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. 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.
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 a product or 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, through 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. Continuous 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.
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:
6 responses to “My Product Management Toolkit (13): Continuous Discovery”
[…] RSS ← My product management toolkit (13): Continuous Discovery […]
[…] you’ll almost always will have to take a punt, but being disciplined about doing sprints and continuous discovery will help you make better informed decisions, based on real customer […]
[…] learning – In my experience, the ‘learning’ aspect comes from continuously exploring different ways to tackle a problem, celebrating success as well as reflecting on the ‘failures’. The more you can share […]
[…] or unknowns related to the technical implementation. As a group, you might agree on running discovery sprints to test certain technologies or non-happy path scenarios to deal with some of the ‘unknown […]
[…] This might mean that the existing design checklist (see Fig. 2 below), underpinned by my preferred dual track approach, might be binned or adapted accordingly. Both are fine, as I expects checklists to be formed by […]
[…] features prioritised prioritised for an entire year … In my experience, until you start discovering, implementing and launching product ideas, you’re not going to know whether your product is […]