Product validation sounds obvious until you watch how most teams actually make product decisions.
Someone has a strong opinion. A roadmap window opens. Design starts filling screens. Engineering estimates the work. By the time anybody asks users, the organization is already emotionally invested in the answer. At that point, the work is no longer validation. It is damage control.
That is the reason I do this work.
I have seen teams spend years building something people do not understand. Not because the team was weak. Not because the technology was bad. Because the core direction was never tested with the people who were supposed to use it.
The engineering-company case study is the cleanest example. Two years of development. Launch-day confusion. Then a user showed up with their own slides, mockups, and a better flow. They had been thinking about the problem for years. Nobody had created a process where that knowledge could surface. One comment from the right user changed the direction of the product and exposed how much waste had built up around untested assumptions.
That is what product validation consulting is really for. Not polishing concepts. Not making research look respectable. Creating a decision-making process where real user signal shows up before the expensive commitment happens.
What gets validated
Usually, not the whole product.
The useful question is narrower:
- Is this workflow understandable?
- Does this feature solve the problem we think it solves?
- Is this the right ordering of steps?
- Are we targeting the right user and the right use case?
- Is the value proposition strong enough to justify building this at all?
Teams often come in asking for “feedback on the concept.” That is still too vague. Good validation work sharpens the question until it becomes testable.
At Admicom, the issue was not “do users like dashboards?” It was whether the product family could move toward a clearer dashboard concept that helped people switch contexts without getting lost. In five days, the team had a user-tested prototype and a cleaner product direction. That is the power of focus. The sprint did not solve every future product decision. It solved the decision that mattered now.
What usually goes wrong internally
The information is already in the organization, but it is trapped in the wrong places.
Support hears the recurring friction. Sales hears why deals stall. Customer success hears what people actually expected. Product sees tickets and requests, but not always the deeper pattern behind them. Leadership sees the strategic pressure, but not the daily reality of use.
Without a structured validation process, those perspectives never become one shared picture.
Instead, teams get:
- fragmented opinions
- design work done too early
- overconfidence from inside the building
- false certainty because nobody wants to slow momentum
That is why I prefer working with a specific decision and a cross-functional group. The output is not “research says maybe.” The output is “we tested this, here is what happened, here is what changes now.”
What the work looks like
Sometimes it is a one-day sprint around a single blocking question. Sometimes it is a three-day or five-day sprint with stakeholder alignment, prototype work, and user sessions. The format matters less than the sequence:
- Frame the decision correctly.
- Identify the riskiest assumption.
- Build the lightest useful thing to test that assumption.
- Put it in front of real people.
- Decide while the evidence is still fresh.
The reason this works is not speed for its own sake. It works because it compresses the gap between assumption and reality.
FCG / Kuntarekry is a good example of the organizational side. Eleven people. Different functions. A service used by 1.5 million people and handling half a million applications a year. The design sprint did not just produce a validated prototype. It aligned the room. That alignment would have taken months through ordinary committee behavior.
What you leave with
You should leave with something sharper than “insights.”
You should leave with:
- a tested concept
- evidence your team can replay and refer back to
- a smaller, clearer build scope
- a more honest understanding of user priorities
Sometimes the biggest win is discovering what not to build. That sounds negative until you price the alternative. Killing the wrong idea early is one of the best ROI moves a product team can make.
This is also why I do not position validation as a decorative discovery phase. It is operational risk reduction. It is how you avoid turning conviction into sunk cost.
Why bring in an external consultant
Because internal teams are rarely short on intelligence. They are short on distance.
You cannot be objective about your own product politics when you are living inside them. You also cannot facilitate a hard conversation well if you are personally attached to one of the outcomes.
An external product validation consultant changes that dynamic in three ways:
- I can frame the uncomfortable question without defending past decisions.
- I can facilitate a room where different functions are heard without the usual hierarchy taking over.
- I can move from ambiguity to prototype quickly because I have seen the pattern before.
That outside perspective is not about “fresh ideas.” It is about removing the friction that keeps teams from hearing what is already true.
If the next product decision is expensive, validation is not extra work. It is the work that prevents the wrong investment.
