Someone says X → think Y
The searchable index of this domain. The left column is what you hear in a meeting or read in a ticket; the right column is the thing to think before you answer.
34 of 34 rows
| Someone says | Think |
|---|---|
| "Just add a button for it" | Decompress the ticket: what problem, for whom, how do we know, what changes, what is the smallest thing that would tell usProblem Before Solution → |
| "Users want…" | Which users, doing what job? A role and a task, not a populationUsers and the Jobs They Hire Features For → |
| "We shipped it, the sprint is done" | That is output. What changed for someone, and how would you see it?Outcome vs Output → |
| "It is a small feature, why not?" | Every feature has a support, performance and deprecation cost that arrives after the sprintThe Cost of a Feature → |
| A request you think is wrong | Do not refuse — propose a smaller, cheaper way to find out who is rightSaying No Well → |
| "Why did we choose X?" six months later | A decision record with the rejected option is the only thing that survives the people who made itDecision Records → |
| Two pages of context before the ask | The one-pager: decision at the top, options, recommendation, what would change your mindThe One-Pager → |
| Stakeholder asks "so what should we do?" | Bring options with costs, then your recommendation — never only the recommendationOptions, Not Answers → |
| You are asked something you cannot answer yet | Say so, say what you will do to find out, and say when"I Don't Know Yet" → |
| A choice everyone treats as final | Is it reversible? Reversible decisions deserve a day, not a monthReversible vs Irreversible Decisions → |
| A six-week feature with no smaller version | What is the quarter-size version that answers the same question?The First Version That Teaches You Something → |
| Scope creeps mid-sprint | Cut by asking which parts change the answer to the question the feature is askingCutting Scope by the Question, Not the Difficulty → |
| "Let us build the foundation first" | Sequence so value lands early; the foundation is justified by the second slice, not the firstSequencing Work So Value Lands Early → |
| "We cannot ship until it is finished" | A flag turns a big launch into a series of small, reversible onesFeature Flags as Product Tools → |
| "Done" means merged | Done means someone used it and you know what happenedDone Means Someone Used It → |
| The team ships in bursts and burns out | A cadence you can sustain beats a heroic quarterA Shipping Cadence the Team Can Keep → |
| "Let us track everything" | One metric that moves when the product gets better, and the guardrails that stop you winning the wrong wayPicking a Metric That Moves When the Product Gets Better → |
| "We will add analytics later" | Later has no baseline. Instrument first, then buildInstrumentation First → |
| "The A/B test says +3%" | Ask about the sample, the duration, the guardrails and who decided when to stopReading an Experiment Honestly → |
| The metric went up and support tickets did too | A guardrail metric would have caught the win that was actually a lossGuardrail Metrics → |
| "The dashboard looks fine" | Dashboards show what you thought to measure. Read the ticketsWhat Dashboards Hide → |
| A number with no story behind it | Five user conversations beat a thousand events for explaining whyQualitative Signals → |
| The PM hands you a solution | Ask for the problem; bring the cost and the smaller versionWorking With a Product Manager → |
| Design delivers a mock you cannot build in time | Say what is expensive and why, and offer the version that keeps the intentWorking With Design → |
| Nobody read your update | First line is the decision or the ask; everything else is optionalWriting for Stakeholders → |
| You lost the argument | Disagree in writing, commit in full, and name what would prove you rightDisagree and Commit → |
| A demo that is a feature tour | A demo should end with a decision, not applauseRunning a Demo That Ends With a Decision → |
| Feedback that was ignored | Specific, about the work, with the effect it had — and ask for it the same wayFeedback in Both Directions → |
| An outage with no product owner in the room | An incident is a product event: who was affected, what did they lose, what do we tell themIncidents Are Product Events → |
| Support keeps asking the same question | The support queue is the cheapest user research you haveThe Support Loop → |
| "We need a refactor sprint" | Debt is a product decision with a cost; name the feature it is slowing downTech Debt Is a Product Decision → |
| A feature three people use | Deprecation is a feature: announce, measure, remove, and say what you learnedDeprecating a Feature → |
| "Ops will page us if it breaks" | If you shipped it, you own the page — and the runbook that makes it shortOn-Call for Product Engineers → |
| A postmortem with ten action items | One change that would have prevented it, owned, with a datePostmortems That Change Things → |