7. Engineering and product

§Most of what goes wrong between product and engineering at a startup is a confusion about which question each is answering. Product answers what and why. Engineering answers how and how long. When product starts answering how, it gets bad architecture. When engineering starts answering why, it gets a beautifully built thing nobody asked for. The relationship works when each holds its question and trusts the other with theirs.

§ 7.1Requirements a developer can build from#

§The unit of communication between the two is the requirement, and at a startup it is almost always too vague or too detailed. Too vague: "add loyalty." Too detailed: a twelve-page specification of screens nobody has tested. The right size is a problem with a boundary.

§The user story format exists for this reason, and Bill Wake's INVEST criteria are the test of whether a story is any good. Independent: it can be built without waiting for another. Negotiable: the details are open to the engineer, only the outcome is fixed. Valuable: a user gets something when it ships. Estimable: the engineer can say roughly how long. Small: it fits inside a week or two. Testable: there is a clear way to know it is done.

§Acceptance criteria are the boundary in writing: three to six statements of the form "a customer who has never used the app can complete a reservation on a phone without asking anyone." They double as the test script for the stranger you will watch later.

§Basecamp's Shape Up adds the idea this book leans on most: the requirement carries an appetite, the amount of time the team is willing to spend, rather than an estimate of how long it will take. "Two weeks of one engineer" is a product decision; "how long will it take" is an engineering question. Setting the appetite up front turns scope into the variable and time into the fixed point, which is the only arrangement under which a startup ships.

§ 7.2Who decides#

§Every product-engineering standoff comes down to a decision that has no owner. The tool the original guide borrowed, and this book keeps, is the RACI matrix, reduced to its one useful line: for each kind of decision, who is Responsible for doing the work, who is Accountable for the decision, who is Consulted before it, and who is Informed after it.

§At five people the matrix is a paragraph. What to build and for whom: product accountable, engineering consulted. How to build it and how long: engineering accountable, product consulted. What ships this week: product accountable, engineering responsible. Whether to take on technical debt to hit a date: engineering accountable, product consulted and informed of the cost in writing.

§That last one matters most. Technical debt is a product decision disguised as an engineering one. Every shortcut is a loan against future speed, and the owner has to know the interest rate. The habit that keeps this honest is a running list, kept by engineering, of trade-offs taken and what it would cost to unwind each. Chapter 10 returns to what happens when the list is not kept.

§ 7.3The fewest rituals#

§The Scrum guide describes five events: sprint planning, daily scrum, sprint review, sprint retrospective, and backlog refinement. They were designed for teams of seven to nine in organizations where alignment is expensive. A team of five that sits in one room does not have an alignment problem; it has a deciding problem, and rituals do not decide.

§Keep the ones that produce a decision or a demo. A short weekly planning conversation that ends with the appetite for each piece of work. A demo whenever something is usable, to whoever will use it. A retrospective when something went wrong, not on a calendar. A daily standup is optional and usually a Slack message. Anything longer than fifteen minutes that ends without a decision was a conversation, not a ritual.

§ 7.4Handoffs that do not break#

§The last failure mode between the disciplines is the handoff: product writes, engineering builds, and what ships is neither. Two habits prevent it. The engineer is in every conversation where scope is decided, so the boundary is understood before it is written. And the acceptance criteria are read aloud at the demo, one by one, against the thing built. If a criterion cannot be checked at the demo it was not a criterion.

§Part II is done: experience, interface, engineering, each held by the owner until a specialist arrives. Part III is about the instrument panel, and the one rule that keeps it from taking over the plane.