top of page
kmcgourty2

Great we have a hypothesis, now what?

Let’s assume your innovation and NPD team has gone through the process of creating a hypothesis or set of hypotheses in the form of “job-to-be-done”  statement explaining who has the job, what they are trying to get done, and the context/situation in which the job occurs.

Chances are you have gathered preliminary information to provide some level of validation that your hypothesis has merit – but there are still too many unknowns and questions needed to be addressed before launching into a full blown development effort.

After all most of the data you have collected comes from secondary sources  providing what seems to be initial validation that there is interest out there and potentially a good market opportunity (i.e. the business idea is “viable”).

Mostly likely through gut feel and limited user feedback you have a sense that there is indeed a job out there that can be done better (perhaps you and your team would “hire” the product to do your own jobs better – or you informally talked to potential job executors – i.e. the product is “desirable”).

And your development team has a reasonable level of confidence that they have or will have (through learning and/or partnering) the means to execute the concept (i.e. the product is “feasible”).

But if you build it will customers buy it?  That is what  management will be asking – and hopefully they are open to exploring the idea further,  but they aren’t ready to bet the ranch on a raw concept – they need more proof that the concept is real.

For all practical purposes in the early stages of market adoption your market doesn’t exist yet, thus we shouldn’t expect to get a lot of practical information by asking yet-to-become customers “what they think” because the concept simply won’t compute in their minds – they will either say “yes that’s a great idea – when can I have one?” (encouraging but don’t confuse this with confirmation) or “why would I want that?” (can be discouraging but not necessarily evidence the idea won’t fly).   So where do we go from here?

It’s time to put the hypotheses to test with real people in real situations to see if our underlining assumptions are valid and discover real insights to what customers really want even though most of them can’t articulate it because the knowledge we seek is tacit (unspoken and hidden) and we need to extract that information using tools that don’t either bias our test subjects (i.e. trying to sell them something they don’t need or want) and/or equally problematic – biasing ourselves with pieces of evidence that we cherry pick to falsely confirm our assumptions (also known as “cognitive bias”).

There are many tools available to test our hypotheses ranging from prototyping and “presenting” the concept to potential users for their reaction to formal voice-of-customer research including ethnographic studies (i.e. observing real people doing real things/jobs at work and home).Choosing the right research tools and methods in the early stages of the innovation cycle is a critical decision innovation and development teams need to make and depends specifically on the goals and objectives the team is trying to achieve with their research. Remember our goal in managing the innovation process is to test early, often and cheaply – not all research is created equally nor cost equally!

Prototyping – including early stage mock-ups (i.e. 3-d models) – is definitely a useful practice and I highly endorse the practice – but there are limitations and prototyping without a formal research plan won’t yield the kind of results we need to validate business assumptions – there needs to be a formal plan on how to collect data, analysis and interpret the data, and derive useful and actionable information from it. Just waving mock-ups randomly in front of people isn’t a plan for success.

Another potential problem with prototyping a solution is that we have made a critical leap-of-faith (and sometimes we must make this leap to move forward) that there is indeed a “problem” out there worth solving and the prototype represents the solution. Okay I realize this is a bit of a chicken-and-egg conversation – but that’s the gist of why we need to do some exploration using a formal – but not costly in the grand schemes of things – market research to verify that we have indeed identified a “job-to-be-done” that is currently not being done very well by job executers (the people who have to do the job) as expressed by their level of satisfaction in achieving their desired outcomes.

What we are really talking about is “pre-totyping” (I believe this term is credited to Alberto Savoia – http://www.pretotyping.org  and not exactly the same meaning I use here) where we test  to better understand the job-to-be-done hypothesis and discover if the business concept makes enough sense to move forward, and/or refine the concept or perhaps even redefine the concept (plan b) or dismiss it as “not a good opportunity” for us.

Next blog I’ll provide an example hypothesis and discuss how to use VoC research to validate and shape a concept into a winning product.

Cheers!

Kevin

2 views0 comments

Comments


bottom of page