Building What People Want

Launch day arrived. Posted everywhere. Waited for the flood of sign-ups.

Barely anyone signed up. The few who did never came back after the first login.

Turns out, users didn't want it.

Why? Could be a number of reasons. But what’s for sure is the cause: three months of building blind.

This is the number one cause of startup failure. We build in secret, perfecting our vision, then release it to discover absolutely no one cares. We've solved problems that exist only in our heads.

The brutal truth? Your first build will be wrong about something important. Maybe everything.

Let’s get started:

Why Beta Testing Matters

You've got an MVP. It might work. Maybe. It might solve the problem you think it solves. Maybe. But assumptions aren't facts.

What we think about it sort of doesn’t matter. Our opinion is the least important.

So we’re going to find beta testers. These are people who try out our unfinished masterpiece, knowing that it’s not the end product. Beta testing isn't about proving you're brilliant. It's about discovering your blind spots before we release into the world.

We actually want to be wrong here. And to find our errors ASAP. So that we can fix them and improve.

Here's what you'll learn from real users that you'll never discover building alone:

They use it differently than you expected. You built a workflow assuming users would go A → B → C. They're going A → D → B and getting confused at step C.

They care about different things. Maybe you spent weeks perfecting a dashboard. They just want the export button to actually work.

They have different language. You call it "project optimisation." They call it "getting stuff done faster." (Hint: this will be important later when we get to marketing)

They have different problems. You solved problem X. They actually need help with problem Y, which is related but different.

The sooner you discover these gaps, the sooner you can fix them. The longer you wait, the more time you waste building the wrong thing.

And if we go in assuming we know best then we’ll crash and burn. This is all about dropping the ego and getting real people to test what we’ve build. It’s hard. I won’t lie. But it’s super important.

Finding Your First 10 Testers

First up we just need to find 10 people. This is not about building a complex systematic testing flow with analytics, thousands of data points and sophisticated feedback. Not yet. This is about getting the tool into the hands of real people first.

Start with the warmest possible audience and work outward. Here's the order:

Circle 1: People You Know Personally

Friends, family, colleagues, classmates. Anyone who'd help you out as a favour.

Yes, they'll be nice to you. Yes, they might not be your target market. But they'll actually use your thing, and that's what matters right now. Start here even though it’s not “perfect”.

You need people who will:

• Actually try your product (not just say they will)

• Give you honest feedback when you ask

• Answer your follow-up questions

• Let you watch them use it

Circle 2: Your Existing Audience

Anyone following your build-in-public journey. They're already invested in your success and understand what you're building.

Post in the WhatsApp community if you are part of it. Message people who've engaged with your content. Ask your LinkedIn connections.

Circle 3: Relevant Communities

Going out wider now to communities. Industry forums, Reddit subreddits, Facebook groups where your target users hang out. We found some of these during the market research phase so loop back to them.

But only after you've exhausted circles 1 and 2. Cold outreach is harder and less reliable for early testing.

One important thing - when posting make sure people know you aren’t selling. Make this abundantly clear - “I’m looking for a handful of people to test this out. I think it’s useful but need real people to see if I’m heading in the right direction. I’m not selling anything here just looking for human feedback”. The assumption will be you are selling so we need to counter this upfront.

The Simple Approach

Don't overcomplicate this. You need 10 people to actually try your thing. That's it.

Sit down and look at your three circles.

Then message them. Today.

Keep it simple: "I've built this thing to solve [problem]. Would you mind trying it and telling me what you think? Takes about 10 minutes. Haven’t got anything to sell - just looking for feedback."

Most will say yes if you've picked the right people. Pro tip here: people love to be asked for their opinion, especially their “expert opinion”. You can use this as leverage.

Your AI Prompt for Today

OK here’s a quick prompt to help with all of this. But don’t overthink it! This is about action. We just need 10 people.

You are a user research specialist helping me identify and prioritise potential beta testers for my new product. My product is [DESCRIBE YOUR PRODUCT IN ONE SENTENCE].

Please help me create a systematic approach to finding my first 10 beta testers by:

