My Product Management Toolkit (13): Continuous Discovery

4 min readAug 20, 2016

I know it’s a bit of a bugbear of mine; people coming up with assumptions and jumping straight into solutions to address their assumptions:

“I know what my customers want”

“I know that I’m right”

“I’ve got umpteen years of experience in this sector, I know what people want”

“We’ve defined all customer requirements, we now just need to implement”

These are some of the comments that I hear quite regularly. Hearing comments like these have made me even more determined to constantly discover.

Discovery is all about about truly understand what your customers want (and why) or validating your assumptions, checking whether what you think is actually true. I learned that “Dual Track Scrum” is a great way to do discovery in an efficient and a continuous way (see some visual breakdowns in Fig. 1 and Fig. 2 below). Marty Cagan introduced Dual Track Scrum, citing Jeff Patton as his inspiration. I don’t tend to get too hung up on the word “scrum”, because one might not always be working in a Scrum type fashion. It could be Kanban, XP or any other iterative development approach that you might be using instead.

Fig. 1 — Discovery feeding into Delivery — Taken from: http://www.slideshare.net/andreaneu/ux-in-a-dual-track-agile-world

Instead, I like talking about ‘Continuous Discovery’, stressing that ongoing learning drives product development. Rather than doing big chunks of customer research at the start and at the end of the product development lifecycle, I prefer to learn ‘early and often’. The key is to spend some time understanding the problem first, before coming up with ideas or solutions to implement. With a ‘dual track’ approach, you’re constantly discovering and validating customer needs which can then be fed into the delivery of working software.

The outputs of a discovery track can come in all kinds of shapes and sizes:

A set of user stories and acceptance criteria
Design assets or wireframes
A prototype of a varying degree of fidelity
Learnings about user issues with working software
Data from a live experiment (e.g. A/B testing)

I often get asked why and when to best to use this Continuous Discovery approach and I thought to quickly summarise these FAQs:

Question: “Why can’t I just go and build stuff, launch and see what happens?”

My answer: I’d be the last person to stop you from building things, measuring and learn. However, I strongly believe that a large part of ‘continuous discovery’ is about mitigating (product) risk. Instead of spending a couple of weeks or months building something before you get actual customer feedback, I’d rather get customer feedback ‘early and often’, based on an product or a feature that has been used by actual users.

Question: “With these discovery sprints, isn’t there a big risk of ‘analysis paralysis’?”

My answer: No. By time-boxing and fixing the scoping of each discovery cycle, you can make sure that you constantly validate your riskiest assumptions or investigate things that can then go straight into the next development sprint. Each discovery cycle should result in a tested set of customer needs, user stories and/or wireframes which will then be converted into working software the following sprint.

Question: “Aren’t’ we just going over old ground?”

My answer: From my experience, even if you have working software, by constantly testing it you’ll be able to fix bugs and develop a better product. It might seem tedious but I feel that this approach is a lot less risky compared to companies just doing a (soft) launch at the end of the development process and hoping for the best. Continuos discovery is not an alternative waterfall type approach,where you create additional stage gates and isolated process. In contrast, since development is still happening in tandem; you’re effectively discovering what needs to developing in the next iteration whilst people are building what you discovered in the previous discovery track.

Fig. 2 — Dual-Track Development — Taken from: https://confengine.com/agile-singapore-2016/schedule

Main learning point: Instead of gathering customer requirements on a one off basis, I strongly recommend doing this continuously. Having designated discovery tracks that feed into development cycles will help in discovering customer problems and needs ‘early and often.’ This helps you in making sure that you’re building the right product for the right customer whilst you’re designing and building it.

Related links for further learning:

My Product Management Toolkit (13): Continuous Discovery

Written by MAA1