O Construtor de Matriz de Decisão: Transforme uma Decisão Multiopção em uma Recomendação Ponderada e Defensável
Porque é que este prompt importa
Undocumented gut-call decisions get re-litigated the moment results are anything less than perfect, because there's no record of what was actually weighed. A written, weighted analysis with an explicit sensitivity check settles the argument the first time, and gives you a concrete artifact to revisit if the underlying assumptions change, instead of relying on someone's memory of a conversation that happened weeks earlier.
Para que o usamos
You're facing a decision with three or more viable options — a vendor selection, an infrastructure migration path, a hiring choice between finalists, a build-versus-buy call — and need to present a recommendation that will hold up when a skeptical stakeholder asks why you didn't pick a different option.
Prompt
Role: Act as a senior decision-analysis consultant who helps executives and teams make high-stakes, multi-option decisions using structured, defensible frameworks — the kind of analysis that survives being challenged in a leadership meeting. Context: - The decision I'm facing: [DESCRIBE THE DECISION IN 1-2 SENTENCES] - The options I'm considering: [LIST 3-6 OPTIONS, ONE PER LINE] - The criteria that matter for this decision: [LIST 4-8 CRITERIA, e.g. upfront cost, time-to-value, team capacity required, reversibility, strategic fit] - Any hard constraints or dealbreakers: [LIST ANYTHING THAT AUTOMATICALLY DISQUALIFIES AN OPTION, OR WRITE "NONE"] - Who else needs to be convinced by this analysis: [E.G. "MY CO-FOUNDER," "THE BOARD," "MYSELF ONLY"] Task: 1. First, propose a weighting (out of 100 total points) across the criteria I listed, and explain your reasoning for each weight in one sentence. Pause here so I can adjust before you proceed. 2. Score each option against each criterion on a 1-10 scale, with a one-line justification for every score — no unexplained numbers. 3. Calculate the weighted total for each option. 4. Identify the top-scoring option and flag any options that are statistically too close to call (within 5% of each other). 5. Run a sensitivity check: identify which single criterion, if reweighted by plus or minus 15 points, would change the recommended option. State explicitly if this exists — a fragile recommendation should be labeled as such. 6. Write a final recommendation in plain language, including the strongest argument against your own recommendation and why you're making it anyway. Constraints: - Do not silently round close scores into a false sense of certainty — say explicitly when the decision is close. - Do not use vague criteria labels — operationalize each one in half a sentence before scoring. - If any option violates a stated hard constraint, exclude it from scoring entirely and explain why. - Keep the tone analytical and neutral — no cheerleading for any option. Output Format: 1. A markdown table: rows = options, columns = criteria plus weighted total, sorted highest to lowest. 2. A short "How I Weighted This" section (2-4 sentences). 3. A "How Close Is This" section flagging any near-ties or fragile results. 4. A final recommendation paragraph including the steelman case against it.
Resultado
How I weighted this
I weighted Time-to-Value highest (30 points) because your Friday deadline and board skepticism suggest speed-to-first-results matters more than long-term elegance right now. Risk of Outage (25 points) comes second since you're mid-fundraise and a customer-facing incident would be costly beyond the technical fix. Team Capacity Required (20 points) reflects your 12-person team's limited bandwidth. Reversibility (15 points) and Total Cost Over 12 Months (10 points) round it out — cost matters less than the other three given your current runway.
| Option | Time-to-Value (30) | Risk of Outage (25) | Team Capacity (20) | Reversibility (15) | Cost (10) | Weighted Total |
|---|---|---|---|---|---|---|
| Lift-and-shift | 9 — deployable in 2 weeks with minimal refactoring | 6 — moves existing fragility as-is, doesn't fix root causes | 8 — low engineering lift | 9 — easy to roll back to on-prem if needed | 5 — higher ongoing cloud spend from unoptimized resources | 78.5 |
| Containerize-and-migrate | 6 — 6-8 week timeline for containerization work | 8 — improves isolation and rollback granularity | 5 — requires Docker/K8s ramp-up for two engineers | 7 — moderately reversible, some rework needed | 7 — better resource utilization | 67.5 |
| Full re-architecture | 2 — 4-6 month timeline, misses your deadline entirely | 9 — addresses root causes directly | 2 — consumes most of the team's bandwidth for two quarters | 3 — hard to reverse once started | 8 — best long-term unit economics | 44.5 |
How close is this
This isn't close — lift-and-shift leads containerize-and-migrate by 11 points, well outside the 5 percent fragility threshold. The one criterion that could flip the recommendation is Time-to-Value: if you reweighted it down by 15 points (to 15) and shifted that weight to Risk of Outage, containerize-and-migrate would edge ahead by roughly 3 points. Worth flagging to your board member if they push back on speed as the top priority.
Recommendation
Go with lift-and-shift for this cycle. The strongest argument against this: it doesn't fix any of the architectural problems that got you here, and you'll likely be having this exact conversation again in 9-12 months once traffic grows. But given your Friday deadline and board skepticism, a working migration you can demo now is worth more than a better migration you can't show yet. Plan the containerize-and-migrate path as your Q2 follow-up, not a competing option for this decision.
A maioria das decisões de alto risco com múltiplas opções é tomada por instinto disfarçado de análise — um líder escolhe a opção que "parecia certa" e depois constrói uma justificativa por engenharia reversa se alguém perguntar. Isso funciona bem até a decisão dar errado, momento em que não há registro do que realmente foi ponderado, e a conversa degenera em "por que não consideramos X" sem uma boa resposta.
Por que este prompt é estruturado desta forma
O prompt pede ao modelo que proponha os pesos primeiro e faça uma pausa para confirmação antes de pontuar qualquer coisa. Essa ordem importa: se a ponderação e a pontuação acontecem no mesmo passo, é fácil para um modelo (ou uma pessoa) reconstruir inconscientemente pesos que produzam a resposta que já queria. Separar as etapas obriga a lógica de ponderação a se sustentar sozinha, defensável independentemente de qual opção acabe vencendo.
A instrução de justificar cada pontuação individual em uma frase — não apenas os totais finais — é a segunda restrição fundamental. Uma matriz ponderada com números não explicados não é mais rigorosa que uma decisão instintiva; é uma decisão instintiva vestida de planilha. Forçar uma justificativa de uma linha por célula torna o raciocínio auditável.
A etapa que a maioria dos frameworks pula
A verificação de sensibilidade — identificar qual critério único, se reponderado em ±15 pontos, inverteria a recomendação — é o que separa isso de um modelo de pontuação estático. A maioria das matrizes de decisão apresenta um instantâneo de um único momento e implica uma confiança falsa. Uma decisão apertada que se inverteria com uma reponderação modesta e defensável é fundamentalmente diferente de uma decisão robusta em uma ampla faixa de ponderações razoáveis.
Onde este prompt comprova seu valor
Isso não é para decisões triviais — escolher um lugar para almoçar não precisa de uma matriz ponderada. Foi criado para o punhado de decisões multiopção por trimestre que são caras de errar e onde um processo documentado importa tanto quanto a resposta: seleção de fornecedores, rotas de migração de infraestrutura, candidatos concorrentes a uma vaga, decisões de construir versus comprar.