What did Agile contribute to product discovery?

Agile's gift to discovery is often missed because Agile was never about discovery: small increments, frequent feedback, early detection of problems. Those habits make a delivery team learn faster. They do not tell it what to learn about, and a startup that mistakes Agile for a discovery method will iterate beautifully toward the wrong thing.

Is Agile a discovery method or a delivery method?

Agile's gift to discovery is often missed because Agile was never about discovery: small increments, frequent feedback, early detection of problems. Those habits make a delivery team learn faster. They do not tell it what to learn about, and a startup that mistakes Agile for a discovery method will iterate beautifully toward the wrong thing.

Why do Agile teams still build the wrong product?

Agile's gift to discovery is often missed because Agile was never about discovery: small increments, frequent feedback, early detection of problems. Those habits make a delivery team learn faster. They do not tell it what to learn about, and a startup that mistakes Agile for a discovery method will iterate beautifully toward the wrong thing.

Agile · Product Discovery · Product Thinking

§ 7.1What it gave us#

§The 2001 manifesto was written by engineers about engineering, and its influence on discovery is real precisely because it was indirect.

§Three habits crossed over. Small increments: work broken into pieces that ship in days or weeks rather than quarters, which means each piece can be reacted to before the next is built. Frequent feedback: a working thing shown often, to real people where possible, so that the reaction is to the thing rather than to a description of it. Early problem detection: because increments are small and feedback is frequent, the moment a piece is wrong is close to the moment it was made, and the cost of being wrong stays small.

§Together these turned the delivery half of into something that could learn. A waterfall team found out it was wrong at the end. An Agile team finds out every two weeks. That is a discovery contribution, even though nobody in the manifesto used the word.

§ 7.2What it assumes#

§Agile assumes the question of what to build has already been answered, somewhere upstream, by someone, and that the team's job is to build it well and adapt as details emerge. The backlog is a queue of things to build. Prioritizing the queue is not the same as asking whether the queue is pointed at a real problem, and nothing in the method requires anyone to ask.

§Marty Cagan's distinction between product teams and feature teams is the sharpest description of what happens when this assumption goes unexamined. A feature team is handed features and builds them, often very well, in sprints, with retrospectives. A product team is handed problems and is accountable for solving them. Both can be Agile. Only one is doing discovery.

§ 7.3Where it breaks at one to five#

§At a startup Agile breaks by being mistaken for the whole of product. A founding team adopts sprints, stand-ups and a backlog because that is what serious software teams do, and the ceremonies produce a strong sensation of rigor. The backlog fills with the founder's ideas. Each sprint delivers some of them. Velocity is measured and improves. Nothing in the process ever asks a stranger whether any of it matters, because the process assumed that question was answered before the first ticket was written.

§The result is a team that iterates beautifully toward the wrong thing, and discovers this at the same moment a waterfall team would have: when the money runs out.

§ 7.4What to keep#

§The three habits: small increments, frequent feedback, early detection. They make 's build step and Product Experimentation's loops faster and safer. What to leave is the belief that a backlog is a strategy. Agile is how a team that knows what to build gets it built. Everything before that is this book.

7. Agile