You’ve come up with a solid idea. You’ve talked to friends and people you trust, and you’ve probably heard things like, “Yeah, I would definitely use that”, or “I’m surprised no one has built this yet”.

Maybe you have even checked out similar products to see who your competition might be. You might have sketched out a few features, or played around with generative AI to imagine what the product could look like.

Honestly, kudos!

You have done more than most aspiring founders ever do, but this is the point where a lot of people get stuck. They have done the initial thinking and research, but are unsure how to move from idea to something they can actually test with real users.

This is the point where a bit of structure helps you move forward with clarity. Let me walk you through the steps we use to take an idea and shape it into a small, workable prototype you can test with real people, and then into an MVP you can keep learning from.

Get clear on the problem

Before anything else, we slow down and write a simple, clear problem statement. We look at:

• Who has the problem
• What they’re trying to do
• What’s getting in their way
• How they solve it today

Then we distill everything into a single sentence. For example:

“People forget upcoming bills, get hit with late fees, and feel overwhelmed trying to keep track manually.”

If this sentence isn’t clear, our solution won’t be either.

Identify who you are building for

A strong problem statement almost always reveals who the real users are. This idea could be for:

• Adults living alone
• Students
• Parents managing household bills
• Freelancers with inconsistent schedules

But once we continue to refine the problem, a narrower group often emerges. For example:

“Busy working adults who manage multiple bills and subscriptions.”

Focusing on a single persona helps to choose a clear starting point.

Define the one job your product must do

Inside the problem lies the core job-to-be-done, the thing your product must help the user achieve.

For our example:

“Help me quickly see what bills are due and take action so I don’t miss payments.”

If your MVP doesn’t deliver on this job, nothing else matters.

Separate what you know from what you are assumming

In these exercise, we lay everything out into three simple columns:

What we know

• People manage bills across different apps and emails
• Late fees are common
• People often forget when payments are due

What we don’t know

• How often they check their bills
• Whether they prefer reminders, auto-pay, or both
• If they’d trust a new app with this information

What we assume

• They want all bills in one place
• They are willing to pay for the service
• They want a dashboard rather than simple reminders
• They will act on notifications immediately

That last list becomes crucial. Because it helps focus our efforts on testing the assumptions that matter most.

Find the one part of your idea that has to work first

Before sketching anything, we like to map a simple user flow, a quick outline of what someone is trying to do from start to finish.

For our hypothetical finance app, the flow might include:

• onboarding
• adding accounts
• connecting bank details
• viewing upcoming bills
• paying or scheduling

But when you look closely, one moment carries the whole idea:

“Can the user quickly see what’s due and take action?” In the case of our hypothetical finance product, that will be the “View upcoming bills” flow

That’s our critical path. If that moment doesn’t work, the rest of the product doesn’t matter.

Create a simple prototype you can learn from

We can now create a lightweight clickable prototype starting with our critical path, usually in Figma or any design tool of choice. Our goal here is to create just enough screens for someone to see upcoming bills, understand what’s urgent and take an action (real or simulated)

These allows us test it with 5–10 people who fit the user profile, watching for patterns like:

• Do they understand what to do?
• Does the critical path make sense?
• Where do they hesitate?
• What do they expect to happen next?

Then we refine the prototype based on what we learn. This is the cheapest, safest place to fix issues.

Turn the refined prototype into an MVP

Once the prototype feels clear, the next step is to build a small MVP, the simplest working version someone can use in real life.

For our example, this might be:

• a basic list of upcoming bills
• simple reminders
• the ability to log “paid” or “snooze”

To help us launch truly lean and fast, we will avoid bank integrations or any automations. This will help us put the MVP in front of users and focus on the trends their behaviour reveals, trends like:

• Do they return on their own?
• Does it help them stay ahead of payments?
• Where do they drop off?
• What do they ignore entirely?
• What surprised us?

This also allows to incrementally improve the quality of the product while adding features that improves the user’s experience and helps them users solve their problems easier and quicker.

Most MVPs reveal one of three outcomes:

1. The idea works. In this case, we keep building.
2. Some parts work, while others don’t. Here, we refine and test again.
3. The idea doesn’t hold up. In this case, we use trends from user behavior to pivot early and save time.

It is also possible to answer a lot of these questions much earlier when you run a structured Product Design Sprint. In four or five days, you get a clear problem statement, defined user, mapped critical path, and a clickable prototype, all before writing a single line of code. For many founders, that early clarity saves weeks of wandering and months of building the wrong thing.

If you have an idea and want to move forward quickly, our Product Design Sprint process is built exactly for that. Reach out if you’d like support running one.