The Four B’s of AI: A compass for product judgment

I was in a collab session with a client awhile ago where they pasted some rather hastily jotted feature requirements into an AI tool — admittedly as an experiment — and typed in: “generate a usable, intuitive UI for this feature.” No contextualized rationale for what those words meant. No articulation on what they’d assumed about the customers it was meant to serve. Just…generate it! 😅

I’ve been thinking a lot about that moment (and others with clients and gathered via LinkedIn posts) mostly because it’s not really about the AI. It’s about what happens to sensemaking under pressure — how quickly a team will trade the discomfort of a probing question for the relief of a quick answer, and call the trade “efficiency.” The tool didn’t cause that. It just made the trade frictionless enough to happen without anyone noticing. 🫠

Over the past few months, working with some clients on UX projects, I’ve been developing a small discipline against exactly this — a way of using AI as a collaborative partner that resists the sycophantic, seductive, yes-machine gravity most tools default to. I call it the Four B’s: Blindspot → Branch → Bridge → Blueprint.

Each one is a deliberate counter-move against a specific way teams stop thinking when they’re moving fast.

👁️‍🗨️ Blindspot is the analysis itself — a gut check before you commit to a direction. Not “does this look right,” but “what am I too close to see.” It’s not about asking AI to validate the brief (or requirements). It’s about asking it to disclose what the brief is quietly assuming — about the people it’s for, the jobs they’re actually trying to do, the constraints everyone’s stopped questioning because questioning them felt like a distraction from shipping, etc, etc.

A prompt I like to use: What would a skeptical exec from outside this domain say is wrong with how we’ve framed this problem?

The point isn’t to be told you’re wrong. It’s to hear the version of wrong you’d likely not generate on your own, because you’re standing too close to see the shape of it. 🤔

🪾 Once you’ve read the situation honestly, Branch is what you do with that discomfort — you don’t just quickly resolve it in one-shot, you multiply it! This is where the single-solution trap opens up: ask AI for “a solution” and you’ll get the most statistically obvious (aka “homogenized mediocrity”) one, dressed up to look well-considered. Lots of beige, ochre, orange, with large serif fonts in a standard layout. Ask for eight distinct approaches — not variations, not a solution with five mid-level paint jobs — and you’re forcing real divergence, the kind that surfaces directions a team might not have reached by iterating on its first idea. A prompt that does effective work for that:

What would the solution be like if we removed the key constraints we’ve been considering as fixed? Generate 8 distinctly different approaches of interaction model and interface layout.

I’ve learned in the last 20+ years that half the time the supposed constraint wasn’t fixed or real — it was just unexamined. 🙃

🌉 Divergence without a way back to reality is just noise, though — which is what Bridge does to prevent. Bridge is the step where you connect back to those prior definitions and assumptions. You take the branches and correlate them against what actually matters — validated requirements, strategic drivers, the customer insight that either supports a direction or quietly nullifies it. Which of these directions is most defensible to a skeptical VP of Product, and what evidence backs it? is the prompt I apply, because “defensible” is the crux of the matter. It’s the difference between legit choice and personal preference — judgment as reasoned accountability, not a whim of the moment.

𝌭 And then there’s Blueprint — the step everyone skips because the decision already feels done and the teams “needs” to ship it fast. 🙄 But a decision without its reasoning attached doesn’t survive the next reorg, the next hire, the next six months of institutional forgetting. Ask AI to document the rationale & situations as if you’re writing it for someone joining the team after you’re gone, for example: What are the five most likely edge cases, and how should each be handled while supporting the UX principles and brand proposition?

You’re not meticulously documenting a perfected, polished design. You’re building a shared understanding that was supposed to exist before the sprint started, and usually doesn’t. That’s what needs to persist for knowledge & historical value as the team, product, and company evolve. Who knows where everyone is 12-18 months from now?

Now, really none of this requires AI — technically. I mean, you could just do all four moves with a whiteboard and a patient colleague. 😅 But most teams don’t have a patient colleague anymore — they have an artificially urgent deadline, a tiresome Slack thread, and a mandated tool that will happily generate the first plausible thing you ask for. The Four B’s isn’t really a prompting technique.

It’s a way of refusing to let the tool’s fluency substitute for your own judgment, at exactly the moments judgment is most expensive and most tempting to skip.

If you’ve spent time with my recent trilogy of the Janitor and the Architect — the Stranger keeps circling back to a compass, and is careful to point out it’s not the kind that points north. It’s the kind that points toward coherence: a way of reading what a situation actually requires before you reach for a tool, a title, or an answer. The Four B’s is that compass held up specifically against AI’s special kind of seductive gravity — its fluency, its speed, its endless willingness to generate something before anyone’s asked whether it should exist. Blindspot is the initial reading, the analysis of what could go wrong. Branch, Bridge, and Blueprint are what you do once you’ve read it correctly.

So here’s the question I’d leave you with, the same one I’m now asking myself in these collab sessions: When the deadline tightens, which B does your team quietly drop first? And is that maybe the moment your compass mattered most? 🙃

If you want to test that against your own work, here’s the full set of prompts I’ve been using, with some variations/tweaks along the way…enjoy! 🙌🏽

Copy, paste, adapt to your own situation, etc. These are the prompts I often use, not polished for this post, just the ones to keep me and my clients moving forward:

👁️‍🗨️ Blindspot

• What assumptions about people, jobs, tools, goals, contexts are buried in this brief/requirements doc that should be questioned? Prioritize the list against severity of impact or consequence to the customer and the business.

• What would a skeptical PM, SME, or business leader/exec from [domain xyz] say is inaccurate or incorrect with this framing? Prioritize the list against severity of impact or consequence to the customer and the business.

• What do we think we know about our primary users [given xyz domain materials] that might not hold? Prioritize the list against severity of impact or consequence to the customer and the business.

🪾 Branch

• Generate 8 distinct approaches to this problem, NOT variations of the same idea. Consider interaction model, interface layout, and navigational scheme.

• What directions have we probably not considered? Push beyond obvious [industry xyz] conventions. Weave in concepts from lateral/adjacent domains like T, K, L.

• What would this solution be like if we removed the key constraints we’ve regarded as fixed? Explain the risks and tradeoffs that would be required.

🌉 Bridge

• Map each option against each requirement and identify where they conflict or align.

• Which of these directions is most defensible to a skeptical VP of Product? What evidence supports it? Tie back to identified measures of success, including ARR, etc.

• What customer insight most directly argues for or against each option?

𝌭 Blueprint

• Document the design rationale for this pattern as if you’re writing it for a new engineer/designer joining the team in six months.

• What are the five most likely edge cases for this flow, and how should each be handled?

• Write the acceptance criteria for this interaction from a design perspective.