5 Questions Every Founder Should Answer Before Building a Product

You've got an idea. Maybe you've sketched it out, maybe you've already spoken to a developer, maybe you've got a pitch deck and a Figma file someone put together for you. You're ready to build.

But here's the thing. Most products don't fail because of bad design or buggy code. They fail because the wrong thing got built in the first place.

Before you spend a single pound on development, before you brief a designer or write a user story, there are five questions worth sitting with. Not because they're complicated, but because skipping them is where the expensive mistakes start.

1. What problem are you actually solving?

This sounds obvious. It isn't.

Most founders start with a solution. "I want to build an app that does X" or "I need a platform that connects Y with Z." The feature is clear in their head. The problem it solves? Often much less so.

There's a big difference between "I want to build a booking system" and "small business owners are losing clients because their current booking process involves three emails and a phone call." One is a feature. The other is a problem that a real person has, described in a way that tells you what success looks like.

If you can't describe the problem without mentioning your product, that's worth paying attention to. The best products are built around a pain point that exists whether your solution does or not.

Try writing it down in one sentence: "The problem I'm solving is _____ for _____ because _____." If that sentence is hard to finish, the product isn't ready to build yet. It's ready to research.

2. Who is this for, specifically?

"Small business owners" is not specific enough. "Marketing managers at mid-size companies" is getting closer but still broad. The tighter you can define your first user, the better every decision becomes, from what features to include, to what language sits on the landing page, to where you spend your marketing budget.

This doesn't mean your product can only ever serve one type of person. It means you need to know who you're building for first. Trying to design something that works for everyone usually results in something that works brilliantly for nobody.

Think about one person. Give them a name if it helps. What's their day like? Where does the frustration you're solving sit in their routine? What have they already tried? What would make them switch from whatever they're doing now to your product?

This clarity shapes everything. Without it, you're guessing at features, guessing at priorities, and guessing at what "good" looks like. With it, you've got a filter for every decision that comes next.

3. What does success look like in six months?

Not the ten-year vision. Not the "once we scale globally" version. Six months from launch, what needs to be true for this product to be working?

This question matters because it forces you to separate the essential from the ambitious. Most founders have a long list of features they want. That's fine. But if you try to build all of them before launch, you'll either run out of budget, run out of time, or end up with something so bloated that nobody can figure out how to use it.

Defining short-term success also helps you figure out what to measure. If success at six months means "50 paying customers using the core feature weekly," that tells you what to build first. If it means "validated that people will pay for this," that's a different product entirely, probably smaller, simpler, and cheaper.

The number of products that launch with features nobody uses is staggering. Not because those features were bad ideas, but because they were built too early, before anyone confirmed they were needed.

4. What are your actual constraints?

Budget. Timeline. Technical skills on your team, or lack of them. Existing systems you need to integrate with. Time you personally can commit to the project alongside everything else you're doing.

These aren't exciting things to talk about, but they're the things that will define what's realistic. And realistic matters, because the gap between what a founder envisions and what can actually be delivered with their resources is where most projects go sideways.

Being honest about constraints isn't a limitation. It's a design tool. A £10,000 budget and a £100,000 budget lead to very different products, but both can be good products if they're scoped properly. The problem comes when a £10,000 budget is trying to deliver a £100,000 vision. That's not ambition. That's a project that's going to stall halfway through.

If you're working with a designer or product partner, these constraints should be part of the first conversation, not something that comes up three weeks in when the scope has already expanded twice. The earlier you're honest about what you're working with, the better the outcome.

5. What happens if you don't build this?

This is the question most founders skip, and it might be the most important one.

If the answer is "nothing really changes," that's worth knowing now. It might mean the problem isn't painful enough to sustain a product. It might mean the timing isn't right. It might mean there's a simpler solution that doesn't require building anything at all.

If the answer is "we keep losing customers" or "we keep doing this manually and it's costing us ten hours a week" or "we miss the market window," then you've got something. You've got urgency, you've got a cost of inaction, and you've got a way to measure whether the product was worth building.

This question also helps you prioritise. If not building the booking feature means you keep losing clients, but not building the analytics dashboard just means you check a spreadsheet instead, you know where to start. The things that hurt most when they don't exist are the things to build first.

Why these questions matter before you spend anything

The temptation is always to start building. Tools are more accessible than ever. You can have a prototype in a weekend. But speed without direction just gets you to the wrong place faster.

These five questions aren't about slowing you down. They're about making sure the money and time you invest actually moves you forward. A week spent getting clear on the problem, the user, the goals, the constraints, and the urgency will save you months of rework later.

The founders who get the best results from working with designers, developers, or product partners are almost always the ones who've done this thinking beforehand. Not because they had all the answers, but because they'd asked the right questions. It makes every conversation more productive, every brief more useful, and every pound spent more effective.

If you're reading this and realising some of these questions don't have clear answers yet, that's not a bad sign. It's a good one. It means you're catching it now instead of six months into a build that's heading in the wrong direction.

Where to go from here

Write your answers down. Even rough ones. Share them with someone you trust, a co-founder, an adviser, a potential user. See if they hold up. Refine them.

And if you'd like help working through them, that's exactly what a discovery phase is for. It's the part of the process where you stress-test your thinking before committing to a build, so that when you do start, you're building with confidence rather than assumptions.

At Scale Now Design, every project starts with these kinds of questions. Whether you've got clear answers or you're still figuring it out, a short conversation can help you work out where you stand and what the right next step is. No pressure, no commitment, just honest advice on whether you're ready to build and what that might look like.