Most new products fail.
That is the stubborn background condition of the modern business. Teams work hard. Companies invest real money. Customers get interviewed. Research gets done. And then a disappointing percentage of what gets built either underperforms or quietly disappears.
I have spent more than twenty years in product and innovation leadership, and that reality has never escaped me.
The question I kept coming back to was not whether teams were doing customer research well. Many were. The question was why so much of it failed to produce the thing that actually matters: a successful new product.
The research gets done. The product still misses.
Here is what I’ve observed…
A team conducts customer interviews. The interviews are reasonably well run. Or they hire an outside firm. Either way, the findings get synthesized and presented. Leadership nods. The initiative moves forward.
And then, somewhere between the research report and the product decisions, something breaks down.
The product still gets built on assumptions, often led by the loudest voice in the room. Features can become prioritized based on what the team found interesting rather than what customers most needed. The positioning, if done at all, misses because the real job the customer was trying to do never got clearly named.
That gap between evidence collected and decisions made with real conviction is one of the most expensive problems in product development. It does not show up as a research failure. It shows up as a product that underperforms in the market, and a team that cannot quite explain why. In practice, they move on to other positions and there’s little institutional learning.
-
-
The PM’s version of the same problem
Product managers feel this differently than executives do, but they feel it just as acutely, if not more so.
You did the work, or your hired a market research firm. You’ll have interview notes. Maybe survey data. Each source captured something real.
But none of them quite add up to a clear answer.
Which customer problems actually matter most? Which findings reflect durable needs versus isolated frustrations? What can you defend in a prioritization meeting, and what are you still guessing at?
Lots of evidence, but confidence is low for making the strategic decisions that a product manager must make. So you make judgment calls, present them with more certainty than you actually feel (gulp), and hope the product validates what the research only half-supported.
That is an uncomfortable place to work from. It is also avoidable.
What was missing was a way to see the evidence together
The problem is rarely a shortage of customer information.
It is that the information is available in different forms, from different sources, at different times, and stays that way. Each study sits in its own report. Each data point gets interpreted on its own terms.
The organization within the company has information, but no shared structure for understanding what the evidence says collectively. So every initiative starts from scratch. Knowledge does not compound. The same questions get asked again. The same gaps go unfilled.
Each project becomes an island. And the organization, despite all the research it has done, never quite gets smarter.
I had never seen a practical method that solved this in quite the way I have done in my own practice. Let me share, for the first time, what that is.
The Signal Translator
The Signal Translator organizes evidence from different sources around a common structure: the outcomes customers are trying to achieve while doing a job. Using Jobs-to-be-Done as the foundation, their success criteria become the shared language that connects everything.
An interview is still an interview. A survey result is still a survey result. Past studies and internal data sources each carry a unique perspective. The Signal Translator does not flatten those differences or pretend they carry equal weight.
But when different sources connect to the same underlying customer criteria, patterns that would otherwise stay hidden become visible. Apparent contradictions start to make sense. Older research informs newer work. Differences across customer segments become clearer and more actionable.
Most discovery works like this: a question gets asked, research gets done, findings get presented, and the project closes. The next initiative opens with a mostly blank page. A pile of independent projects, each starting from scratch.
The Signal Translator turns that into a system. Because every piece of evidence connects to the same underlying customer criteria, learning from one project carries into the next. It gets tested, confirmed, challenged, or refined over time. The organization stops running disconnected initiatives and starts building something that actually accumulates.
The result is confidence that builds over time, holds up in a meeting, and gives a product team a real basis for the choices it makes. That is a different thing than finishing another research project. That is genuinely knowing your customers.
The book also teaches the discovery process itself
The Signal Translator is only as useful as the evidence placed into it.
That meant DISCOVER also had to address how customer discovery gets done well: how to plan it, how to recruit the right participants, how to conduct interviews that go beyond surface answers, and how to structure what you learn so it stays useful. A substantial portion of the book is devoted to exactly that, with enough practical depth that a team new to customer interviewing can use it as a working guide.
But the synthesis method is the part I had not seen done before. That is what the book is built around.
I tried something fun: I told it as a story
I always loved the old manufacturing book, The Goal, written as a novel to be a bit more interesting than a conventional methods book.
I adopted a similar approach, with a narrative-driven book, exploring how customer discovery rarely unfolds cleanly. I wanted to share the reality of the difficulties through a story. After all, in real life, a bit of chaos happens. Teams disagree. Stakeholders apply pressure. Findings conflict. The right next step is not always obvious.
DISCOVER follows Ryan Carter and the team at Big Sky Outdoors through a real discovery challenge. The methods appear when the team actually needs them. The story gives the reader a chance to experience the difficulty, and consider why these methods are helpful, not just read rules about it.
What I hope it does
I wrote DISCOVER for executives and product managers who need to walk into decisions with something more than a collection of interesting quotes. For innovation leaders who are tired of watching good research fail to change what gets built. For executives who have approved the research budget and still watched the product miss.
The customer interview is not the destination. It is the beginning.
The goal is to understand customers clearly enough, and structure that understanding carefully enough, that it actually changes what you build and improves the odds that what you build succeeds. Not just on the next initiative. On every one that follows.
From a series of projects to a system.
DISCOVER: From Customer Noise to Product Signal launches on July 12.