From product vision to action - taking leaps of faith

Ok - so you have a compelling vision for your product. It's what users want, it will make the world a better place, will differentiate your product from competition or existing solutions and will make you boatloads of money.

You have your version of "1000 songs in your pocket" -- the famous tagline from the original iPod launch in 2001

Now what?

How do you translate that vision into action? How do you go from that catchy shingle to something you can start doing on Monday morning?

 You take leaps of faith

1. You figure out what would need to be true for you to achieve that vision. What hypothesis do you need to validate, what capability do you need to build to make the vision a reality.
2. Then you figure out how much uncertainty there is on each hypothesis, and what the impact would be for the ultimate attainment of your vision if the hypothesis was wrong. 
3. Then you get to work on validating the hypotheses what have the highest uncertainty and highest impact to goal attainment. 

 Simple?

 Lets take the example of the "1000 songs in your pocket" vision for the original ipod

(CAVEAT -- these thoughts below are completely ILLUSTRATIVE - for the purposes of this example. I have no inside knowledge of the deliberations inside Apple. There is discussion in the public domain about some of this, which I have used as an inspiration for the illustrative example below e.g. this and this)

So, in this hypothetical scenario - what were the hypotheses that needed to be true for Apple to attain this vision for the ipod?

1. We can find a hard drive that can accommodate 1000 songs in a small, portable form factor (Hard Drive) - remember this did not exist in 2001
2. We can transfer 1000 songs to this hard-drive fast (Transfer Speeds)
3. We can create an application for users to manage their song collection on their PC (Desktop application)
4. Battery life for this contraption will be acceptable (Battery life)
5. Users actually want 1000 songs in their pocket (User needs)
6. We can manufacture this whole system at scale (Manufacturing)
7. We can sell this at a profitable margin / price to users (Pricing)

 Lets plot these hypotheses on the "uncertainty" and "impact of being wrong" map

In this ILLUSTRATIVE example - a hard drive that had enough storage in a specific form factor, and the transfer speeds of getting the data on to the hard-drive would be the most critical pieces for Apple to figure out first i.e. these are the A+ problems. If either of these didn't work out - then the entire project would be doomed. On the other end of the spectrum - building a desktop application and manufacturability were the "easiest" parts of the whole problem (relatively speaking) i.e. the B problems and should be considered as tasks, and something you already have the capability and expertise for.

This framework for prioritizing problems is also helpful because often teams (especially immature, low performing teams) have a tendency to attack the low leverage B problems first (low impact, low uncertainty), just because they have the most certainty around them and they know they can ship something. In-fact - the leverage in achieving breakthrough results is in going after this high impact, high uncertainty problems first - which can be hard.

Now - things don’t need to be this dramatic for software products. Typically, and unless you have a once in a generation taste maker like Steve Jobs on the team - user needs tend to the thing that is the most uncertain and obviously the highest impact. This is what you need to start testing with early prototypes, survey's and even your initial MVPs. Or it could be some sort of critical capability that you need to deliver the validated solution, and you need to figure out how to build or buy it.

Either way - going through the exercise of clearly stating your ALL the hypotheses that need to be true to ship a product, and then classifying them into A+ / A / B problems helps to focus the team's energies on areas with highest leverage.

Why you should believe me: I lead product, marketing and revenue for CreditWise from Capital One. We have an awesome team - and have more ideas than we have capacity for. The framework laid out above helps to keep us focussed.

All views, opinions and statements are my own