1. Circle 1 - Personal Network:
   - Suggest 5 categories of people I likely know who might be interested
   - Provide a simple message template for reaching out to friends/family/colleagues
   - Include what to say if they're not the target user but might help anyway

2. Circle 2 - My Audience:
   - Suggest ways to leverage my build-in-public journey to find interested testers
   - Provide templates for social media posts asking for beta testers
   - Include approaches for the WhatsApp community and LinkedIn connections

3. Circle 3 - Relevant Communities:
   - Suggest 3-5 places online where my target users congregate
   - Provide templates for community posts that don't feel spammy
   - Include guidelines for following community rules while recruiting

4. Qualification Questions:
   - Create 3-5 simple questions to confirm someone is worth the time investment
   - Focus on willingness to give feedback, not just interest in trying it

Make everything simple and actionable. I want to message 10 people by the end of today.

Don't spend all day planning. Spend 10 minutes planning, then start messaging. If they say no (o more likely, say nothing) who cares. Just get your asks out.

Build in Public Content

Share your approach:

"Day 21 of AI Summer Camp: Time to find my first beta testers.

Built my MVP last week. Now for the scary part - letting real people use it.

Looking for testers to try what I’ve built. I don’t have anything to sell. Just looking for feedback. Comment or message if interested”

What's Next?

Tomorrow we tackle onboarding - helping your beta testers actually get started and find value in your product.

Keep Prompting,

Kyle

You jump on a call. Show them the proper way. "No, no - click here first, then do this, then that." They nod. "Oh right, that makes sense. I guess I just didn’t understand."

Problem solved, right?

Wrong. Problem delayed. At best.

Your beta testers are previewing exactly what real customers will do. And you won't be there to fix it for them.

If your tester uses it wrong, so will your customers. If they get confused, so will everyone else. If they need hand-holding to understand the basics, your product isn't ready.

There's nothing worse than building something people can't figure out how to use properly. Good onboarding fixes this before it kills your business.

Let’s get started:

Why Onboarding Matters for Beta Testing

Maybe you've got your first few testers lined up from yesterday. Maybe you're still waiting for replies. Either way, keep pushing - send more messages, ask more people.

I’m going to assume you don’t have them yet. It’s only been a day!

Whilst you're chasing down testers, let's get everything ready for when they say yes. We’ll lay out the welcome mat.

Because once someone agrees to test your product, you want to get them using it immediately. Strike while they're motivated. The longer you wait, the more likely they are to forget or get busy with other things. Good (and fast) onboarding transforms "I'll try to look at it when I have time" into "I tried it and here's what I think."

Most testers have good intentions. They want to help. But they're busy people doing you a favour, let’s be honest. If your product is confusing or unclear, they'll try it once, get stuck, and never come back.

And worse they probably won’t tell you what went wrong. You won't get feedback because they didn't really experience your product. They experienced confusion.

Getting your onboarding sorted now means you're ready to capitalise the moment someone says "yes, I'll test it."

The Beta Testing Onboarding Goal

Remember that this isn't about converting paying customers yet. It's about getting people to experience your product properly so they can give you intelligent feedback.

Your onboarding needs to achieve one main thing: Get them to their "ooooo I get it" moment as fast as possible.

This is your Time to Value - the exact moment when they understand what your product does and see it working for them. Not just intellectually understanding it, but actually experiencing the benefit.

For most simple apps, this should happen within 2-3 minutes. If it takes longer, you'll lose them. That's it. No fancy animated tutorials. No comprehensive feature tours. No long-arse video walkthrough. Just clear steps that lead to meaningful usage.

Think about it:

• Productivity tool? They need to see it actually save them time on a real task

• Data analyser? They need to see it generate useful insights from sample data

• Content generator? They need to see it create something they'd actually use

• Problem solver? They need to watch it solve a version of their actual problem

Once they hit that "ooooo I get it" moment, they'll stick around long enough to give you proper feedback. Without it, they'll try it once and shrug.

Your AI Prompt for Today

Since you built your MVP with no-code tools we’re going to first pull information about our product into a format we can work with.

