ManagementSubsection
Product management
Deciding what is worth building at all, and being able to tell afterwards whether it worked. Three topics that follow each other: finding out what people need, choosing what to do about it in an order you can defend, and measuring the result without fooling yourself. The hardest part of all three is declining things, which is why each page covers how to say no as well as how to choose.
What is inside
Every page in this group, with what each one covers.
- Product DiscoveryOne finished quarter of discovery: the trio, the opportunity solution tree, assumption mapping, and tests from cheapest up.The trioOpportunity tree
- RoadmappingOne team’s finished roadmap: Now/Next/Later, three versions for three readers, RICE against WSJF, and dates made after discovery.Now / next / laterRICE vs WSJF
- Metrics & KPIOne team’s finished set of metrics: a written definition, guardrails against Goodhart’s law, the North Star tree, cohorts and peeking.GuardrailsCohorts
Where to start
- Building without evidenceProduct discovery. Start with assumption mapping — it is the cheapest way to find out what you do not know.
- Your roadmap is a list of datesRoadmapping, and the three audiences in particular: most roadmap arguments are two people reading it as different documents.
- The numbers disagreeMetrics and KPI — written definitions and the cohort-versus-snapshot distinction resolve most of it.
Elsewhere in the section
- ManagementIT project management is the set of decisions that turn an intention into shipped software: what to build, how to cut it into work that can actually be finished, how the team runs itself week to week, and how the result reaches users. This section covers 25 topics in six groups — product management, decomposition, methodologies, the release process, the formal frameworks, and the craft of running a project rather than a method for running one — and each page gives the trade-off behind the choice rather than a summary for a certification exam.
- DecompositionTurning something too big to start into pieces small enough to finish — and keeping the reason for each piece attached to it on the way down. Four topics covering the two traditions that rarely meet: work breakdown from project management, and user stories from product. They answer different questions, and knowing which one you are in stops most arguments about how detailed a plan should be.
- MethodologiesHow a team decides what to build next, in what order, and how it knows when something is done. Nine methodologies, from the two most teams actually run to the four that exist because one team stopped being enough. Each page describes what the framework actually defines — every ceremony, every role, every artefact — rather than summarising it, and says plainly where it stops working.
Found this useful?
Share it with someone who is working on the same problem.