Ramon Harrington of Vistaprint on Choosing What Not to Build

• 0:30 Introductions
• 1:05 The Hatchery as an innovation lab focused on identifying new opportunities for Vistaprint
• 1:43 Ways to differentiate good ideas from bad ideas
• 2:05 Using customer surveys and customer feedback metrics – customer satisfaction
• 2:25 Using money as an indicator – customer spend
• 3:05 The importance of meeting customers in person to validate ideas
• 3:28 Putting engineers in front of customers and having conversations
• 3:53 The need to explore the customer reactions and pull pieces from different ideas together
• 4:12 Overcoming the “pet feature” response by ensuring you talk to many different customers
• 4:35 The importance of the engineer or designer remaining detached and not holding on to a feature because you came up with it
• 4:48 Most of the ideas will fail so being able to let go is crucial
• 5:07 Becoming comfortable getting honest (and sometimes unpleasant) feedback
• 5:35 The waste that happens because of unused features
• 5:51 Be prepared to launch before you’ve built everything you think the product needs in order to avoid building features people don’t want
• 6:20 This approach focuses the teams attention on ensuring what is built is good
• 6:35 From the customer perspective the UI is the most important aspect
• 7:08 Most of what is needed is unclear, don’t assume that it is more predictable than it actually is
• 7:25 In engineering there is often a “right” answer, in product identification there isn’t – you don’t know until you try it out
• 7:52 Telling a story of how this experimentation approach can work in a real product
• 8:38 Design the experiment to answer the question that matters – in this example “will people use this feature” rather than “can we process credit card payments”
• 9:32 Overcoming the concern about releasing a not fully-baked product – in today’s technical environment releases can be almost constant and products can and should evolve
• 10:38 Listening to customer feedback results in teams motivated to improve
• 10:52 Most launch deadlines and intended launch feature sets are artificial
• 11:05 Launching early with a reduced feature set can result in more engaged customers because their important problems are addressed first, and the product will be improved incrementally
• 11:42 Techniques for actively avoiding the waste of redundant/unwanted code
• 12:04 Leveraging open source and packaged solutions in order to focus on what makes you unique
• 12:17 Consciously choosing to descope some activities (levels of testing and test automation, for instance) in the early release in order to get feedback quicker
• 12:44 Focus the right level of engineering for the right stage of the product
• 13:05 Going to the extent of scrapping what has been built once the ideas are validated and rebuilding them from scratch with all the quality aspects built in
• 13:54 This is a mindset shift – embrace uncertainty and allow learning to happen
• 14:49 Having engineers respond to customer support requests results in solutions being identified and built quickly
• 15:10 If an engineer needs to handle the same issue twice, it goes away really quickly because the solve it
• 15:42 Having engineers handle customer support feels inefficient but it actually results in better products and better teamwork
• 16:05 The freedom for every member of the team to advocate for things they want to work on or fix
• 16:42 The voice of the customer has the strongest influence on what gets worked on
• 17:05 Sometimes the software that you don’t write is more important than the software that you do write
• 17:40 Engineers need to think beyond the what and how of a feature and really understand why it is important (or not)
• 18:04 These decisions belong to everybody, not just the product owner or business lead

Mentioned:

• QCon
• Vistaprint