When validation comes after code: the case of the group purchasing system

1. The starting point

A company in a traditional sector decided to innovate. The founder, familiar with the market, noticed a common inefficiency: suppliers with idle stock and buyers struggling to find good purchasing opportunities.
The idea seemed logical. So, a group purchasing system concept was born — a B2B platform where small manufacturers could join together to buy supplies at a discount, while suppliers could move idle inventory more quickly.
The team believed the problem was real and went straight from paper to code. The product was designed, developed and technically tested. But just before launch, doubts arose:

Does the market really need this?
Would buyers wait to close a collective purchase?
Would suppliers accept selling at a discount to small groups?
The product was ready — but no one knew if it was the right answer to the right problem.

2. The first step: back to the origin of the idea

When I was called to the project, the first thing I did was go back to the beginning. Before any product analysis or marketing plan, I needed to understand where this idea came from and what people believed it would solve.
I talked to the founder, the product team and the technical team. I discovered that the motivation was genuine: there were indeed suppliers with idle capacity and buyers with immediate buying behavior. But the product had been designed without clarity about the depth of these pains — or the real viability of the model.
What seemed like a promising innovation was actually supported by a set of untested assumptions.

3. Structuring the thinking: the Product View

From the conversations, I organized everything the team believed into a document called Product View. It served to turn scattered opinions into explicit hypotheses. The idea was to get the knowledge out of people’s heads and put it into a logical structure.
The first step was to describe the problem the product promised to solve — the inefficiencies between supply and demand. Then we translated what the product did and for whom: a system that connects suppliers of inputs with shoe buyers, allowing collective sales campaigns with limited time and volume.
So far, it seemed coherent. But the Product View is not about describing the idea — it’s about making explicit the conditions that need to exist for the idea to work.
That’s where three fundamental parts of the process came in: success criteria, when it fails and assumptions that need to be true.

4. What success criteria are and why they matter

Success criteria are the indicators that show when the product is truly working — not technically, but in terms of value delivered. They answer questions like:

How will we know this product has succeeded?
What needs to happen in practice for it to be useful to people?

In the case of the group purchasing system, some examples were:

Shoe manufacturers need to accept slightly longer delivery times, since the collective purchase depends on time to close the group.
The offers need to be really attractive in price, term and payment conditions.
Suppliers need to be able to move inventory on a recurring basis, not just sporadically.
The platform needs to keep engagement and prevent people from returning to negotiate via WhatsApp after the first purchase.

These criteria help the team define what success means — because without them, it’s impossible to measure whether the product is on the right track.

5. Understanding “when it fails”

Just as important as defining success is understanding how the product can fail. This part is often overlooked, but it’s essential because it reveals the warning signs the team should watch from the start.
In the case of the platform, we knew it would fail if:

There was little variety of offers — without diversity, the buyer has no reason to return.
Campaigns didn’t close — if the group doesn’t reach the minimum volume, the experience is frustrating.
Users preferred to continue buying directly from known suppliers.
Suppliers didn’t want to pay commission or a monthly fee.
And especially if the collective model created more friction than benefit.

Understanding when it fails is important because it anticipates obstacles. It helps the team see, early on, whether they’re facing a correctable deviation or a structural problem with the model.

6. The assumptions that need to be true

The third layer was mapping the assumptions that needed to be true. They are the backbone of product validation. Every idea depends on assumptions that, if not confirmed, undermine the model. That’s why listing these assumptions is the first step for any discovery process.
In the case of the group purchasing system, some of these assumptions were:

Suppliers really have idle stock frequently.
They are willing to sell at a discount.
Buyers would be willing to wait for the group to close.
Collective buying would be perceived as an advantage, not a risk.
And the fee paid for using the platform (subscription or commission) would be justified by the return obtained.

These assumptions act like a map of truths that the team needs to confirm before investing more time and money. If one of them falls, the whole model needs to be reviewed.

7. Mapping the risks

Based on this information, we identified the two biggest risks of the product:

Value risk – Do people really want this?
Sustainability risk – Even if they want it, is the model financially viable?

Other risks, such as usability and technical feasibility, existed but weren’t priorities at that time — because the product hadn’t even proven that it delivered real value.

8. Going to the field: the research plan

From the assumptions, we designed a qualitative research plan to talk to two audiences: input suppliers and shoe buyers.
With the suppliers, we sought to understand:

If they really had idle inventory.
What caused this inventory.
If they would accept selling to small groups.
And if they saw value in using a digital platform as a complementary channel.
With the buyers, we investigated:
How they buy today.
What they value (price, time, quality).
If they would be willing to wait for the group to close.
And how they perceived the risk of buying from various suppliers.
The interviews brought deep insights into habits, objections and decision patterns.

9. What the research revealed

The conversations confirmed some hypotheses but also dismantled others.
What was invalidated:

Idle inventory wasn’t as frequent a problem as imagined.
Collective buying didn’t fit well with the buyers’ behavior, which is highly immediate.

What was validated:

Suppliers really want to diversify channels and reduce their dependence on representatives.
Interest in discounts is real — even a 5% discount is considered advantageous, as long as the material is good and the delivery time short.
There is a willingness to try new models, as long as they don’t increase bureaucracy.

What remained open:

The monetization model still needed to be tested.
The role of the sales representative within the platform was uncertain — he could be an ally or a barrier.

These discoveries showed that the pain existed, but the solution built wasn’t the right answer.

10. Reframing the product

The goal wasn’t to prove that the product was wrong, but to understand what it could become based on reality.
Based on the evidence, the team realized that the real value was in creating a digital channel to connect buyers and suppliers, not necessarily in forcing a group dynamic.
The focus shifted to:

Reducing dependence on sales representatives.
Making purchasing more accessible and transparent.
And building, in the future, a B2B marketplace model based on trust and recurrence.

11. The final lesson

This case summarizes a very common mistake: the rush to innovate makes many companies skip validation stages.
But it also shows something valuable: even when the product is ready, it’s still possible to go back and learn what really matters.
By reconstructing the reasoning behind the product — understanding what success is, what failure is and which assumptions need to be true — the team was able to reconnect strategy to market reality.
In the end, the group purchasing system wasn’t a failure. It was an experiment that paved the way for a more mature solution, more aligned with real pains and more sustainable for the business.