3. What the owner is accountable for

§Chapter 1 said product is the ownership of strategy, vision and execution at once. This chapter takes the three apart. Each is a different kind of promise, held for a different length of time, and broken in a different way.

§ 3.1Vision: held stubbornly#

§The vision is the description of the world when the company has done its job. Not the feature list, not the market size, the world. "Every developer has a pair programmer that knows their codebase." "Anyone can make a professional image by describing it." A good vision is broad enough to survive several pivots of the product underneath it and specific enough that a stranger can tell you what would count as failure.

§Jeff Bezos's line is the one every founder quotes, and it is quoted because it is exactly right: stubborn on the vision, flexible on the details. The vision is the thing the owner does not renegotiate when a customer conversation goes badly or a competitor launches. Everything else is a detail.

§The vision earns its keep in three ways the original Product 101 guide listed and this book keeps: it gives the team a sense of direction when the day's evidence is confusing, it recruits people who could work anywhere, and it is the frame in which every smaller decision gets made. A team without a vision decides each feature on its merits, which sounds reasonable and produces a product that is a pile of reasonable features.

§ 3.2Strategy: choices that exclude#

§Strategy is how the company intends to get from here to the vision. Richard Rumelt's definition is the useful one: a diagnosis of the situation, a guiding policy for dealing with it, and a set of coherent actions. What makes strategy strategy, rather than a plan, is that it excludes. A strategy that does not say what the company will not do is a wish.

§At a startup, strategy is a short list of bets, in order. "We will win developers before we win their employers." "We will not build a mobile app until the desktop retention curve flattens." Three to five of these, each with a critical question attached: what has to be true for this bet to be right, and what number would tell us in ninety days.

§The layered picture that Reforge calls the product strategy stack, and that Lenny Rachitsky lays out as a ladder from mission to task, is the tool for keeping vision and strategy in the right order. Each level is the input to the next; a vague level turns everything below it into opinion. Product Strategy, the fourth whitepaper, is entirely about filling that ladder from evidence. For now the point is only that the owner is accountable for the ladder existing, being written down, and being short.

§ 3.3Execution: the first unit of work#

§The third promise is the one that gets built. Not the whole product: the first unit of work, defined tightly enough that it can ship in weeks, learned from, and used to decide the second.

§The original guide called this the MVP and listed the standard shapes: concierge, where you do the job by hand; Wizard of Oz, where the automation is faked behind a human; the landing page, where you test whether anyone wants the job done at all. Those shapes are still right, and this book moves them to Product Sprint, where they belong with the other ways of turning ideas into evidence. What stays here is the accountability: the owner is answerable for a first unit of work that exists, that a stranger can use, and that teaches the team something specific.

§ 3.4How the three fail together#

§The three promises fail in characteristic combinations. A strong vision with no strategy produces inspiring decks and a roadmap nobody can defend. Strategy without vision produces a well-argued sequence of bets toward a destination nobody wants. Execution without either produces shipping as a substitute for deciding: the team is busy, the burn is steady, and nothing that ships answers a question anyone asked.

§The owner's job is to keep all three alive at once and to notice, week by week, which one has gone quiet. One chapter remains in Part I, and it is about why this description of the job, once a startup exception, is becoming the rule everywhere.