10. Continuous learning

§The second pillar is a sentence the original guide put plainly: product discovery is not a phase, it is a continuous process that runs parallel to development. Everything else in this chapter is about why that sentence is harder to live than to agree with.

§ 10.1Why the loop never stops#

§Four steps, each feeding the next. Discovery informs what to build. Building creates new situations, in which real people use real things and behave in ways nobody predicted. Those situations trigger new discovery: why did they do that, what did they expect, what stopped them. And the new insight drives the next step. There is no point in the cycle where learning is finished, because every act of building changes the world the learning was about.

§This is obvious once stated and violated constantly, because organizations are built around phases. Research happens, then design, then engineering, then launch. The plan has a box for learning and the box has an end date. After the end date, every conversation with a customer is filed as feedback on the product rather than evidence about the problem, and the company slowly loses the ability to notice that the problem has moved.

§Teresa Torres's whole practice, described in Continuous Discovery Habits, is an argument for one number: how many weeks in a row has the team talked to a customer? Not a research sprint once a quarter. Every week, as a habit, so that the picture never goes stale. She writes for product trios inside larger companies. At one to five people the habit is easier to form and easier to lose, because there is nobody whose job it is except the person whose job is everything.

§ 10.2Why spikes fail#

§The alternative to a habit is the spike: an intense burst of research when the team feels lost, followed by months of building on what it found. Spikes fail for the reason occasional exercise fails. The benefit decays. The findings from March are the assumptions of June, and by September the team is defending decisions made on evidence nobody has looked at since.

§Spikes also fail because they are expensive in the way that matters at a startup: they interrupt. A team that stops building for two weeks to research, then stops researching for three months to build, is switching modes at exactly the cost the loop was meant to remove.

§ 10.3What embedding looks like at one to five#

§The original guide listed the systematic version: regular customer contact through several channels, quick experiments with clear learning goals, insight shared across the team, decisions made fast on new information. Translated to a company of one to five, it is three habits.

§One customer conversation a week, minimum, run by the owner, synthesized the same day. Every shipped thing treated as an experiment with a question attached, so that watching what happens to it is discovery rather than monitoring. And a place, a document, a channel, a wall, where what was learned is written where everyone sees it, so that the sales call and the support email and the engineer's observation land in the same picture.

§ 10.4Who owns the rhythm#

§Somebody has to. The guide said it directly: start with yourself, then your team, then your stakeholders, and if you do not take ownership no one will. Product Foundation named the person. This pillar is what they are keeping alive.