Continuous Discovery →
It’s common practice now in software development to do “continuous integration” — a constant reintegration of newly-written code with the master application to continuously run regression and unit tests, making the process of integrating new features a series of small efforts rather than one massive one at the end of a sprint cycle:
Many product teams have taken this principle to the next step and have learned that integration problems are time consuming, and that by integrating early and often (rather than a “phase” before testing), they can significantly speed up their overall throughput by minimizing the time that they are working in isolation.
Similarly, instead of testing everything in a phase at the end of a release cycle (even a 2-week release cycle) and finding all the problems at once, it is much better to run automated regression test suites continuously to find newly introduced issues as soon as possible (which significantly reduces the possible sources of the issue and hence the time to correct).
Marty Cagan makes the case here for a similar process for shaping new product opportunities: “continuous discovery”:
I have long argued for exactly the same principle in terms of how we come up with product backlog items. Rather than a “Product Discovery Phase” where we come up with several weeks of validated product backlog items and deliver them to engineering, I encourage teams to do continuous product discovery – where we are constantly identifying, validating and describing new product backlog items. Some discovery work takes a few hours and other things can take longer, but it is an ongoing process of ideation, validation and description.
I think many companies do this already, at least some individuals do (including myself) without recognizing it as such. I like the idea of making it part of the discipline of how teams work all the time — for a particular part of your product team (owners, PMS, designers) to be spending almost all their time working with the raw material inputs from your own backlog ideas, customer feedback, conversations with sales, marketing leading indictators, market trends, and more, constantly molding and forming these elements into new product while others are building.
This falls in line with the Basecamp technique of maintaining no backlog. It makes sense to me: if you’re constantly sculpting and shaping new solutions from all your input channels, you’ll be much more likely to create the right product, and to have a tight grip on what to build when the time comes for engineering to dig in.