Your approach to validation is broken

There's been tons of buzz about "validation" in the past several years. Lean and design-centric approaches such as Design Thinking encourage entrepreneurs to build things and incrementally validate them, correcting course as necessary. When I think about how, at the beginning of my career, we worked for months before validating anything, this increased focus on getting feedback from those who will use our product is most welcome. However, this obsession to validate what we build has, in practice, at least a couple of massive flaws that I'd like to highlight.

Firstly, I see almost exclusive focus on end users. While the people who directly use our products are important, the fact is that they are just one type of stakeholder. This point is a little less obvious in the Internet-based consumer space, where the user and economic buyer are the same and the buying process is much, much simpler than in the enterprise space. An individual consumer paying a couple of bucks for an app may (often?) make a decision based on little more than impulse. Those toiling away in the complex problem space where millions may be invested in a solution and with a fiduciary responsibility to stockholders tend to have buying processes that are dizzyingly complicated. We, as product managers must, therefore, validate ideas not just with end users, but with most or all stakeholders. Have we expressed our value proposition in a way that resonates with executive leadership? Do we have the right business model? Does our pricing model provide enterprise purchasing departments with the required financial flexibility? Overlooking these types of questions for these stakeholders may result in massive failure of a product that delights its end users.

Secondly, I find that most of what's written about validation focuses on the solution space. The idea is to build something quickly, test it, and "pivot" while it's still relatively cheap to do so. The problem is that we rush through our analysis of the problem space without validating that we clearly understand our stakeholders' key pains. Just like in solution validation, we rarely get it right on the first pass. Often, our understanding comes from anecdotal evidence ("I was talking to a customer the other day…") and flawed intuition. The first thing we should validate with stakeholders (not just users), is that we truly understand their problems. And here I'm not just talking about the problems we intend to solve. Understanding stakeholders' pain broadly helps us uncover acute pain we may have overlooked and helps put the problems we intend to solve in proper context. Laser-focused on our objectives, we begin to assume we are solving stakeholders' most critical problems although in many cases our solution, although important, is way, way down on our stakeholders' list of most pernicious issues. Before we even conceive of a solution (much less validate it), it is wise to validate our understanding of the problems that are holding our stakeholders back.

Problem validation entails the following steps:

1. Open, problem-oriented discussions with all important stakeholders
2. Distilling problems into a concise, consumable form
3. Validating our understanding of problems directly with stakeholders
4. Adapting our expression and understanding of problems as necessary

Just as fixing a prototype is far less expensive than fixing a shipping product, correcting misinterpretations of problems is much cheaper that reformulating a misguided solution, even as a prototype, later. I've blogged previously about the "Problem Profile", a valuable tool for considering problems holistically and validating them with stakeholders.

Your challenge is to resist the urge to validate too late, once you've already invested in the solution space. You will find that problem-centric analysis will yield insights that will never come from a solution-oriented approach.

What is your experience? Do you have practices in place to ensure you have a grasp of stakeholders' problems before you begin trying to conceive of and develop solutions?

You can read more about my strategic approach to product management on my site.