I have a technical decision to make between two options. Translate the tradeoff into business-shaped language a non-technical exec (CFO, CEO, Head of Sales) can decide on. For each option produce: - Cost: in money, time, or both. Specific numbers if I've given them. - Capability: what becomes possible (or impossible) with this choice. In business terms - 'handles 100x growth' not 'eventually consistent'. - Risk: what could go wrong. Include the engineer-side risk that the team might be motivated to downplay. - Timeline: when each option pays off (immediately, year 1, year 2-3, etc.). End with a one-line recommendation AND a 'when to revisit' clause - the conditions under which we'd reconsider this decision. No jargon in the option descriptions. If a concept needs jargon, define it inline in plain language. Option A: {{option_a}} Option B: {{option_b}}
Engineering tradeoff explainer
Example output
Option A: Postgres with logical replication.
Cost: ~2 weeks engineering time, no new vendor cost (we're already on Postgres).
Capability: Can handle our current data volume + 10x growth without rearchitecture. Standard tooling everyone already knows.
Risk: Schema changes still require coordination - if we get this wrong, a future migration is painful. Manageable with discipline.
Timeline: Pays off immediately; future-proof for ~2 years of growth.
Option B: Move to DynamoDB.
Cost: ~6-8 weeks engineering time + ~$3k/month in vendor cost + retraining the team.
Capability: Handles 100x growth without thinking about it. Better fit for the cross-region replication we don't need yet.
Risk: New tooling, team has no operational experience, harder to debug. The kind of risk that doesn't show up until production load hits.
Timeline: Pays off in year 2-3 if we hit hyper-growth scenarios. Negative payoff in year 1.
Recommendation: Option A. We're solving a problem we have, not a problem we might have. Revisit if growth exceeds 5x year-over-year for two consecutive quarters.
Common mistakes
Don't let the model use jargon in either option's description. 'Eventual consistency' is jargon. 'Some users might see slightly out-of-date data for up to 30 seconds' is the version a CFO can evaluate. Also: do not skip the 'risk' section. Engineers will sometimes downplay the risk of the option they prefer; the prompt's job is to surface both, including the downside they might be motivated to minimize. Third mistake: a recommendation without a 'when to revisit' clause. Tradeoff decisions get made once and then forgotten until they break - the revisit clause makes them inspectable later.
More from AI Prompts for Product Managers
PRD draft from a one-line problem
Act as a senior product manager. I'm going to give you a one-line problem statement. Before drafting any PRD, do this: 1. State the…
Customer interview synthesis
Read the raw customer interview transcripts below. Produce: 1. The top 5 themes ranked by frequency (number of interviews where the theme…
Stakeholder weekly update
Convert my raw bullets below into a weekly stakeholder update. Use exactly three sections: 1. Shipped: each item with a one-line outcome,…
Why it works
Engineering tradeoffs are where PMs lose the room. The mistake is presenting a technical decision in technical terms ('do we use Postgres or DynamoDB') and watching the non-technical execs nod and then disengage. This prompt converts the technical tradeoff into a business-shaped decision: paste the two options with their technical descriptions, get back the version a CFO or non-technical CEO can decide on - cost (in money or time), capability (what becomes possible or impossible), risk (what could go wrong), and timeline (when each pays off). The output is one paragraph per option plus a one-line recommendation, written in language that doesn't require knowing what 'eventual consistency' means. Tested cleanest on Claude Opus 4.7.