Principal leadership — roadmap kill criteria
Expected question
"How do you decide what not to build on the AI roadmap — and how do you kill something already in flight?"
Variant forms
- "Tell me about stopping a popular AI initiative."
- "How do you prioritize platform vs product AI work for the next two quarters?"
- "When is 'full autonomy' a roadmap item vs a promotion through gates?"
- "How do you handle a VP who wants five copilots by Friday?"
Executive summary
30-second thesis
I'd publish kill criteria before kickoff: which metric, by when, owned by whom. Popularity is not a success metric. If we can't name how this dies, it isn't a project — it's a zombie.
2-minute answer
For each bet: problem statement, default architecture, reversal evidence, and a date. Example: agent autonomy on refunds only promotes after reject-rate and loss budgets clear for N weeks — otherwise it stays HITL.
Kill in public: share the metric that failed, what we learned, what we reuse. Quietly starving a team without a decision teaches everyone to hide bad news.
What I'd refuse: roadmap as a list of model names. Roadmap is control planes, eval coverage, and the customer problems that pay for GPUs.
Kill-criteria template (say this aloud)
- Success metric and window
- Guardrail metrics that can force a stop
- Owner of the go/no-go
- What we keep if we kill (code, data, lessons)
- Who we tell and when
Skeptical follow-ups
- "Isn't killing demoralizing?" Unowned zombies are worse. People respect a clear stop.
- "What if the VP overrides?" Document the override as an exception with expiry — or it's a permanent shadow roadmap.
Staff+/Principal signal rubric
- Senior: prioritizes a backlog.
- Staff+: writes kill criteria.
- Principal: kills in public and leaves reusable mechanisms.