Time-Boxing Product Discovery
In my last article I talked about one technique for applying Scrum concepts to product discovery – the opportunity backlog. In this article, I wanted to talk about another, which is to time-box product discovery.
First, for those that are not familiar with the term, time-boxing is not the same as time-limiting. Time-limiting is what we did in Waterfall. Teams would plan a schedule with 2-4 weeks of time to do “requirements and design” and then development would proceed after that.
In contrast, time-boxing simply says that we will decide what we want to focus on in a given iteration, then work for that fixed period of time, and then reflect on our progress and see if we can’t improve how we work the next iteration.
This is at the heart of Scrum as a method, and is especially well suited to delivery because of our critical need to have frequent, consistent release vehicles.
But product discovery is not about delivery. It is about coming up with something that is worth building and delivering. Very specifically, the output of product discovery is a validated product backlog.
The product discovery team (product owner, lead designer and lead engineer) are working in product discovery to come up with the product backlog, and the delivery team is busy building and delivering the items on the backlog. This model of working is often referred to as dual-track Scrum.
I have been reluctant to advocate for time-boxed product discovery because with time-boxing the pendulum can easily swing too far towards output rather than outcome (just get something done, also known as “feed the beast”). Also, for good teams the velocity of product discovery is on the order of multiple iterations per day, in which case time-boxing breaks down.
However, the reason I wanted to discuss the concept of time-boxing product discovery is that I occasionally run into product teams that take far too long and go too slow in product discovery – not a little too slow, way too slow. And I know that if they continue to move this slowly, they simply will not get enough iterations produced and validated which will almost certainly lead to wasted time and money, and failed efforts.
Note that this is not about working harder or longer hours. It is about techniques and especially about mind–set.
The overarching principle in selecting the best techniques for product discovery is: “what is the fastest, cheapest way to validate the idea?” Actually building production software and deploying it live is among the slowest, most expensive ways to validate an idea.
Most of our techniques – including many flavors of MVP Tests, User Prototyping, and Live-Data Prototyping – are about validating in hours or days rather than delivery sprints (typically measured in weeks and months).
One technique to help teams improve on the speed at which they do this ideation and validation is to time-box product discovery. Let’s say that you decide on a one-week time-box for product discovery. On Monday you meet in the morning and decide what you are going to work on (hopefully by taking the highest priority opportunities from the opportunity backlog). Then you ask yourselves, “what is the fastest possible way we can flesh out this idea and validate it?” The product discovery team then spends the next several days doing exactly that. The purpose of the week is to generated validated product backlog items. At the end of the week, you would then reflect on how things went, and ask yourselves if there may have been even faster ways to ideate and validate these ideas?
For those that want to try time-boxing product discovery, the key question is the best duration for the time-box. Unless you’re working on hardware, to me this duration is never longer than one week. One week is a long time for product discovery, and good teams will explore and validate many iterations in a week. On the other end, I haven’t seen a duration shorter than one day. So likely somewhere between there.
Product discovery depends on establishing a rapid ideation/validation rhythm, and short duration time-boxing may help the team to move to this mindset.
If you’re not moving fast enough in product discovery, consider trying to time-box product discovery and see if this discipline can’t help the team to get the feel of a much more rapid test and validation mind-set.
