BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts Ramon Harrington of Vistaprint on Choosing What Not to Build

Ramon Harrington of Vistaprint on Choosing What Not to Build

Bookmarks

In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Ramon Harrington of Vistaprint about his QCon New York talk on Rapid Prototyping.

Key Takeaways

  • Putting engineers in front of customers and having conversations results in far better understanding and empathy for the customer’s needs
  • Be prepared to launch before you’ve built everything you think the product needs in order to avoid building features people don’t want
  • In engineering there is often a “right” answer, in product identification there isn’t – you don’t know until you try it out
  • 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
  • Sometimes the software that you don’t write is more important than the software that you do write
  • 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:

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

BT