Step 1: Get Your Product Spec from Lovable

First, go to Lovable (or whatever tool you used to build) and ask it to generate a user guide:

Create a comprehensive user guide for this project. Include:
- What the product does (main purpose and value)
- Complete step-by-step user workflow from start to finish
- All key features and how to access them
- What users should expect to see at each step
- Any sample data or examples that would help new users

Make this guide detailed enough that someone who's never seen the product could understand how to use it properly.

Step 2: Take That Guide to ChatGPT for Onboarding

Copy the user guide from Lovable and use this prompt in ChatGPT/Claude or your favourite AI:

I need to create simple onboarding for beta testers of my product. Here's the full product specification: [PASTE THE LOVABLE USER GUIDE HERE]

Please help me create Simple Welcome Message Template:
   - Link + 3-step instructions format
   - One sentence explanation of what it does
   - The exact 3 steps new users should take to see value quickly
   - Contact details for questions

Keep everything simple - this is for a basic app, not enterprise software. I want them to understand what it does and experience value within 2-3 minutes.

The Simple Welcome Flow

Now you'll take the output from those prompts and create your actual onboarding. Keep this dead simple - a single email or text with clear instructions, not a complex multi-stage system.

Remember: this is a super simple app for now. You're not onboarding people to enterprise software. You're giving them access to something basic and making sure they know how to use it.

Using the template from the second prompt, send this as soon as they agree to test:

"Here's the link to try [product name]: [LINK]

No registration needed.

What it does: [One sentence from your prompt output]

How to use it:

1. [First step from your prompt output]

2. [Second step from your prompt output]

3. [Third step from your prompt output]

Should take 2-3 minutes to see how it works.

Any questions? Just reply to this message.

Thanks for testing this!"

That's it. No long emails. No fancy formatting. Just the clear, specific instructions that came from understanding your actual product workflow.

I also recommend making this as simple as possible for them. No need to register. Give them an email or Whatsapp to contact you by. Remove as much friction as possible.

Your Deliverable Today

Create your beta tester onboarding ready for when people say yes:

1. Run both AI prompts above to get your product spec and onboarding template

2. Write your actual welcome message using the ChatGPT output

3. Test the entire flow yourself and send the link to a friend for a double check

4. Have this message ready to send immediately when someone agrees to test

And keep pushing for more testers! The onboarding prep shouldn't stop you from continuing to message people from yesterday's list. The goal here is to be ready to send a perfect onboarding experience the moment someone says "yes, I'll try it."

Build in Public Content

Share your approach:

"Day 22 of AI Summer Camp: Setting up onboarding for my beta testers.

Goal: Get them from 'I signed up' to 'I understand what this does' in under 3 minutes.

No fancy tutorials. Just clear next steps and sample data to play with.

Beta testers are doing me a favour - the least I can do is make it easy for them to actually try my product.

Anyone else onboarding beta users? What's working for you?

Also, still looking for more beta testers! DM me if interested"

What's Next?

Tomorrow we tackle feedback collection - setting up simple systems to capture what your beta testers think and do. Because getting them to use your product is only valuable if you can learn from their experience!

Keep Prompting,

Kyle

Basically a waste of time. But this is how most people collect feedback. They ask vague questions and get vague answers. Then they wonder why their product still doesn't work properly for real users.

Worse: they’ll protest “I talked to customers!” as a defence. And they did. Technically. They just didn’t do it properly.

Your beta testers are willing to help, but you need to make it easy for them to give you the specific insights you actually need. This comes from asking the right questions.

Let’s get started:

Why Systematic Feedback Matters

First up we’ve got to systematise this. Random "what do you think?" questions get you polite responses, not useful insights.

Your beta testers want to help. They wouldn’t have volunteered otherwise. But they don't know what kind of feedback you need. They'll default to being nice rather than being helpful. So we need to help them help you, if that makes sense!

You need structured ways to capture the specific information that will actually improve your product:

• Usage patterns: What did they actually do? Not what they said they'd do, but what they actually clicked and tried.

• Confusion points: Where did they get stuck? What wasn't obvious? What made them pause and think?

