How to Validate a New Product Opportunity in an Existing Product

Your onboarding data lights up a segment you never targeted. Retention is strong, intent is high, and someone senior wants to show it to the whole company by Friday. That is the exact moment most teams make their most expensive mistake: they start building. The better move is to validate a new product opportunity the slow-looking way, which turns out to be the fast way, before a single engineer touches it.

I recently sat down with a Senior PM at a B2B SaaS platform who lived this. Their onboarding flow asks new users what they came to manage. One answer, CRM, kept showing the strongest three-month retention and near-highest intent of any segment, second only to the platform's flagship use case. The surprise was that the platform was not really a CRM, just a flexible system people were bending into one.

How do you validate a new product opportunity inside an existing product?

You run cheap, staged validation before you build: re-verify the data, interview the segment's extremes, test the value with packaging, and only then build something deliberately thin. Building is the last rung on the ladder, not the first.

The hardest part is emotional, not analytical. A promising signal creates a wave. A senior leader gets excited, the room gets excited, and you feel yourself being carried toward a commitment you have not earned yet. Part of the job is to be the person who says "not yet, let's validate in steps" while everyone else is ready to sprint. Hold the excitement and the doubt at the same time.

The ladder that PM used, in order:

1. Re-check the data, several times. A wrong cut is worse than no cut.
2. Survey the segment. Cheap context on why they showed up.
3. Interview the extremes. The users who succeeded and the ones who quit.
4. Run a reverse-funnel test. Push what you learned back up to acquisition.
5. Build thin, on purpose. Ship something you know is not good enough.

Why re-check the data before you chase the opportunity?

Because a wrong segmentation cut sends a whole team down the wrong path, and unwinding that is expensive. Re-run the cut several times before anyone acts on it. This team had been burned by a bad cut before, so they treated the number as a hypothesis, not a verdict.

Once the data held up, they got specific about who these people were. They sent the segment a short survey, around fifteen questions, which is something any company can do regardless of size. Then they built an interview script from the answers and ran fifteen depth interviews with users from that pool. The move that most teams skip: they studied both extremes. They asked the users who succeeded why it worked, and they hunted down the users who genuinely tried the capability and then chose to stop. Users who never really tried got set aside. The ones who tried and quit told them exactly what was missing. From there they could ask whether a particular company profile succeeded or failed, and build a hypothesis around it.

How do you validate the value without building anything?

You repackage what already exists so the product feels built for the new use case, then watch whether the segment responds. Language, pricing framing, and help content all move faster than code. This is where a small team beats its own resource constraints instead of losing to them.

That PM's team could not out-build the incumbents. So they changed perception rather than the product. The main screen started speaking the new use case's language. The pricing page wrapped existing features in that language so users could compare against real competitors. The help center surfaced articles for the new use case, backed by scrappy how-to videos recorded over a screen share. Nothing new was built, and it worked. In one case I worked through with a Senior PM at a B2B SaaS platform, a team of roughly one and a half engineers validated and grew a new CRM product line for more than six months, mostly by repackaging the existing product rather than building new features.

The lesson for your roadmap: many users want something they can understand and adopt without a manual rather than the most sophisticated experience, and that alone moves their platform choice. Testing that with packaging is the muscle I train product teams to build in discovery workshops, because it is far cheaper than testing it with a sprint.

What is reverse-funnel validation?

Reverse-funnel validation is taking an insight you learned deep in the product and testing it at the top of the funnel, where the traffic is. Bottom-of-funnel learning, from interviews and usage, is the cheapest thing you own to validate on landing pages and ads. Most teams only ever push information down the funnel. This runs it the other way.

The interviews had surfaced one value that consistently separated the users who stuck: customization. So the team took that exact word into their campaigns, landing pages, and ads. The ads immediately performed better, which was a second, independent signal that the opportunity was real. That same PM pointed out that even a tiny startup has on the order of 10,000 people exposed to its ads, which is enough traffic to get a fast read on a new positioning message. You do not need a big audience to run reverse-funnel validation. A landing page or a short video that either earns comments or does not will tell you plenty by next week.

There is a quieter version of this too. Use your users' own words. When people describe the value in an interview, take their phrasing into the product, the support articles, and the marketing, instead of the internal terms your team defaults to. Their words carry more weight than yours, and they close the loop between what you learned and what you say.

Be honest about what this validates. A message that pulls people in proves demand for the promise, not that you can keep them once they are inside. A positioning win still has to be paired with the delivery test below.

When you finally build, how thin should you build?

Build thin enough that you know it is not good enough yet, so the market tells you what "good enough" means. Ship a rough version with an obvious feedback path, then iterate on what comes back. The reframe is small but real: not "build something and learn," but "do something, learn, and only then build."

When that team did build, the first version skipped the WhatsApp-and-payments machinery the big CRMs ship and served the one specific, basic need their interviews kept surfacing, which a tiny team could serve well and keep serving for a long time. They shipped it knowing it was incomplete, put a large feedback button on the first screen, and let real responses tell them what to build next. No matter how right you feel, your first cut will not be precise enough, and buying that precision up front costs more time and money than it is worth.

One more constraint shows up here: you will need other teams to lend you engineering, and they are deep in their own priorities. Treat it as a trade, not a favor. Show the other team how a small change to their feature also creates real value for their users, with actual usage stories, not a slide. Getting help by making the ask serve the other side is product management.

Key takeaways

• Validate a new product opportunity in stages before you build: re-check the data, interview the extremes, test with packaging, then build thin.
• Re-check the data several times. A wrong segmentation cut is expensive to unwind.
• Package before you build. Language, pricing framing, and help content validate value faster and cheaper than code.
• Run reverse-funnel validation. Take a bottom-of-funnel insight and test it in ads and landing pages, where the traffic already is.
• Build something you know is not good enough, ship it with an obvious feedback path, and iterate.

If your team keeps jumping from a promising signal straight to a build, that is a discovery habit worth changing. Book a discovery workshop with RE.FOCUS and we will pressure-test one of your live opportunities together, or read more field notes on the blog.