On Designing
Good Products—
Eight Frameworks,
one map.

A father doesn't buy a milkshake because he loves milkshakes. He hires it to make a long commute less boring, to keep his hands busy, to get him to work without crumbs in the car. Change the job, and the competition changes too—now you're competing with bagels and podcasts, not other milkshakes. Once you can articulate the job in a single sentence, the design space narrows from "infinite" to "tractable."

Design Thinking is less a process than a posture: stay curious longer than feels comfortable, define the problem narrower than feels safe, generate options wider than feels useful, and put something crappy in front of someone real before you trust your own taste. The five stages aren't sequential—you'll bounce between them—but they each have a job, and skipping any one of them is how the wrong thing ships.

The Double Diamond is the rhythm of any honest design process: open wide, narrow hard, open wide again, narrow hard again. The first diamond figures out what is the right problem. The second figures out what is the right solution. People conflate them constantly—the solution-first reflex is the original sin of product work—and you can spot a healthy team by how comfortable they are sitting in the messy middle of each diamond without rushing for closure.

Kano's insight is that features sit on three different curves. Basic features (the wheels on a car) cause misery if absent but no joy if present—their ceiling is zero. Performance features (battery life, speed) scale linearly with quality. Delighters are unexpected and disproportionately joyful—you didn't ask for them, but their absence isn't missed. Treating all three the same is how teams waste sprints polishing things customers were never going to notice.

Every product person eventually invents some version of this formula in a desperate moment after a stakeholder meeting. Intercom just gave it a clean name. RICE forces you to make four judgments explicit: how many people are affected, how much it'll move the needle, how sure you are, and what it costs to do. The score is not the truth. It's a conversation starter—and a way to notice when "obviously important" features have, on closer inspection, terrible math.

A North Star Metric is the one number that, if it goes up, your customers and your business win at the same time. It is not revenue—revenue is the bill the customer pays after the value is delivered. It is the value itself, measured: nights booked, songs played, messages sent, decks shared. Below the star sit input metrics—the levers teams can actually push. Below those, the activities that move the levers. Get the chain right, and the org aligns without anyone shouting.

The whole point of Lean Startup is to shrink the loop. Build something just-good-enough to test a single hypothesis. Measure the right thing—not vanity metrics, but the metric the hypothesis predicts. Learn whether you were right, then either pivot (the hypothesis was wrong, change direction) or persevere (you were right, push harder). Teams that confuse "building fast" with "learning fast" can produce a year of features and still not know what their product is for.

A prioritization model is only useful if it forces someone to say no. MoSCoW's brilliance is the explicit "Won't" column—not "later," not "backlog," but a public acknowledgement that some things will not be done in this round. Saying "no" out loud is more politically difficult than picking what's important, which is exactly why teams that skip it ship bloated, late, and incoherent products. Drag the items below and feel the resistance in your stomach when you have to put something in Won't.

For thirty years, "shipping software" meant convincing engineers to build the thing. Now you can build it yourself, this afternoon, before the coffee gets cold. The result: the bottleneck moved. Code used to be the hard part — it isn't anymore. The hard part is knowing what to build, for whom, and having the discipline not to ship every clever idea your AI offered you at 2am. The eight frameworks above didn't become obsolete in the AI era. They became load-bearing: when build cost approaches zero, the cost of building the wrong thing approaches infinity.

The temptation of vibe coding is to confuse motion with progress. AI can generate ten features in an hour. Your customers can absorb maybe one a month. The leverage is not in shipping more — it's in shipping the right thing, sooner, to the right person. The frameworks above are still the work. AI just lets you run more laps. The discipline is to make each lap count.