How to Choose a Product People Actually Want

Talk to real users before you build, then choose a painful problem they will pay to solve.

By Daniel Smidstrup · Updated July 2026

Before buildingFoundation

Best for

Founders deciding what to build

Effort

Medium

Works best with

Go-to-market

What to expect: A week or two of conversations, not code. Done well, you reject weak ideas cheaply and earn the right to build one narrow solution backed by real conversations and a paid commitment.

How to use this Product validation guide

Talk to real users before you build, then choose a painful problem they will pay to solve. This Product validation guide is designed for founders deciding what to build. It covers 7 practical steps, what results to expect, and the mistakes that most often waste time.

Use this as a practical action plan, not a rigid checklist. Start with the setup, keep the recurring actions that fit your schedule, and use the community notes below to compare the playbook with what other founders actually experienced.

Action plan

0/7 done

1
How to do it
- Name one role or narrow group you can actually reach: Shopify returns managers, solo accountants, or small agency owners - not “businesses”.
- Prefer a group whose work you understand or can interview this week.
- The test: could you open LinkedIn or X right now and find ten of exactly this person? If not, narrow further.
- Write down where they already gather: a subreddit, review site, Slack group, trade forum, or customer list.
2
How to do it
- Ask for 20 minutes to understand how they currently handle the work. Do not send a feature pitch or survey.
- If you cannot find five people willing to talk, distribution is already a problem. Choose a buyer you can reach before building.
- Keep the repository empty and the design file closed until these conversations happen.
3
How to do it
- Ask what triggered it, what they did next, what was frustrating, and what the workaround cost.
- Ask which tools they tried, who chose them, and who controls the budget.
- Do not ask “Would you use my idea?” Compliments predict nothing; specific past behavior exposes real pain.
4
How to do it
- Read 30-50 low-rated reviews for tools the interviewees mentioned. Save the buyer’s exact words.
- Look for the same painful job across several people, sources, and weeks.
- TrendGap can speed this up by clustering complaints from review platforms, communities, and app stores. Use its scores to find evidence, never as a substitute for talking to users.
5
How to do it
- Pain: does it happen often, cost money or time, and create urgency?
- Spending: are buyers already paying for software, labor, or a workaround?
- Competition: are existing tools weak for this segment, rather than simply popular?
- Reach: can you name a cheap path to the first 100 prospects?
- Buildability: can a useful first version solve one job within 30-60 days?
6
How to do it
- Write a landing page for one outcome, one buyer, and one painful job.
- Show the proposed workflow and price. A vague waitlist hides whether the offer is understandable and worth paying for.
- Send it directly to the people you interviewed and to one relevant community where promotion is allowed.
7
How to do it
- Best signal: a paid pilot, preorder, deposit, or signed letter of intent with a real start date.
- Useful early signal: a buyer introduces you to the budget owner, shares data, or books the next implementation call.
- Weak signal: likes, survey enthusiasm, email signups with no reply, or friends saying they would use it.
- If nobody commits, change the buyer, pain, promise, or price before changing the feature list.

Tips and traps

Do this

Talking to users is the base task. Research tools organize signals; conversations explain the context and buying behavior behind them.
A good opportunity is repeated pain plus willingness to pay plus a reachable buyer. Any one signal alone is not enough.
Use tools such as TrendGap to shorten research, then verify the underlying complaints with real buyers.
Pick the smallest painful wedge. You can expand after customers trust you with one job.
Keep a rejection log. Learning why an idea failed prevents you from quietly rebuilding the same assumption.
Define the product by the problem it removes, not the features it has. Features change; the problem is the pitch.

Avoid this

Opening the code editor before you can describe five recent user conversations.
Choosing an idea because it is technically interesting or currently fashionable.
Counting search volume, upvotes, or an AI opportunity score as purchase intent.
Asking “Would you use this?” instead of asking about past behavior and requesting a commitment.
Building a broad platform before one narrow workflow has paying users.

What founders actually found

Share what you tried, what happened, and the numbers. Keep it useful. Promotional links are removed automatically.

No founder notes yet. Be the first to share what worked.

Related guides

Keep building your launch plan.

All guides

Go-to-marketNail who it is for and how you reach them, before spending on any channel.