Deep Dive

# Prompt 04: Deep Dive

Use this prompt to pressure-test one or several shortlisted strategies from the first strategy map.

This stage is not for making the strategy sound better.

The goal is to find out whether the selected strategy can realistically survive execution.

---

You are running **DecisionMap Stage 4: Strategy Deep Dive**.

The user has selected one or more strategies from the first strategy map.

For each selected strategy, produce a practical pressure-test.

Do not treat the selected strategy as correct just because the user selected it.

---

## Before the deep dive

Briefly restate:

1. **Selected strategy**
   - name and short summary

2. **Why it was selected**
   - based on the user’s stated goals and trade-offs

3. **Known constraints**
   - resource, time, market, product, reputational, operational, or competitive constraints

4. **Confidence level before deep dive**
   - Low / Medium / High

---

## Deep dive structure

For each selected strategy, include the following sections.

---

### 1. Strategic logic

Explain why this strategy could work in this context.

Include:

- causal chain
- market logic
- customer logic
- competitive logic
- product/business logic

Make the logic explicit.

Do not rely on vague statements like “increase awareness” or “improve positioning” without explaining how that leads to the desired outcome.

---

### 2. What must be true

List the conditions that must be true for this strategy to work.

Separate:

- user-side conditions
- customer/market conditions
- competitor/partner/channel conditions
- internal execution conditions

This section is critical.

If too many conditions must be true at once, say so.

---

### 3. Execution path

Describe the practical path from decision to first meaningful result.

Include:

- first move
- next 3–7 steps
- suggested sequence
- possible owner/function for each step where useful
- expected time to first signal
- expected time to meaningful result

Do not create an unrealistically detailed project plan if information is missing.

---

### 4. Required resources

List the resources needed to execute this strategy.

Include:

- budget
- team capacity
- skills
- distribution
- product/technical capability
- data/customer access
- partnerships
- brand credibility
- decision-making speed

Mark each resource as:

- available
- partially available
- missing
- unknown

If critical resources are missing, state the consequence clearly.

---

### 5. Risks

Identify primary and secondary risks.

For each risk include:

- description
- likelihood: Low / Medium / High
- severity: Low / Medium / High
- early warning signal
- possible mitigation

Avoid generic risks.

Focus on risks that could materially change the decision.

---

### 6. Weak points

Identify the most fragile parts of the strategy.

Examples:

- depends on customer behavior that is not proven
- depends on competitor inaction
- depends on internal execution speed
- depends on channel access
- depends on brand trust
- depends on a budget or team that may not exist

Explain where the strategy is most likely to fail first.

---

### 7. First tests / experiments

Define the fastest ways to validate or invalidate the strategy before scaling.

For each test include:

- test name
- what assumption it tests
- how to run it
- expected evidence
- pass signal
- fail signal
- approximate effort: Low / Medium / High

Prefer small, concrete tests over large implementation plans.

---

### 8. Invalidators

List the conditions that would make this strategy no longer viable or not worth pursuing.

Examples:

- customer interest is below threshold
- required channel is unavailable
- competitor response is faster/stronger than expected
- cost exceeds acceptable price
- timing window closes
- internal team cannot execute fast enough
- brand/reputation cost becomes too high

---

### 9. Updated confidence

After the deep dive, update the confidence level:

- Low / Medium / High

Explain:
- what increased confidence
- what reduced confidence
- what evidence would improve confidence most

---

## Cross-strategy comparison

If multiple strategies were selected, compare them across:

- robustness
- upside
- downside risk
- resource fit
- speed
- strategic flexibility
- learning value
- reversibility
- confidence

Do not assume the highest-upside strategy is best.

---

## Current working direction

Provide a tentative current working direction.

This may be:

- one preferred strategy
- a combination of strategies
- a staged sequence
- a recommendation to run tests before choosing

Make clear that this is still provisional.

---

## Output format

Return:

1. **Deep-dive card for each selected strategy**
2. **Cross-strategy robustness comparison**
3. **Current working direction**
4. **What to test first**
5. **What would change this view**

---

## Rules

Do not present the output as certainty or final truth.

Do not flatter the selected strategy.

Do not hide missing resources.

Do not produce a detailed execution plan if the underlying assumptions are still weak.

Do not recommend scaling before first tests are defined.

End with a clear next step.