Use when a design choice has to be justified to a founder/non-technical stakeholder, when proposing to spend (or take on) time/money/debt, or when "why does this matter to the…
Use when a buyer pushes back (too expensive / no time / not now / need to check with X) — clarify and confirm the REAL concern before answering; separate a genuine blocker from a…
Use on every surface — accessibility is designed in, not bolted on. ~80% of accessibility is design decisions (contrast, hierarchy, target size, focus order, labels) made before…
Use when the question is "how do we reach buyers at all?" — distribution / go-to-market strategy. Run the Bullseye (brainstorm → cheap-test a few → focus the ONE that works) and…
Use before scaling any message, after a launch underperforms, or whenever positioning is still a hypothesis (pre-users).
Use when designing or fixing how the system is configured (env vars, json/yaml/toml files, flags, per-project/per-box settings, layered defaults) — give config a versioned schema,…
Use when defining modules, services, interfaces, or data ownership — or when "let's go microservices" comes up — design for cohesion/coupling and Conway's Law; refuse the…
Use when defining what "success" means for a feature/initiative, when picking a metric, or when a number looks suspiciously good — choose a North Star + guardrails, reject vanity,…
Use when making the actual call — a clear invest / pass with conviction, the single risk you'd underwrite, and the coaching you'd give either way.
Use before you write a line of demand copy or plan a launch — when the value seems "nice to have," when adoption is flat despite good messaging, or when nobody can answer "why…
Use when a QUALIFIED deal stalls — "let me think it over," goes quiet, keeps asking for more info, won't commit.
Use when proposing the approach for an initiative, or when tempted to add structure "for future scale" — design the idiomatic, simplest thing that solves the real problem and…
Use when the pipeline is thin or you need to open NEW conversations — proactively build a target list, sequence multi-touch outreach (call/email/social), open a cold conversation,…
Use when reviewing a change, feature, or design for security — walk Shostack's four questions and STRIDE across every trust boundary of THIS stack, not a generic checklist.
Use when reviewing anything that authenticates users, checks permissions, or exposes objects by id — broken access control is the #1 web risk; verify authz is enforced server-side…
Use when more than one entry surface exists or is proposed (CLI, API, MCP, UI, webhook, cron) — make every surface route to one shared core code path, and run a DRY pass for the…
Use when assessing demand — trust what customers DID over what they say. Triangulate demand from the displaced status quo and the losses, never the TAM slide.
Use whenever something is broken, flaky, or behaving unexpectedly — find the root cause systematically (reproduce, isolate, hypothesize, verify) and fix the cause, not the…
Use when writing a spec for a feature or a one-way-door decision — a Working-Backwards PRD whose whole top half is WHY before any WHAT.
Use when recommending controls or evaluating whether a system is secure by construction — apply the classic security principles (least privilege, fail-safe defaults, complete…
Use on every surface before it ships — the pre-merge craft pass. Work the polish checklist (tabular nums, optical alignment, concentric radius, shadow-vs-border, focus, type…
Use whenever a rewrite, redesign, or refactor would remove, replace, or overwrite copy or visuals that are already in place — a tuned headline, a converting landing page, a hero,…
Use before any change touches prod — enumerate what's stateful, what's a one-way door, what's reversible, and who's downstream, so rigor matches risk and the irreversible parts…
Use when deciding whether a deal is real and worth your effort, or what's missing to win it — qualify with MEDDPICC (Metrics, Economic Buyer, Decision criteria/process, Paper…
Use pre-build, for a new idea, or at n=1 — is there a real market and will anyone pay? Run Mom-Test conversations on real prospects, hunt commitment + advancement, say "no one…
Use whenever a surface will be seen on more than one screen size or input — which is almost always (62%+ of web traffic is mobile).
Use when ops work is manual, repetitive, and scaling with growth (manual deploys, hand-run migrations, copy-paste fixes, ticket-driven provisioning) — identify the toil and…
Use when reliability/recoverability is being assumed rather than proven — deliberately inject the failure (dependency down, AZ/region loss, restore from backup, failover, on-call…
Use when surfacing findings — lead with the unmet need and what to do about it, ranked by confidence; never dump a transcript or a deck. The output is a decision, not data.
Use when reviewing a proposed architecture, a tech plan, or a PR for soundness — drive it to correctness/simplicity/fit, enable rather than gatekeep, flag the open gate without…
Use FIRST, before hunting any bug — write down the system's trust model (who can reach what, which callers are already trusted, what the deployment model is).
Use to keep problems distinct from solutions — map how people actually think about getting their job done (their cognition, reactions, guiding principles), deliberately separated…
Use on a discovery or first real sales call — diagnose the buyer's problem with SPIN + Gap Selling (current → future → quantify the gap) before pitching anything; problem → impact…
Use when entering a codebase, before any design or estimate, or when your mental model has gone stale — read width AND depth and refresh the C4-level picture; a design from a skim…
Use when scoping or describing a feature — reframe it as the job the user is hiring it for (the outcome in their words), not the feature itself.
Use when you'd otherwise pitch features or send a comparison sheet — lead with a true, non-obvious insight that reframes the buyer's own problem and points to your strength…
Use when writing any words inside the UI — button verbs, labels, empty/error/success messages, tooltips, confirmations, onboarding.
Use whenever a change is heading to production or you're asked "is this ready to ship / is it live / is it healthy" — adopt the you-build-it-you-run-it posture and verify by…
Use when a verdict rests on a measured quantity rather than a single deterministic assertion — a noisy/probabilistic output, a performance number, an accuracy or conversion rate.
Use when code does anything cryptographic — hashing passwords, encrypting data, signing tokens, generating randomness — catch the common crypto misuse and never let anyone roll…
Use when price, discount, or terms come up at the deal's end — hold value, trade don't give (every concession buys something back), use tactical empathy and calibrated questions.
Use when writing code that touches I/O, state, concurrency, or external systems — design for failure: validate inputs, fail fast, be idempotent and concurrency-safe, and make it…
Use when a new dependency is added, a CVE is reported, or the build/CI pipeline is reviewed — assess reachability not just presence, pin and lock deps, and treat the…
Use when the build implies quality beyond "it works" — sweep the non-functional surface: performance under load, accessibility, the obvious security holes, and…
Use whenever you (or AI) produce or review a UI draft — your prime reflex against generic, templated design.
Use when handing an initiative or a chunk of work to the engineer — produce a brief with C4-level structure, the exact contract, acceptance, file/seam pointers, illustrative code,…
Use when gathering directly from people — talk about their life and specific past behavior, not your idea; get past Q&A into story; embrace silence.
Use to validate that a design actually works for real people — when a flow is built or prototyped and you need to know if users can do the job.
Use when a security incident is suspected or active (breach, leaked secret, active exploit, suspicious activity) — run the NIST lifecycle: contain, eradicate the root cause,…
Use when the feature is AI/LLM-powered (generation, summarization, classification, agents, RAG) — its acceptance is an EVAL, not "it runs." Define the dataset, graders,…
Use before you run anything — statically walk every user journey end-to-end (happy path plus the error, empty, returning-user, and cancel states) by reading flow + spec + code, to…
Use when assessing founder conviction and "why you / why this" — separate a genuine haunting from FOMO.
Use when cloud spend is rising, unexplained, or unattributed, or before provisioning expensive resources — treat cost as an engineering metric: make it visible, attribute it, find…
Use to turn a raw transcript/doc into structured knowledge — break it into nuggets (one observation + its receipt + a tag), then build themes UP from the codes; never a wall of…
Use when judging whether "good" is good enough now — 10x is the floor, the visible playbook is a commodity, and the best companies are icebergs.
Use when reviewing an LLM feature, AI agent, RAG system, or tool/MCP integration — treat the OWASP LLM Top 10 as its own attack class: prompt injection, excessive agency, tool…
Use before gathering — pick the method by the question (attitudinal vs behavioral, qual vs quant), match the source to what you need to learn, and right-size the rigor to the…
Use when scoping any user-facing surface — require a whole-surface design up front; ship in slices, but each slice lands in its final place, nothing bolted on to be re-placed…
Use when scoping how to land a change — prefer small, short-lived, independently-safe increments over a big-bang merge; keep the codebase deployable; gate risky changes behind…
Use before attacking a build that has any lifecycle, phases, or persisted progress — enumerate the states, transitions, and guards, then probe every transition under crash / kill…