Making Product Development habitual
Product Development is a mash up of three mindsets; ‘Design Thinking’, ‘Agile’ and ‘Lean’, at the heart of which is empiricism. Continuous product improvement is a cycle of Build-Measure-Learn, where experiments define how rapidly we can get feedback on whether we are making progress. The problem I find is making sure teams have the discipline to track that progress, to make the cycle of experimentation and learning ‘habitual’.
When trying to validate any assumptions we’ve made about the product we’re building, I like to define what our experiments are going to look like using categories of work. These fall into 1 of 4 areas (they don’t have numbers because they aren’t sequential – you can do them in any order):
• Talk to a Customer
• Gather some data
• Prototype something
• Put it in Production (or Make a Change)
These categories of work then form a small defined experiment that segments your intended customers and a narrow slice of your product.
There’s no ‘failure’ when it comes to experimentation, assumptions either get validated or invalidated. This is the heart of the Build-Measure-Learn empirical feedback loop, where the experiment we choose determines how quickly we will complete a cycle.
Making it habitual
The key is to make these feedback loops habitual for a team, a part of their everyday way of working. To achieve that I really like Melissa Perri’s use of The Product Kata (based on the Improvement Kata by Mike Rother). This is a tool that helps the team take small purposeful steps toward solving actual customer problems. A team needs to start with a good question, before it can start to Discover what the answer might be.
One thing I have learned is that the language we use has a big impact on people’s understanding of why we do what we do. I’ve therefore adapted the ‘Product Kata’ to reflect the everyday vocabulary and approach I’ve heard and used with teams doing Dual Track delivery.
Enter The Product Experiment Map
This has resulted in a Product Experiment map that describes/facilitates the key steps of the empirical feedback loop.
• Current Condition: What is the current behaviour (of your user / system)? How do you measure it?
• Assumption: Assumptions that must be true for your product to be successful
• Experiments: pick one of ‘Talk to a Customer’, ‘Gather Some Data’, ‘Prototype Something’, ‘Put it in Production’ (these are all learning activities)
• Learned: Results, observations and insights from your experiment
Here’s how I use it:
1) Download a pdf copy of the Product Experiment Map Product here
2) Print in out in A3 (that’s Tabloid or Ledger for you people in the North of America!), put it on the wall and use stickies to keep track
3) Start with a team Mission and a target Metric you are looking to focus on – clarity and direction for the team (if you aren’t measure it, how can you tell if you’re making progress?)
4) Work through the following steps with the team:
i) Start with a Current condition: in order to improve you need to measure where you are now. This may feed into and baseline your initial target Metric.
ii) Establish the Assumption or obstacle that forms the question needed to be answered
iii) Define an Experiment that will answer that question, using one of the four Categories of Work
iv) Capture what you’ve Learned through running the experiment, what are the results and observations that will feed into your next Current Condition
5) Repeat as often as is necessary as you make continuous validated product improvements!
NOW YOUR TURN
If you use the Product Experiment Map – I’d love to hear about your experiences and feedback.