It’s typical among Lean Startup adherents to speak of “validation” and “customer development”, as part of the rapid iterative build-test-learn cycle inherent to the Lean philosophy. Formed an assumption about the customer? Validate it. Got a new hypothesis about the problem? Validate it. Exploring some delivery tactics via a fake website? Validate it.
Validation is the heart and soul of Lean, pushing the product team brimming with self-created enthusiasm “out of the building” to speak with actual people to gather their feedback, reduce risk, and ensure success before moving on to the next decision point.
However…there’s a small problem with the word “validation“.
Looking closely, it implies an exactitude of guaranteed correctness, that you’ve got the right answer, so you can successfully move forward. You can almost hear the stamp going “thunk” on the paper, with the certification of proper results, as the team smiles, knowing that they “got it”. This attitude presupposes a correct definitive answer, can constrain the ability to see fringe ideas, and inhibits openness to new possibilities unforeseen during testing.Â
As anyone knows who has gone through not just design, but also the fuzzy front-end of product innovation, there are no predictable guaranteed outcomes, due to the dazzling array of uncertain variables and risk factors beyond your control.
Besides, all data (quant or qual) must be taken with grains of salt due to the contexts of the feedback sessions. Therefore, instead of singular “validation”, it’s preferable to break down this nearly ubiquitous phrase into the following concepts, that map to primary phases of a user-centered design process, as shown below:
After understanding targeted customers and contexts, then Verify your personas and scenarios with actual users and other stakeholders to ensure accuracy of perceptions. (Like the old adage, “trust but verifyâ€)
After creating diagrams and taskflows/wireframes, then Assess your models of data interaction and information architecture with Product Managers and Engineering leads for completeness of capturing and representing all the relevant tasks and objects and functions, and such. This can also be assessed with targeted users with proper framing of the activity and what’s to be shown.
After producing some solutions, then Evaluate such visualizations and/or prototypes (of varying degrees of fidelity) with targeted users through properly framed feedback sessions to catch usability problems, missed features, and other forms of improvements.Â
These terms point to a more nuanced sense of “validating” what’s appropriate for your targeted market and context, as an ongoing process of learning and understanding and thus, innovating. It’s going beyond simply a convenient stamp of approval (“validation”) but creating a dialogue of realization. Inventing solutions is a journey of seeking, not a singular moment of final absolution. It takes several rounds to get it moving on the “right track” towards satisfying users ;-)Â