• Language they use: How do they describe the problem? What words do they use? This becomes your marketing copy later.

• Missing expectations: What did they expect to find but didn't? What felt incomplete?

• Workflow fit: How does this fit into their actual process? What comes before and after using your tool?

The goal isn't to hear "good job." It's to discover exactly where your assumptions were wrong. Don’t worry, I’ll give you a prompt to construct all of this. First up let’s chat mechanics of how we collect..

Collection Methods

There’s a spectrum of different ways to get feedback. All are good but some are better and richer. One thing I’d say for now is that whilst it’s very nice to have built in feedback and analytics inside your tool that’s adding too much complexity for now. That’ll be super valuable but first we need to make sure our basic business idea is sound - we can do that with more basic methods.

So keep this external to your product for now. Don't try to build feedback systems into your app - use simple tools that already work. Here are a few ranging (roughly!) from easiest to most valuable.

Google Forms (Easiest)

Create a simple form with 5-7 specific questions. Send them the link after they've tried your product. Free, easy to set up, organises responses automatically. Make it anonymous if you think that’ll help them be more truthful.

Voice Notes (Underrated)

Ask them to record a quick voice note on their phone while using your product. "Just talk through what you're thinking as you try this." Often more honest than written feedback because people have less time to structure their thoughts. Stream of consciousness is much more useful.

Screen Recording

A step up is asking them to record their screen while using it. Shows you exactly where they get confused. Tools like Loom make this dead simple. But this is still adding an additional layer of difficulty on their side - remember we want to keep this as frictionless as humanly possible!

Quick Calls (Most Valuable)

Nothing beats a 10-minute call where you can ask follow-up questions. This is the holy grail. But also requires you to step out of your comfort zone and it requires them to carve out time. Which is a pain. So…whilst it’s a very powerful method it’s also more difficult for both you and the tester.

The key: make it as easy as possible for them to give you specific, useful information.

For now I want you to choose one of these methods and use it alongside the prompt below. Use this below your prior work for best results as always as there will be additional context.

Your AI Prompt for Today

I need to create a feedback collection system for beta testers of my product. Here's my product information: [DESCRIBE YOUR PRODUCT AND MAIN FEATURES]

I want to use [CHOOSE YOUR METHOD: Google Forms / Voice notes / Screen recordings / Quick calls] as my primary feedback collection method.

I want to collect these specific types of feedback:
- Usage patterns: What they actually did, not what they said they'd do
- Confusion points: Where they got stuck or weren't sure what to do next
- Language they use: How they describe the problem in their own words
- Missing expectations: What they expected to see that wasn't there
- Workflow fit: How this fits into their actual process
- Specific improvements: What they'd change to make it more useful

Please help me create:

1. Feedback Collection Setup:
   - If Google Forms: 5-7 specific questions that get actionable insights
   - If Voice notes: Script for what to ask them to record
   - If Screen recordings: Instructions for what to capture
   - If Calls: Question list for 10-15 minute conversations

2. Specific Questions Based on My Product:
   - Questions about usage patterns specific to my features
   - Questions about confusion points relevant to my interface
   - Questions about missing expectations for my type of tool
   - Questions about workflow integration for my target users

3. Follow-up Sequence:
   - When to send the feedback request (immediately after use? next day?)
   - How many follow-ups to send if they don't respond
   - What to do with non-responders

4. Organisation System:
   - How to categorise and track the feedback I receive
   - What patterns to look for across multiple responses
   - How to prioritise which feedback to act on first

Make everything specific to my product and collection method. I want actionable insights, not generic compliments.

This will combine information about your product alongside your chosen feedback collection method and prep up all the materials and a brief for you. I’ve also put in some extra stuff about follow up and how to track and organise feedback - all you need to do is implement.

Types of Feedback to Collect

This will get you started but it’s useful (especially if you are doing calls!) to know what you are looking out for. Focus on gathering information that will actually change how you build:

• What they actually did: "Walk me through exactly what you clicked and in what order."

• Where they hesitated: "Was there any point where you weren't sure what to do next?"

