It’s MAD to Build everything that goes through discovery

People nod heads with a knowing look when someone informs them that less than 50% of ideas make it to market.  That may even seem generous. Companies practicing continuous product discovery collect data on the impact and unofficially report numbers far lower than 50%. These companies test multiple ideas weekly and most are not pursued.

Many organizations wind up building most everything on the discovery path when getting continuous dual-track development sufficiently running. This also seems logical. Naturally, teams need time to embrace and adopt new practices and celebration in making it all work together.

At some point, the teams need to sit down and thoroughly review all the data collected. Information about people and product usage builds up rapidly- both quantitatively and qualitatively -as it’s used to fuel discovery.

/ponder by hobvias sudoneighm

What is missing the mark?  Are the ideas themselves tepid? How safe is it for teams to explore wild concepts? Can the team stop doing things stakeholders want, when it’s proven that the users and choosers don’t want it? The product discovery questions-

  1. Do people want (to buy) it?
  2. Can they use it?
  3. Can we build it?
  4. Do stakeholder support it?

-are in order of priority. If nobody wants it, we’re done here. Quickly answering the discovery questions with a resolute ‘no’ for many ideas helps tremendously cut costs.

Giving the team the authority to manage the opportunity backlog, including removing items, speeds up the learning process. Ensure the right environment and measures are in place for teams to thrive.

Teams can generate enormous amounts of ideas, including the quirky and strange, rather cheaply. Having many ideas, furiously discarding most and combining elements of the best is more likely to strike upon something truly innovative.

« Eurêka ! » by Adrien Leguay

A team tuned into design thinking and applying real options theory will have many more ideas, of an overall higher quality, and understand their worth. Teams of this calibre are more likely to design safe-to-fail experiments instead of making fail-safe decisions, iterating through prototypes with users and choosers several times a week.

The safety net in technology in support of experimentation starts with continuous integration. CI is the soul behind unit testing, TDD and continuous delivery.

Enhance practice efficacy with pair programming. Pairing moves the information around, amplifies learning and boosts confidence to make the changes necessary in support of rapid experimentation.

That support extends in technology by integrating tools for A/B testing and usage analytics. Use A/B testing for big changes across pages, while multivariate testing is best for smaller, localized changes inside one page.

Supporting multiple variations helps with gentle and continuous deployment.  DevOps can quickly flip on and off features, as well as launch dark and allow work-in-progress in to production.

It’s been said that a good team will successfully build 100% of ideas and a great team will invalidate over 75% of them. What does discovery look like where you work? How many of your ideas survive through to delivery? Please leave your comments below!

 

This entry was posted in #agile explained and tagged , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *