Who Is the User and What Problem Do They Have?

If your answer is “anyone who wants to be more productive,” stop there.

That sentence will make your product harder to design, harder to explain, and much easier to overbuild.

You do not need a huge research report to start. You need a believable person with a real job to do and a frustrating current workaround.

Pick a person, not a market

“Founders” is a market. “A solo founder who gets customer feedback through DMs and email” is a user you can build for.

Get specific about:

• their role;
• what they are trying to finish;
• when the problem appears;
• what they do today; and
• what the problem costs them in time, money, or missed progress.

For example:

User: A non-technical founder running customer interviews each week.
Goal: Turn interview notes into a short list of product decisions.
Problem: Notes are spread across recordings, Docs, and chat messages, so patterns are easy to miss.
Current workaround: They reread notes manually before planning meetings.

That is much stronger than “an AI note-taking product for founders.”

Find the pain underneath the request

People often ask for a feature when they are really asking for an outcome.

They do not want a spreadsheet. They want to stop forgetting follow-ups.

They do not want an invoice generator. They want to get paid without spending Friday afternoon formatting documents.

They do not want an AI dashboard. They want to know what to do next.

Write the problem in the user’s language. If it sounds like a product brochure, it is probably too vague.

Use the “without” test

Complete this sentence:

Our user needs to [job] without [painful current obstacle].

Examples:

• A freelancer needs to send a clear project update without writing the same status email every week.
• A founder needs to collect feature requests without losing them across customer conversations.
• A coach needs to schedule sessions without a back-and-forth email chain.

This puts the user’s job first and keeps your solution from becoming the starting assumption.

Look for an expensive workaround

The best early problems are usually repetitive, annoying, and costly in small ways. The user copies the same information twice. They check three places before replying. They keep a spreadsheet because the existing tool does not fit the job.

Those workarounds give you product clues. They show what must be simple, what information matters, and what a user may pay to avoid. Build around the repeated frustration, not a vague category label.

Avoid designing for every edge case

When you choose a specific first user, some people will not fit. That is okay.

You may build for solo founders before agencies. For freelance designers before every creative business. For people who use Gmail before every inbox provider.

That is not exclusion forever. It is focus long enough to build, launch, and learn something useful.

Add this to your PRD

Use this block before you list any features:

Target user:
[specific role]

Job to be done:
[what they are trying to accomplish]

Current pain:
[what makes that job hard now]

Current workaround:
[what they do instead]

V1 promise:
[the simpler, better outcome your product offers]

Once this is clear, your AI coding agent has context for every small implementation decision. More importantly, you have a reason to say no to features that do not help your first user.