Managing Startups: Best Blog Posts

Chapter 34. Time-Boxing Product Discovery

Marty Cagan

In this article, I want to talk about time-boxing 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 development—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 it 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 toward output rather than outcome (just get something done, also ...