Product Discovery: why finding the right solution matters more than development

In IT, speed is often seen as a good thing: move from idea to code and ship as quickly as possible. But speed won’t help if you’re heading in the wrong direction. You can build a product perfectly and still end up with something nobody needs.

That’s why product discovery comes before development. It helps the team understand the problem, test hypotheses and avoid expensive mistakes before writing code.

What is Product Discovery?

Product discovery is about finding and validating the right product solution before development starts. The team studies users, their problems and the context around how they use the product to understand what’s actually worth building.

Here’s an example from one of our projects:

• the problem — suppliers were arriving late with deliveries to the Emex warehouse;
• the users — delivery drivers, some of whom were making this type of delivery for the first time;
• the context — the terminal was outside, and people were using it on the go.

These details directly affect the product. When someone is standing at the warehouse, surrounded by boxes, with a queue behind them, the interface needs to work differently from a web form used at a desk.

In practice, the product discovery process answers two questions: “What should we build?” and “How do we know it’s worth building?”

To answer them, the team conducts interviews, analyses competitors and processes, maps customer journeys, creates prototypes and tests user flows. In other words, we look at how people actually behave instead of inventing solutions in a meeting room.

The discovery phase isn’t a one-off research exercise at the beginning of a project. It’s a way to make product decisions based on evidence rather than opinions.

What does Product Discovery help you validate?

The main purpose is to test hypotheses. Businesses often come to us with a solution already in mind: “We need an app”, “We want a marketplace”, “Build us a new system”. But at this point, it’s still just an assumption.

For example, one client came to us with an idea for a cybersecurity start-up. Before investing tens of thousands of dollars in development, it was important to find out whether security professionals would actually use a service like this and whether it could help them quickly identify vulnerabilities in their infrastructure.

We test ideas like this step by step:

1. Form hypotheses.
2. Evaluate and prioritise them.
3. Test them using quick, low-cost methods.
4. Explore the hypotheses that pass the first round in more detail.
5. Build an MVP and test it with users.
6. Analyse the results and decide what to do next.

Discovery helps us understand:

• whether the problem actually exists;
• how important it is;
• how users solve it today;
• whether they’re willing to change the way they do things today;
• whether the new solution will be valuable to them.

Product Discovery also reduces risk. Development is the most expensive part of the product cycle. Testing hypotheses, user flows and prototypes before writing code makes it much cheaper to find and fix mistakes.

Tools we use during Product Discovery

We combine several methods to test hypotheses.

Interviews

In-depth interviews help us understand real user scenarios, problems and motivations. What we learn can be very different from what the business initially assumes.

For example, while working on Sirmione, we used several survey formats and uncovered the central idea behind the brand — “Flowers as art”. It became the foundation for the brand identity and its future development.

CJM (Customer Journey Map)

A Customer Journey Map shows how users interact with a product: the steps they take, their emotions, barriers and decision points. It helps identify where the product can create the most value.

Prototypes

From simple diagrams to clickable designs, prototypes let us test a solution before development starts. Getting critical feedback at this stage is much cheaper than discovering the same problem after launch.

Together, these methods give the team a much clearer picture of the problem and a stronger basis for product decisions.

What do you get from Product Discovery?

After the discovery phase, an abstract idea becomes a clear product concept with user flows ready for development.

For example, while working on the Smartbe service, we defined:

• A validated concept. Smartbe is a shop built around chat: the user describes what they need, and an expert helps them choose the right parts.
• The users. The main audience is non-professionals who find it difficult to choose parts themselves and are worried about making a mistake.
• The core user flow. The user opens the chat, describes what they need, and an expert selects the parts, builds the basket and helps place the order.
• Feature priorities. Chat, an in-chat basket and a single workspace for the expert became the priorities. A complex catalogue and additional services were left for later.
• The MVP scope. The first version only needed chat, parts selection, a basket and checkout.
• Defined expert workflows. We designed the experts’ workflows and interface in advance, reducing uncertainty and making employee training and the service launch easier.

This is how Discovery turns “let’s build a service” into a concrete plan: who the product is for, how people will use it and which features the MVP actually needs.

Why skipping Product Discovery can get expensive

Skipping research might look like a way to save time. In practice, it often does the opposite:

• Unnecessary features. The team builds a complex account area when users only need a quick way to place an order.
• Longer timelines and higher costs. New requirements emerge during development and require additional resources.
• Rework. Real user scenarios turn out to be different from the team’s original assumptions.
• Messy priorities. The team develops secondary features before validating the product’s core value.
• Low conversion. After launch, users don’t understand the product’s value or don’t come back.
• Expensive redesigns. Problems in core user flows have to be fixed after release.

Without product discovery, decisions are based on assumptions. Every new piece of information can lead to changes, rework and technical debt. The business ends up paying first to build the product and then to fix it — and may miss its window of opportunity in the market.

The point isn’t that Discovery matters and development doesn’t. Without understanding what users actually need, development becomes an expensive way to test hypotheses.

A solid product discovery process tests the idea against reality before most of the time and budget have been committed.