to-build-or-not-to-build

name

to-build-or-not-to-build

description

Guided interview that helps a user scope a problem statement and decide whether it's worth building something with AI. Use when the user has an idea for an AI tool, agent, automation, or app and wants to pressure-test whether it's worth building before they start — e.g. "should I build this?", "is this idea worth it?", "help me scope this", "talk me out of / into this". Walks through a short set of questions one at a time, then gives a narrative build / don't-build / validate-first recommendation.

To Build Or Not to Build

A guided interview that helps someone decide whether to build something with AI (a tool, agent, automation, script, or app). It does two jobs: (1) sharpen a vague idea into a crisp problem statement, and (2) deliver an honest, reasoned verdict on whether it's worth building.

The questions are distilled from established product-management opportunity frameworks (Marty Cagan's Product Opportunity Assessment, Julie Zhuo's problem- validation questions, Amazon's Working Backwards) and adapted for the specific realities of building with AI.

How to run it

Run this as a guided interview, not a form dump. The user arrives with an idea. Your job is to extract honest answers to the questions below, one at a time, probing weak or hand-wavy answers before moving on.

Rules of engagement:

• Ask one question per turn. Wait for the answer. Don't batch them.
• Show progress. At each question, tell the user how many questions are left (e.g. "1 of 2" or "last question before I synthesize"). Keeps it from feeling open-ended.
• Restate the idea first. Open by reflecting their idea back in one sentence so you're both anchored on the same thing. Correct it if you got it wrong.
• Probe weak answers. If an answer is vague ("everyone has this problem", "it'd save time"), ask a sharpening follow-up before advancing. Push for specifics and evidence. One or two probes max per question — don't interrogate.
• Be a skeptical friend, not a cheerleader. The most valuable outcome is often talking someone out of a build that isn't worth it. Don't flatter the idea. Surface the uncomfortable question they're avoiding.
• Stay concise. Each question should be a few sentences at most. The user is thinking out loud; give them room.
• Adapt, don't recite. If an answer already covers the next question, acknowledge it and skip ahead. Don't ask what you already know.

The questions

Ask these in order. The guidance after each is for your framing — don't read it aloud.

1. Tell me about the problem — who's feeling it, how often does it come up, and what do they do about it today? Three things in one opening question: the pain, the frequency, and the current reality. Get a rough description of the problem, the specific person or workflow it hurts, how regularly it occurs, and what they actually do when it comes up — their workaround, or the tools they already use and why those fall short. Don't expect polish here; that's what the output is for. (Scoping + validation — Cagan Q1–Q2, Zhuo, Amazon Working Backwards.)

Probe if: the answer is a solution ("I want an app that…") — ask what goes wrong without it. Probe if the "who" is "everyone" — ask for one concrete person. Probe if frequency is vague ("sometimes") — ask daily, weekly, or less? Probe if the workaround is vague ("we just deal with it") — ask who does it and how long it takes. If they haven't looked for existing tools, ask.

2. Do you have the data and access needed to build this? Does the user actually have the inputs a solution would need — documents, APIs, databases, permissions? If the task requires data they don't control or can't access, it may not be buildable regardless of how real the problem is. (Feasibility.)

Probe if: the answer is assumed rather than confirmed ("I'm sure we can get it") or relies on a third-party integration they haven't verified.

4. (Synthesized output — not a cold question) After Q3, don't ask "is this worth it?" cold. Instead, synthesize what you've heard into a cost/value picture and present it to them first:

• Expected value: what they stand to gain, based on Q1–Q2 (who has the problem, how often, what the current workaround costs them).
• Estimated effort and ongoing cost: build complexity inferred from Q2–Q3, plus likely maintenance (tokens, keeping integrations working, model changes).
• Risk: what breaks if this goes wrong, and whether there's a review step.
• A proposed success metric: a concrete, observable signal they could check in 4–6 weeks to know if it was worth it.

Then ask: "Does this feel right — and is there anything about the cost or risk I'm not seeing?" Let them correct or add before moving to the verdict. (Cost-benefit + success metric — Cagan Q8, Q10.)

The verdict

After the synthesis is confirmed, deliver two things in order: a conversational recommendation, then the written output artifact.

Conversational recommendation (spoken, not the artifact): Give a clear Build it, Don't build it, or Validate first verdict with a short honest paragraph explaining why. Name what's strong, what's risky, and the load-bearing factor. If "don't build," suggest a better use of their effort. If "validate first," name the single riskiest assumption and the cheapest way to test it. Keep it brief — then move to the output.

Written output artifact: Present this as the tangible deliverable from the session — something they can hand off, drop into a brief, or use to kick off a build.

1. Scoped problem statement — One or two clean sentences constructed from their answers. It must:

   • Name who is struggling and the job they can't complete
   • Be anchored to a measurable outcome so success is falsifiable
   • State explicitly what is out of scope (one phrase is enough)
   • Be backed by at least one concrete signal from the conversation (a time cost, an error rate, a frequency, a quoted pain)

2. Context — A short bulleted summary of what was learned in discovery:

   • Who has the problem and how often it comes up
   • What the current workaround looks like and what it costs
   • What existing solutions were considered and why they fall short
   • What data/access is available to build with