• How they describe it: "In your own words, what problem does this solve?"

• What they expected: "Was there anything you expected to see that wasn't there?"

• How it fits their process: "Where would this fit into your normal workflow?"

• What confused them: "What part felt unclear or confusing?"

• What they'd change: "If you could change one thing to make this more useful, what would it be?"

Notice how these are all specific, actionable questions rather than general "what do you think?" prompts. These sort of questions will get you the actionable info you need. These are just examples to model. The prompt will also help you come up with more.

Your Deliverable Today

Set up your feedback collection system:

1. Choose your primary collection method (form, screen record, calls, etc.)

2. Use the AI prompt to create your specific questions and setup

3. Create the actual tool (Google Form, call script, etc.)

4. Test it with a friend to make sure it's clear and easy

5. Have it ready to send to beta testers after they've used your product

Don't wait for perfect. Get a basic system working that you can improve as you learn what questions work best. We can (and will) add more sophisticated systems later, directly into your product. But right now keep moving forward.

Build in Public Content

Share your approach:

"Day 23 of AI Summer Camp: Setting up feedback collection for beta testers.

Moving beyond 'what do you think?' to specific questions that get actionable insights.

Using [your chosen method] to capture usage patterns, confusion points, and missing expectations.

The goal: learn exactly where my assumptions were wrong so I can fix them.

How do you collect useful feedback from early users? Any tips?"

What's Next?

Tomorrow we dive into being obsessively helpful to your beta testers. Because collecting feedback is only half the job - you also need to support them, watch them use your product live, and have real conversations about their experience. You'll learn how to schedule calls, conduct live screen shares, and be genuinely helpful while gathering the insights you need.

Keep Prompting,

Kyle

If you feel this — learning how to use AI in entrepreneurship and work — is not for you → Unsubscribe here.

First day: Marcus mentions he's confused about one feature. Within an hour, there's a thoughtful response with a screen recording showing exactly how to use it. Useful.

Second day: Marcus mentions something isn’t quite working as it probably should. The founders thanks him. Then an hour later, unexpectedly the founder sends a message saying “cool that’s fixed! Thanks for flagging it”. Huh…impressive.

Third day: out of the blue the founder follows up with "Oh, you could also use it for tracking your client invoices - might save you time there too." An additional use Marcus hadn’t really thought about but would absolutely help the business.

By week's end, Marcus isn't just testing the app - he's actively rooting for its success. He starts mentioning it to colleagues. Shares it in his company Slack. When the founder launches properly, Marcus becomes the first customer and biggest advocate.

All because someone made him feel genuinely valued during beta testing. The founder didn’t just listen but also acted based on what Marcus said. Powerful stuff.

Let’s get started:

Why Champions Matter More Than Feedback

OK I have a confession to make. I framed this week as being all about getting feedback to improve our product.

That’s true…but we’re also doing something else smart at the same time. You know me - I like efficiency!

Most founders think beta testing is about collecting data. "What do you think of this feature?" "Rate this experience." "Fill out this survey."

They're missing the bigger opportunity here.

Beta testing is also about relationship building. Every person who tests your product is a potential champion who could refer dozens of future customers. But only if you make them feel valued in the process.

That’s a big proviso! So much so that we’re spending today working on exactly how convert our testers into advocates.

The difference between a one-time tester and a lifelong advocate often comes down to how supported they felt during those early interactions. Marcus from above didn't become a champion because the product was perfect. Not at all. He became a champion because the founder made him feel heard, helped, and important.

In a way the product being bad (and Marcus’ feedback being used to improve it!) is what makes the connection stronger. Marcus is now a co-creator.

We’re going to do this in three ways specifically:

• respond quickly and efficiently

• apply their fixes (when relevant)

• go out of our way to help them more

Responsive Support That Creates Advocates

First up we need to respect their time and effort. When they give us feedback we respond immediately and enthusiastically. This is the very least we can do!

Whatever collection method you chose yesterday, the key is being thoughtfully responsive in ways that help testers succeed. When someone mentions confusion, respond with specific help. When they share how they're using it, suggest additional applications. When they encounter problems, solve them quickly.

