Technical Roadmaps

# Technical Roadmaps - All Guest Insights

*1 guests, 2 mentions*

---

## Will Larson
*Will Larson*

> "The first rule of strategy is that if you write it down, then you can improve it. If it's not written down, it's hard to say if this PM is just not a good PM or if they're trying to apply the strategy that they've misunderstood... If you have a written document, even if it's not a super compelling strategy, at least you can start debugging."

**Insight:** A written strategy is essential for organizational alignment and provides a baseline that can be critiqued and improved.

**Tactical advice:**
- Document the strategy even if it is imperfect to allow for 'debugging' and alignment
- Use the Richard Rumelt framework: Diagnosis, Guiding Policies, and Actions

*Timestamp: 00:18:21*

---

> "A common strategy that's really good but very boring is we only use the tools we have today. So a lot of times you'll get engineers that want to introduce new programming languages, new databases, new cloud providers. And a really good strategy for almost all companies is like we just use the standard kit we already have today."

**Insight:** Boring strategies that enforce technical constraints allow teams to focus their limited energy on solving core product problems rather than tooling.

**Tactical advice:**
- Create a 'standard kit' of approved tools to limit technical sprawl
- Focus engineering energy on business-valued problems rather than technical novelty

*Timestamp: 00:19:39*




---
name: technical-roadmaps
description: Help users create technical roadmaps. Use when someone is planning engineering work, prioritizing tech debt, building architecture roadmaps, or aligning technical and product strategy.
---

# Technical Roadmaps

Help the user create effective technical roadmaps using frameworks and insights from 1 product leader.

## How to Help

When the user asks for help with technical roadmaps:

1. **Understand the context** - Ask about their current technical state, team size, and business constraints
2. **Ensure it's written down** - A strategy that isn't documented can't be debugged or aligned around
3. **Apply the Rumelt framework** - Structure as Diagnosis (what's the problem), Guiding Policies (principles for decisions), and Actions (what you'll do)
4. **Favor boring strategies** - Help them resist the urge to introduce new tools when existing ones would suffice

## Core Principles

### Write it down
Will Larson: "The first rule of strategy is that if you write it down, then you can improve it. If it's not written down, it's hard to say if this PM is just not a good PM or if they're trying to apply a strategy they've misunderstood." A written strategy provides a baseline that can be critiqued and improved.

### Boring strategies often win
Will Larson: "A common strategy that's really good but very boring is we only use the tools we have today. Engineers want to introduce new programming languages, new databases, new cloud providers. A really good strategy for almost all companies is we just use the standard kit we already have." Focus engineering energy on business-valued problems rather than technical novelty.

### Use the Rumelt framework
Structure technical strategy using Richard Rumelt's framework: Diagnosis (what's the core challenge?), Guiding Policies (what principles will guide decisions?), and Actions (what specific things will you do?).

### Create a standard kit
Define a list of approved tools, languages, and platforms. This limits technical sprawl and allows teams to focus on solving core product problems rather than reinventing infrastructure.

## Questions to Help Users

- "Is this technical strategy written down somewhere that anyone can reference?"
- "What is the core technical challenge you're trying to solve (the diagnosis)?"
- "What principles will guide your technical decisions (the guiding policies)?"
- "Are you adding new tools because you need them, or because they're interesting?"
- "What does your