Product Launches: Best quality product or rapid product iteration?

If you have watched any of the rocket launch sequences or more recently the touch-down sequence of the Mars rover, the vibe is unmissable. Almost everyone is tense, they all feel the “now or never” moment, and if it's successful everybody jumps with joy and happiness — a feeling of great accomplishment. If your product or feature launch feels like the above, chances are you are doing the product the wrong way.

At the other end of the spectrum if you are doing a lot of feature releases with little or no-impact to users — motion != progress — , inefficiently utilizing the most scarce resource — engineers time — chances are you are doing the product the wrong way.

So how does one do product? An experiment conducted in a school may provide answers to that question.

A high school teacher once held an experimental pottery class where the class was divided into two groups — the first group was tasked to build the best pot possible and would be graded on the best quality pot while the second group was tasked to build as many pots as possible and would be graded on the number of pots made. Guess which pots turned out to be of better quality? it was from the quantity group.

Why did this happen? I can hypothesize below 2 problems with the quality group…

1. Fear of not getting something of high quality.
2. Not knowing what high quality would mean.

Products/features that take too long to launch also suffer from these problems.

Sure, iteration looks better but how do you find that balance because remember resources required for building product/features are way more expensive than the clay, and the output far more important than a pot.

Below are some of my key learnings…

1. Farm for dissent: You have a product/feature release in mind that you are hypothesizing may have a significant impact on user journey or on a certain metric. Take that idea to as many people in the organisation as possible and see what your colleagues think of it.
2. Sketch the journey: You don’t have to be an artist, just keep going through the steps. Try to get a grasp of all the tentacles associated with the journey. Get hold of your designer buddy and get him to make 1 or 2 screens.
3. Experiment: Elements of the journey that you can do an A/B go ahead and carry out those. For others do a limited user group testing. With the results — again farm for dissent.
4. Slice the journey: Once you have arrived at what needs to be built, slice the journey to see if it can cover 1 user 1 product 1 application 1 module as atomic as possible. Be careful — every slice should be large enough to generate value.
5. 1 week sprints: Try to target every sliced journey to be completed in a sprint. May not be production ready but ready enough for demo on Thursday.
6. Strong feedback loops: Ensure that you setup strong feedback loops for you to gather data from this sliced journey. This is important for you to “Land and expand”
7. Visual Dashboards: Ensure success metric dashboards are in place with all important cuts in time period, users, products — to be reviewed weekly, later moved to monthly and quarterly reviews.
8. Setup ears: Once the product has covered all planned slices ( covering all users, products, applications and modules), ensure that there is process setup to understand the edge cases and a rise or fall in these edge cases.