Product Strategy Means Saying No
On the requests a product should decline and how to explain the decision without relitigating it every quarter.
Writing on product work that we keep coming back to, gathered from across the internet.
Every title opens the original on the publisher’s own site. We point at this writing and credit the people who wrote it. We do not host it.
On the requests a product should decline and how to explain the decision without relitigating it every quarter.
Why acquisition channels decay over time, and what that implies for growth plans built on a channel that is working today.
The full book, free online. Six-week cycles, appetite instead of estimates, and shaping work before it reaches a team.
Scrum.org's framework for measuring value across four Key Value Areas. Referenced by the PSPO syllabus without being part of the Scrum Guide.
What changes structurally when a company moves from project delivery to empowered product teams.
The origin of the 40% very-disappointed benchmark, and how to run the survey it comes from.
How to choose a single leading metric and the inputs beneath it, with the failure cases for picking the wrong one.
Defines the parts of a journey map, the actor, the scenario, the phases and the emotional line running underneath them. Read it before commissioning one, since a map assembled without research describes the room it was drawn in rather than the customer.
Sets out the difference between a style guide, a component library and a full design system, and what each one costs to keep alive once it exists. Useful when a team wants to start one and needs to understand the commitment first.
A structured reading path through interface copy, from microcopy and error messages through to voice, tone and localisation. Aimed at people who write the words inside a product without ever having been taught how.
A short run of sketches showing how the same problem looks to someone starting out and to someone who has done the work for a decade. Zhuo uses it to make a point about scope and judgement that carries well beyond design.
Sorts products into attention, transaction and productivity games, then picks a different shape of metric for each. That three way split is what stops a team copying a number that suited a company with a different business model.
What the accountability covers day to day, from ordering the Product Backlog to being reachable when developers need a decision. A good companion to the Scrum Guide for anyone preparing for a product owner assessment.
The three Cs that describe what a user story actually consists of, written when the practice was still being worked out. Short, and it explains why a story with perfect wording and no conversation behind it still leaves the team guessing.
Torres makes the case for a product manager, a designer and an engineer sharing the discovery work rather than passing it down a line. Her distinction between missionary and mercenary teams is the part worth testing against your own organisation.
Gurion separates a metric that moves the business from a metric a team can actually influence, then shows how to derive the second from the first. The worked example of turning churn into observable customer behaviour is the part you can copy on Monday.
Meeting a technical standard and being genuinely usable by disabled people are different bars, and this piece is about the space between them. Worth reading if your team treats a passing audit as the end of the work.
Adams argues that design judged on how a screenshot looks drifts away from the problem the work was meant to solve. What he offers instead is a sequence, starting from the job and the outcome and reaching the pixels last.
Fournier lists what actually decides whether a senior engineer is effective, from writing a design document to running a meeting that ends in a decision. Good raw material for a levelling framework or a growth conversation that keeps stalling.
Kohavi and Thomke on running experimentation at scale inside a large organisation, including how many tests fail and why that is the point rather than a problem. Helpful when you need to explain to leadership that a low win rate is a working programme.