You have an idea for a product. What do you build first?

You’ve been thinking about an idea for a while, and the more you think about it, the more you can see what it could become. You start a document, write down a few features, come back to it the next day and add a few more. At some point, someone asks what the first version would look like, and you realise the answer isn’t as obvious as you thought.

I think that’s a perfectly normal place to be. When you’re close to an idea, everything starts to feel connected: the dashboard needs data, the data needs accounts, the accounts need permissions… and before you know it, your first version looks suspiciously like the entire product you had in mind.

That can be uncomfortable, especially when you’re about to spend your own money. You want to give the idea a proper chance, but you also don’t want to spend months building something only to find out that the people you had in mind needed something else. So how do you decide where to begin?

Get close to the problem

I find it helpful to put the feature list aside for a moment and go back to the situation that gave you the idea. What was someone trying to do, and what got in their way? It sounds simple, but the answer can change how you think about the product.

Imagine a small repair business where the person answering the phone has to find another technician when an appointment falls through. The team uses a group chat, which works well enough until the dispatcher is left waiting for a reply with a customer still on the line.

It’s easy to picture an app with schedules, notifications and a lovely dashboard. Before deciding what goes on that dashboard, we need to understand what happens during the call. Does the dispatcher need to see who is available, or do they already know and struggle to get a response? Does the customer need an answer immediately, or would a callback be fine?

Depending on the answers, you might end up building very different things. That’s why talking to the people who deal with the problem matters. Ask them to walk you through the last time it happened. They might show you a spreadsheet, a chat or a note stuck to their desk, and that slightly awkward workaround can tell you a lot about what a new product would need to fit into.

And yes, it’s tempting to ask, “Would you use an app for that?” I understand why: when you’re excited about an idea, you want to know whether anyone else is excited too. But someone can genuinely like the sound of it and still carry on using the group chat because that’s what fits into their day. Understanding that difference is worth a conversation.

If you want to get better at those conversations, The Mom Test by Rob Fitzpatrick is a useful read. It explores how to ask questions that help you learn about people’s lives and problems, rather than collecting compliments about your idea.

Give the first version a job

Let’s say those conversations suggest the dispatcher needs to see who can take an appointment and offer it to them quickly. You now have a starting point for the product: a dispatcher can find someone available, offer them the job, and see whether they accept.

You can use that idea to sketch a user flow: the path someone takes from a situation to a result. It doesn’t need to be a diagram or a finished design. For this example, a few lines are enough:

An appointment falls through → the dispatcher finds an available technician → the dispatcher offers them the job → the technician responds → the dispatcher sees the answer.

Try writing yours in the same way: start with what brings someone to the product, follow what they need to do, and end with the result they need. If you’re unsure about a step, write down the question beside it. That’s useful information to take into the next conversation.

There are still decisions to make, of course. Someone has to enter availability, and the dispatcher needs to know what to do if nobody accepts. You’ll also need to think about who can see customer details. At least now you can look at each decision in the context of a task someone needs to finish.

The dashboard might still be a good idea, and automated reminders could be useful later. Keep them on the list while figuring out whether the first piece actually helps the people using it.

This is the part I find difficult, and interesting. Leaving something out can feel like you’re giving up on an idea, especially when you can already picture how useful it might become. You’re really making a choice about where to spend your time and money while there’s still plenty you don’t know. The first version needs to be something you can finish and put in front of someone, with enough of the task working for their feedback to mean something.

Small doesn’t mean careless, though. If the product contains customer information, access and data handling need attention from the beginning. And if the dispatcher can’t tell whether a technician accepted the job, the job isn’t finished just because the offer was sent.

Find out what you’re assuming

There’s a lot we still don’t know about our fictional repair business. If technicians don’t have time to keep their availability up to date, or dispatchers need to speak to them before making an offer anyway, that changes what makes sense to build.

The good news is that you can explore some of these questions before paying for a complete application. You could sketch the screens and ask a dispatcher to walk through an appointment, or handle a few requests manually to see what information people need before investing in automation. Neither has to look impressive; you’re trying to make the idea easier to question.

Before the test, decide what you want to see. For example, you might ask a few dispatchers to use the sketch to reassign an appointment and look for whether they can find a technician and understand the response without help. Decide what would make you revisit the flow too: if people repeatedly miss the response, you know where to investigate. This is a way to spot problems in the interaction, not a statistical guarantee that the product is ready.

It also helps to be honest about what you’ve learned. If someone can use a sketch, you’ve learned something about the design, but you still don’t know whether a business will pay for the product. Talk to the person making that decision and discuss a concrete next step, such as a paid pilot when the idea is far enough along.

You’ll never remove all uncertainty before building, and I don’t think you need to. Knowing which questions are still open makes it easier to decide what is worth testing first.

What happens when it’s time to build?

Once you can describe what someone should be able to do with the first version, the conversation about building it becomes much clearer. In our example, the dispatcher offers an appointment and sees a response from the technician. Agreeing on a result like that helps you estimate the work and gives you something concrete to check when it’s ready.

If you already have a developer or an existing stack, bring them into the conversation early: there may be a good reason to build on what you have. And if you’re starting from scratch, you can choose tools based on what the product needs and who will maintain it afterwards.

There’s also everything that happens around the build: getting the product online, watching people use it and making sure someone can run it afterwards. If it only works on the developer’s laptop, it isn’t ready to hand over. Agree on where it will run and make sure the people taking it forward have access and instructions to deploy it.

It’s okay for the idea to change

You may start out imagining a full scheduling platform and discover that the most useful first version solves one frustrating part of a phone call. That doesn’t make the original idea any less interesting. It gives you a place to begin, and something real to learn from before deciding what comes next.

If you’re working through those questions and would like another perspective, you can always tell me about your idea.