To help with this speed let’s use a prompt:

I received this specific feedback/question/response from a beta tester: [PASTE THEIR EXACT MESSAGE]

My product is: [DESCRIBE YOUR PRODUCT]
Context about this tester: [WHAT YOU KNOW ABOUT THEM/HOW THEY'RE USING IT]

Help me craft an immediate, enthusiastic response that:
1. Acknowledges their specific feedback with genuine appreciation
2. Shows I understand what they're telling me
3. Demonstrates that I value their time and input
4. Responds to any questions they asked
5. Makes them feel heard and valued

Make the response conversational and genuinely helpful, not corporate or sales-focused. I want them to feel like I'm personally invested in their success with the product.

Obviously adapt to your own tone of voice. This is primarily for speed.

Quick Fixes That Build Relationships

Next up - fixes.

Do we fix everything they point out as a problem? Absolutely not. Tomorrow we talk about which problems we fix and which we do not - I’ll give you a framework to prioritise.

What we’re fixing immediately are the problems so glaringly obvious that we feel like complete idiots when we’re told about them.

I’m talking about the “I press the submit button and the screen just goes blank” sort of problems. Not the “I think the header text could be larger” type of issue.

Quick fixes serve two purposes: they improve your product (yay) AND they demonstrate to testers that their input matters. When someone mentions a confusing button and you fix it the same day, they feel heard in a way that builds genuine loyalty.

Use AI to help turn feedback into immediate improvements:

I received this feedback from a beta tester: [PASTE FEEDBACK]

Help me determine:
1. Is this an obvious usability fix that should be addressed immediately?
2. What's the simplest way to address this specific issue?
3. How can I turn this into clear development instructions?

My product was built with: [LOVABLE/CURSOR/OTHER]
The issue seems to be: [DESCRIBE THE PROBLEM AREA]

Give me the fix instructions AND a "I've fixed it message" I can send back to the tester that shows that their feedback matters.

Use this below your previous work (especially the product spec work we did earlier this week) so that ChatGPT or Claude will be able to generate helpful possible fixes.

When you do make a quick fix based on someone's feedback, let them know! So many builders miss this simple task. Stupid. It’s easy goodwill that could be acquired with a simple "Thanks for mentioning that button issue - just fixed it!". Immediately they’ll feel heard and valued.

Additional Ways They Could Use It

Let’s go above and beyond. We’re going to overdeliver. Your testers are using your product for one specific purpose (probably the one you first contacted them about), but there might be other ways it could help them that they haven't considered.

After someone's used your product for a few days, follow up with additional use cases they might find valuable. This shows you're thinking about them and their needs, not just your product validation. It’s a pure value add.

I have a beta tester who's been using my product for [DESCRIBE HOW THEY'RE USING IT].

