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.
The pattern for replacing a legacy system in slices while it keeps serving traffic. Fowler covers transitional architecture, the code you write knowing you will throw it away, and makes the case that the cost buys you earlier value and lower risk.
Rewritten in 2024 and considerably sharper than the 2000 original. Fowler lists the practices that make integration cheap, from self-testing code to daily merges, and he is honest about the team conditions the approach depends on.
Maps twenty research methods across attitudinal against behavioural, qualitative against quantitative, and the product stage each suits. The chart is the fastest way to settle a debate about whether a survey can answer the question you actually have.
The definitive source, and what the PSPO and PSM exams are assessed against. Thirteen pages, licensed CC BY-SA 4.0.
Six levers behind product outcomes, covering how much data you hold, how usable it is, how fast insight arrives and how quickly a team can act on it. Cutler runs the same model at startup and enterprise scale, which makes the bottleneck easy to locate.
Defines the four DORA measures and walks through the pipeline Google built to collect them from real systems. Read it before adopting the metrics, because how your organisation defines a deployment decides what every one of the numbers means.
Names three kinds of work that feel productive without being valuable, then points at where the leverage actually sits. Written for senior engineers, and it reads just as well for a product manager holding more requests than hours.
Answers the practical questions a team hits when it sits down to write a vision, including how many years out to aim and who owns the drafting. The nine factors Cagan wants considered in a vision workshop make a usable agenda on their own.
Most artefacts presented as a product vision turn out to be a mission statement. Cagan lists what a real vision has to do for the people building the product, and explains why it usually arrives as a video or a prototype rather than a filled-in canvas.
Benchmarks for user retention and net revenue retention across consumer, small business and enterprise, gathered from twenty growth practitioners. Gives you a number to compare against instead of a debate about whether your curve looks flat enough yet.
The argument for treating work in progress as an organisational limit rather than a team one. Cagan uses Pandora and his own years at HP to show what happens when twenty initiatives are all described as critical, and he quotes Rumelt on concentrating resources on very few pivotal objectives.
Cagan sets out the four things a product strategy has to do, from picking the few objectives that matter through to managing the work once it is under way. Read it when your organisation has a roadmap and a set of objectives but nothing that explains why those are the bets.
Larson names five things that compound across decades, covering pace, relationships, visibility, financial security and learning both deep and broad. A useful corrective if the only career model on offer where you work is a four year vesting schedule.
Works through unit, integration, contract and end to end tests with running code rather than a diagram. The rule to push each test as far down the pyramid as it will go is what keeps a suite fast enough to run on every commit.
Value, usability, feasibility and business viability, each with a named owner on the team. This is the frame underneath most modern discovery practice, and it explains why a prototype users love can still be the wrong thing to build.
Sorts toggles into release, experiment, ops and permissioning categories, each with a different lifespan and a different owner. The section on retiring toggles is the reason to read this before your codebase fills up with them.
Balfour's argument is that products get shaped to fit channels and never the other way round. The worked examples from gaming and dating apps show what happens to a company when the channel underneath it moves.
Opens a series on the fits a company needs beyond product and market, taking in channel, business model and the market again. The description of the product death cycle will land with anyone whose growth plan is really a list of features.
Majors argues that moving between building and managing every few years produces stronger technical leaders than choosing a lane and staying in it. Her point that management is a lateral move rather than a promotion is worth sitting with before you accept one.
The original write-up of the technique for connecting a desired outcome to the opportunities and experiments beneath it.