Product thinking (and the diamond I actually use)
Frameworks are useful when they ask better questions. They’re useless as activity theatre. The design thinking framework I actually run is a sequence of verbs: sense what’s real, frame the outcome, explore more than one answer, decide with an evidence gate, ship and learn. That Sense → Frame → Explore → Decide → Ship loop is product thinking as lived practice — not five badges on a slide.
- SenseAI: Cluster notes and quotesHuman: Real versus loud
- FrameAI: Draft the outcome and the treeHuman: Pick the bet and the rule
- ExploreAI: Outline into layoutsHuman: Kill most of it
- DecideAI: Eval scriptsHuman: Severity and trade-offs
- Ship / LearnAI: Flags and the next briefHuman: What to bet next
- Explore walks back to Sense
- Decide walks back to Frame
- Ship walks back to Sense
Double Diamond, honestly
The classic Double Diamond still holds: Discover → Define → Develop → Deliver. You diverge to learn, then converge to choose; you diverge again to try solutions, then converge to ship. Learning can send you back. Nothing is finished. Put people first. Communicate visually. Co-create with the people who will live with the work. Iterate because the first answer is almost never the lasting one.
I don’t paste diamond graphics into every brief. I use the shape: widen before you narrow, and don’t pretend a locked solution is research. When a week of tickets says the problem is different than last month’s roadmap, we go back — that’s the diamond working, not the plan failing.
Outcomes over outputs
Product thinking starts with a change in behavior, not a feature count. Success is an engineer recovering from a failed synthesis run without leaving the agent pane; a Tier 1 agent resolving or routing correctly on the first call; a diner who trusts a wait estimate enough to bid; a customer who gets their stuff back without contacting support. Outcomes over outputs. Assign problems, not solutions — then an empowered trio (design, product, engineering) discovers how.
OKRs and roadmaps work the same way when they’re honest: a sequence of outcome bets, not a project list dressed up as strategy. The opportunity solution tree keeps the bet honest — one opportunity, several possible answers, riskiest assumptions written out loud before anyone falls in love with a screen.
Opportunity: recover from a failed chip-design run without leaving the agent pane
- Autofill a default and keep going
- Show the plan, then a diff to accept chunk by chunkRiskiest assumption: will a hardware engineer accept an agent’s proposed fix without seeing the diff?
- Hand the whole run to a human immediately
Bets with a decision rule
Every product bet is a time-boxed investment with a hypothesis and an evidence gate. Before we build, we write what the result would mean: stop, revise, or scale. That rule lives next to the ticket in Linear — Cognichip, Handle, Meow — so the decision isn’t a vibe after the demo. Riskiest assumptions first: will a hardware engineer accept an agent’s proposed fix without seeing the diff? Will diners pay to skip the line only if the estimate feels honest? Those questions shape the prototype. The prototype answers them. The gate decides what happens next.
- StopThe rule, written before the build.
- ReviseThe rule, written before the build.
- ScaleOnly after the evidence clears.
Critique and usability that find different problems
A design critique process that only does one method misses half the pain. I follow a pattern that alternates: a heuristic pre-pass (a few independent looks, aggregated and severity-rated) to clear the obvious issues, then task-based usability with new users each round. The two methods find different problems, so they take turns. Facilitated critique turns findings into action items the same day when it can — Handle eval threads scored for honesty and correction speed; UI/UF same-night severity clusters so designers leave with a findings sheet, not folklore.
Include empty, error, edge, and accessibility states in what you test. That’s where trust breaks. Agentic products especially: the suggestion has to be right often enough to trust, and easy to correct when it isn’t.
Where brand OS fits
Brand isn’t a separate planet. Positioning brief, messaging pillars, voice-by-context, and token governance are how product and brand stay one system when the work earns it — launch film and agent pane reading as the same company, CSP theming modes that don’t fork the app. This page stays on product thinking; brand-led cases carry the Brand OS story. The pointer matters: outcomes and identity should inherit from the same spine when you’re the person owning both.
Where this shows up
Product-thinking-first cases: Cognichip (0→1, first designer, agent interaction models), Plume web dashboards and app (clarity to ambiguity, partner with Product and Engineering), Boxbee, Meow, Handle (quality bar upstream), BloomSky (light).
Brand-OS-first cases: Plume brand, Full Node Design, Sparrow Dock, G-Technology, Touro, and related identity systems — same decision discipline, different lead lens.
Constrained institutional UX: UCSF (and related legacy work) — tree test and content model before visual freedom.
The diamond and the verbs are the same. The page tags decide which language leads.