Coming up with an idea for a digital product is usually the fun part. At that stage, everything feels possible: the platform works, users love it, the business is growing, and you can already picture what it might look like five years from now. The harder part comes next, when the question that actually matters shows up: where do we start? This is where many projects begin to get complicated. Developers are hired too early, features are designed before anyone has asked for them, days are spent debating the product name, and in some cases, founders even start looking for funding before speaking with a single person who might actually use it.
It is easy to understand why. When we have an idea, we want to see it working as soon as possible. But building a digital product is about much more than developing software. First, we need to find out whether the problem actually exists, whether people care enough to solve it, and whether our approach creates enough value to become a viable business. The goal is not to move slowly. It is to avoid spending time and money answering the right questions in the wrong order.
Before building anything, understand the problem
Let’s say we have an idea for a new platform. The natural instinct is to start thinking about everything it could do: user accounts, dashboards, payments, reports, integrations, a mobile app, notifications, and, of course, some kind of AI feature because apparently that now has to be part of the conversation. But before getting into any of that, there is a much simpler question to answer: what problem are we actually solving? And it is not enough for the problem to make sense to us. It has to exist for other people and, ideally, be significant enough that they are motivated to do something about it.
At this stage, we want to understand things like:
- who actually has this problem;
- how often it comes up;
- how they deal with it today;
- what frustrates them about the current solution;
- how much time or money the current process costs them;
- what they have already tried to do about it.
Talking to potential users is far more valuable here than starting to write code. The way we ask questions matters too. “Would you use an app that did this?” will often get a quick “Sure.” It is an easy hypothetical question to answer. Asking how someone handles the problem today, when it last happened, or what they did when it happened usually produces much better information. The answers may be less flattering, but they tell us about actual behavior rather than good intentions.
If the same problem keeps coming up across multiple conversations, we may have something worth exploring. We still have not proven that our solution is the right one, but at least we know we are not trying to solve something nobody really cares about.
You can test the solution before building the whole thing
Once we know the problem is real, we can start showing people how we think it could be solved. This is also one of the best opportunities to save money: we do not always need a working product to find out whether the concept makes sense. A Figma prototype, a few screens, a landing page, or even a simple demo may be enough to get started.
At this point, we are not looking for approval. We are looking for signals. There is an important difference between hearing “That’s a cool idea,” “Let me know when it’s ready,” “Can I try it?” and “How much does it cost?” They are all positive responses, but they do not carry the same weight. The first may simply be politeness. The last means the person is beginning to evaluate the product in a much more concrete way.
It is also worth paying attention to whether people understand the value proposition without needing a fifteen-minute explanation. If the product requires a full presentation just to make sense, the problem may not be the presentation alone. At this stage, we want to know whether the proposition is clear, whether it generates genuine interest, and whether someone is willing to take a small step toward trying it.
This is where the famous MVP comes in
Once there are enough signals to justify building something, it is time for the MVP, or Minimum Viable Product. The idea is simple, even though the term has become unnecessarily complicated over the years: build the smallest version needed to find out whether the idea works in the real world. An MVP is not an excuse to launch something bad or release a product full of bugs. It is about deciding what truly needs to exist now and what can wait.
Imagine we are building a platform for booking services. In our heads, the complete version may include profiles, automated payments, reviews, invoicing, notifications, analytics, mobile apps, and a long list of integrations. But the first version may only need to:
- display the available services;
- let someone choose one;
- submit a booking request;
- confirm that the request was received.
That may be enough to start learning whether people actually want to use the product. Everything else can come later. A useful question at this stage is: does this feature help us prove something important, or do we simply think it would be nice to have? That distinction may seem minor, but it can save months of work.
A lot of projects lose focus because of the familiar “while we’re at it” mentality. While we’re at it, let’s add messaging. While we’re at it, let’s build an app. While we’re at it, let’s add reporting. While we’re at it, let’s integrate five external services. None of those decisions seems particularly serious on its own, but together they can turn an MVP that should take a few months into a project that never seems to end.
The first launch does not need to be a big event
There is also a tendency to treat a product launch like a premiere: pick a date, prepare a campaign, schedule the posts and ads, and build as much anticipation as possible. That may make sense later, but early versions often benefit from something much less glamorous: a small number of users and a lot of observation.
Ten or twenty people using the product in real situations can teach us a tremendous amount. We can see where they get stuck, what they do not understand, which features they ignore, and what they try to do that we never anticipated. From there, we can move to fifty users, then a hundred, and continue expanding as the product becomes more solid.
At this stage, it is useful to watch things like:
- how many people complete the main action;
- how many come back;
- where they drop off;
- which parts they use most;
- which problems keep coming up;
- which type of user seems to get the most value.
There is no need to start with an analytics system that looks like an airplane cockpit. A handful of well-chosen metrics are usually far more useful than twenty charts nobody quite knows how to interpret. It is also important not to confuse acquisition with validation. A thousand signups may look impressive, but if almost nobody comes back after the first use, bringing in more traffic does not fix the problem. It simply introduces that same problem to more people.
The uncomfortable part: getting people to pay
When a product is free, a lot of things can appear to be working. The real test often comes when a price enters the picture. That does not mean every product needs to charge from day one, but there is a major difference between someone saying, “This is useful,” and someone deciding to pay for it.
Eventually, we need to find out, and that brings a new set of questions:
- who is actually willing to pay?;
- which part of the product do they value enough to pay for?;
- how much are they willing to pay?;
- which pricing model makes the most sense to them?;
- how much does it cost to acquire that customer?;
- how much does it cost to support them?
Sometimes we discover that people like the product but the business model does not work. Maybe we are selling to the wrong customer. Maybe the price we imagined does not match the value the market sees. That is still validation, and it is much better to learn it while the team is small and costs are under control.
Once it starts working, the problems change
If users keep coming back, some of them are paying, and usage is growing consistently, a different set of issues begins to matter. Infrastructure becomes more important, support needs better processes, security deserves more attention, and some manual tasks stop being practical. Even then, there is no reason to get too far ahead of ourselves.
Designing with growth in mind makes sense. Building a platform for ten million users on day one when we are still trying to find the first hundred usually does not. The same applies to the team: more people do not always mean more speed, and sometimes they simply mean more meetings.
In general, adding complexity makes more sense when there is a specific reason for it:
- traffic or usage is starting to affect performance;
- manual support is taking too much time;
- repetitive tasks are obvious candidates for automation;
- new security requirements are emerging;
- the current team has a clear bottleneck.
At that point, the investment is responding to something that is actually happening rather than something that might happen three years from now.
Then it makes sense to talk about funding
A lot of founders start here. They have an idea, put together a pitch deck, and begin looking for investors. That is not necessarily wrong, but the more we can learn before that conversation, the stronger the conversation becomes.
There is a big difference between saying, “We have an idea for a platform,” and being able to say that the product is already live, we know who uses it, some customers are paying, we understand our key metrics, and we know exactly what additional capital would be used for. The difference is simply how many assumptions are still sitting on the table.
That does not mean a company needs to be profitable before raising money. Some products require capital much earlier because of the technology, regulation, infrastructure, or market involved. But even in those cases, many questions can be answered with relatively little money, and every question we answer reduces uncertainty.
If we had to summarize the process
There is no single path that works for every product, but a reasonable sequence might look like this:
- Understand the problem.
- Talk to people who actually have it.
- Test the solution without building too much.
- Create an MVP.
- Put it in the hands of a small group of users.
- Watch what they do, not just what they say.
- Improve what is not working.
- Find out whether people are willing to pay.
- Understand whether the economics of the business make sense.
- Invest more when there is a clear reason to do so.
- Consider outside funding when it is clear what that capital will help accelerate.
The point is not to follow this list like a rigid recipe. Every product will have its own circumstances, but the logic behind the process is worth keeping: do not spend a lot of money to answer a question you could have answered much more simply.
Early in a project, it is completely normal not to know exactly what the final product will look like. Users, the market, and what we learn along the way will change a meaningful part of what we originally imagined. The first versions are not there to prove that we were right from the beginning. They are there to help us figure out which parts of the idea are worth developing further.
If we can do that without burning through the budget or exhausting the team before reaching the market, the product is already starting from a much healthier place.