My product is: [DESCRIBE YOUR PRODUCT AND FEATURES]
What I know about their work/situation: [SHARE WHAT YOU'VE LEARNED]

Help me identify 2-3 additional ways they could use my product that might be valuable for their specific situation. Focus on practical applications they might not have considered.

Create a friendly follow-up message suggesting these additional uses without being pushy. Frame it as "you might also find this helpful" rather than trying to convince them.

Drop in feedback they’ve given you and any notes about what they’ve been using it for. And use this to extrapolate out (with the help of AI).

This could be things that they can already do with your product. And you are just mentioning the additional use cases.

OR (and this is more advanced) it could be uses that aren’t yet supported but you could build in. We’ll talk more on this tomorrow.

This approach transforms you from someone asking for favours into someone genuinely trying to help them succeed. You’re basically giving them white-glove concierge service. And one that importantly they were not expecting. That’s the key! Above and beyond.

Your Deliverable Today

Focus on building relationships, not just gathering data:

1. Reach out to every beta tester with genuine interest in their experience

2. Use the AI prompts above to create helpful, relationship-focused support approaches

3. Identify and quickly fix any obvious usability issues that come up

4. Document not just what feedback you received, but how each person responded to your support

Remember, you're building relationships with people who could become your biggest supporters. And first customers. More on that soon!

Build in Public Content

Share the relationship-building approach:

"Day 24 of AI Summer Camp: Turning beta testers into champions.

Doing something different today. Most founders treat beta testing like data collection. I'm treating it like relationship building. Big shift.

I’ve realised every person testing my product is a potential advocate who could refer future customers. But only if I make them feel genuinely valued in the process. So…I’m working on that today. “

What's Next?

Tomorrow we tackle which feedback to act on and which to ignore. Not every suggestion should be implemented, even from people you've built great relationships with. We'll learn about Stephen King's rule for feedback and create a systematic approach to deciding what changes actually improve your product versus what just makes individual users happy.

Keep Prompting,

Kyle

Day 2: "Can you add a dark mode?"

Day 3: "The font is too small for me."

Day 4: "I wish it had more customisation options."

Day 5: "Actually, it's too complicated now. Can you simplify it?"

Every founder faces this. Beta testers start sending feedback, and suddenly you're jumping to implement every suggestion. Green button becomes blue. Dark mode gets added. Font size increases. More options appear. Then you're simplifying again.

Haven’t we been here before?? Six weeks later, your product looks nothing like what you started with, and you're not sure if it's better or worse. You've been reacting instead of thinking strategically. Sure, you’ve been busy…but to what end?

There's a famous piece of writing advice that applies perfectly here. Stephen King wrote about feedback: if one person tells you something's wrong, they might be mistaken. If multiple people tell you the same thing, pay attention.

We’re going to apply this principal and help you work out what is worth doing and what can be safely back burnered.

Let’s get started:

Stephen King's Rule About Feedback

Stephen King understood something crucial about feedback that most creators miss. Individual opinions often reflect personal preferences, not universal problems.

The rule: if one person mentions an issue, consider it but don't act immediately unless it’s literally a critical bug (as we discussed in yesterday) If multiple people mention the same issue independently, that's a pattern worth addressing.

This isn't about ignoring feedback. Well…it sort of is, but strategically! It's about distinguishing between individual preferences and actual problems that affect most users. This is made worse because often someone wants to be helpful and so will give you lots of feedback just for the sake of it.

When someone says "the button should be blue," that's probably preference. When three different people say "I couldn't find the submit button," that's a usability problem. Very different!

The difference matters because you can't build for everyone's personal preferences without creating a confusing mess. But you must fix problems that prevent people from using your product successfully.

Iteration vs Pivoting Explained

Most feedback leads to iteration, not pivoting. Let’s quickly unpack this as it’s key.

Iteration means making incremental improvements to your existing approach. Better button placement, clearer labels, simpler workflows, bug fixes. These changes improve what you've built without changing your core strategy.

Pivoting means fundamentally changing your approach. Different target market, different core problem, different solution architecture. These are strategic decisions that affect your entire product direction.

Most beta feedback is about iteration. "This is confusing" suggests better design. "I can't figure out how to save" suggests interface improvements. "It's too slow" suggests performance optimisation.

Pivoting feedback is rarer but more serious. "I don't understand what problem this solves" or "This isn't actually useful for my situation" suggests deeper issues with your core premise.

The mistake most first time founders make is treating iteration feedback like pivoting decisions, or pivoting based on individual preferences rather than systematic problems. We need to protect ourselves against this to preserve our time and sanity. And make sure the product doesn’t become an absolute mess!

As the saying goes a camel is a horse designed by a committee. Personally I think this is far too mean to the poor camels. But you get the point!

Prioritising Feedback Framework

OK so the feedback is coming in. How do we practically categorise and prioritise what you've collected:

High Priority (Fix Immediately)

• Multiple people mention the same usability problem

• Anyone encounters bugs that prevent core functionality

• Consistent confusion about your main value proposition

• Security or data safety concerns

Medium Priority (Fix Soon)

• Single person mentions a significant usability issue

• Suggestions that would improve the core workflow

• Performance issues that don't break functionality

• Requests for basic expected features

Low Priority (Consider Later)

• Individual preference feedback

• Feature requests that add complexity

• Suggestions that serve edge cases

• Cosmetic changes that don't affect usability

No Priority (Ignore)

• Requests that contradict your core strategy

• Suggestions to become a completely different product

• Individual opinions that conflict with majority feedback

• Features that would confuse most users

Got that? Let’s build into in a prompt that will help you sort and filter everything you've collected this week:

I need to prioritise feedback from my beta testing week. Here's all the feedback I received: [PASTE ALL FEEDBACK]

My product is: [DESCRIBE YOUR PRODUCT]
My core value proposition is: [MAIN PROBLEM YOU SOLVE]

Help me categorise this feedback using these priorities:
- High Priority: Multiple people mention same issue OR bugs that break functionality
- Medium Priority: Single person mentions significant issue OR improvements to core workflow
- Low Priority: Individual preferences OR nice-to-have features
- No Priority: Contradicts strategy OR would confuse most users

For high and medium priority items, suggest the order I should tackle them and why. For low priority items, explain why they can wait. For no priority items, explain why I should ignore them.

Give me a clear action plan for what to fix first.

This prompt will help you sort signal from noise and create a logical improvement plan. You still have to have the confidence to deprioritise feedback though! Which initially will be hard. Like all things you’ll get better at it the more you practice. Just try not to jump at every single piece of feedback!

Building Your First Update

Now we’ll pull together everything we’ve been working on and create our first “update”.

You know how software often comes in versions? That’s basically what we are doing here. V1 becomes V1.1 or (if it’s a big change) maybe even V2. Generally we use decimals for relatively minor updates as a useful convention. And to stop us ending up on V148 down the line!

Once you've prioritised your feedback, it's time to implement the obvious winners. Start with the simplest fixes first. Button placement issues, confusing labels, missing functionality that everyone expects. These quick wins build momentum and show your testers that you're listening. Here’s a prompt to help put together an action plan:

Based on my prioritised feedback, I want to implement these high-priority fixes: [LIST YOUR TOP 3-5 ITEMS]

My product was built with: [LOVABLE/CURSOR/OTHER]
Current functionality: [DESCRIBE CURRENT STATE]

For each fix, help me:
1. Create clear development instructions I can implement
2. Estimate how long each fix should take
3. Identify any potential complications or dependencies
4. Suggest the best order to implement them

Also help me write update messages I can send to my beta testers explaining what I've fixed based on their feedback.

Communicating Updates to Testers

As we discussed yesterday remember to tell your testers when you make changes based on feedback! This completes the feedback loop and reinforces that their input matters. That’s what builds relationships! Making the fix is just one part.

And any changes you didn’t implement?? Just don’t say anything. Testers aren’t expecting updates. So we only update them with good news (I took your advice and made a change) rather than bad news (your feedback was stupid so I didn’t do it). We control the flow of info here!

Keep the updates simple and specific: "Thanks for mentioning the confusing save button - just moved it to a more obvious location" or "Based on feedback from several testers, simplified the main navigation." And avoid over-explaining your decision-making process. Just acknowledge their input and describe the improvement.

Your Deliverable Today

Create your first strategic update:

1. Use the AI prompt to categorise all your Week 5 feedback by priority

2. Identify the top 3-5 high-priority issues mentioned by multiple testers

3. Use the second prompt to create implementation plans for these fixes

4. Build and deploy your improved version

5. Message all your beta testers with specific updates you made based on their feedback

Build in Public Content

Share your strategic approach:

"Day 25 of AI Summer Camp / Week 5 wrap: How beta feedback changed my product (and what I ignored).

Got loads of feedback from beta testers this week.

Here’s what I’ve updated based on my amazing testers: list out changes and your journey”

What's Next?

Week 5 complete! You've moved from MVP to validated, improved product with real users who are becoming advocates.

Week 6 shifts to grassroots marketing. You'll use your improved product, your beta tester relationships, and your build-in-public audience to start systematic growth without paid advertising.

The foundation is solid. The product works. The relationships are built. Time to start getting our work out into the world.

Keep Prompting,

Kyle