---
title: "Stop shipping features nobody asked for because the roadmap said so"
canonical_url: https://ampl.webclat.com/use-cases/stop-shipping-features-nobody-asked-for
description: "A feature can ship on schedule and still fail. Tie the roadmap to a decomposed north star metric and a pre-launch experiment, so 'the team said they wanted it' isn't the only evidence."
source: Webclat | Amplitude Solutions (official Amplitude partner, independent consultancy)
---

# Stop shipping features nobody asked for because the roadmap said so

**In short:** We decompose your north star metric into the specific inputs a feature is supposed to move, and check the feature's expected impact against that tree before it ships - not after. A roadmap item earns its spot by tracing to a metric someone will actually check, not by being the idea that got the most nods in a meeting.

## The situation

A feature ships on time, on budget, exactly as scoped - and six months later usage is near zero and nobody remembers why it was prioritized.

## The pain

Engineering time gets spent building things that felt important in the room but never connected to a number anyone tracks, and the team that questioned the idea early gets ignored until the usage chart proves them right too late.

## What we implement

We decompose your north star metric into its input metrics and require every roadmap item to name which input it's supposed to move before it's built - what's called metric-tree roadmap validation - so 'the data said they would' is checked against a tree, not a feeling.

## What you get

- Roadmap items that trace to a specific metric before engineering time is spent, not after
- A documented reason a feature shipped, so a failure is diagnosable instead of mysterious
- Fewer features built and then quietly forgotten because nobody asked what they were supposed to move

## Illustrative

A team that prioritized a feature because 'multiple customers asked for it' might find, once traced against the metric tree, that none of those customers represent the segment the north star metric actually depends on - useful to know before the sprint starts, not after the usage chart comes back flat. (Illustrative scenario - not a measured result.)

## FAQ

### Doesn't this slow down shipping by adding a metric-mapping step to everything?

It adds a short exercise before a feature is greenlit, not a gate on every ticket - the point is to catch the roadmap items with no metric story before they consume a sprint, which is usually faster than building the wrong thing and re-litigating it in a retro.

### What if we don't have a north star metric defined yet?

That's the prerequisite step - our north star metric worksheet runs a leadership team through choosing and decomposing one in a single working session, before roadmap validation can attach to anything.

Related: [North star metric, defined](https://ampl.webclat.com/glossary/north-star-metric), [Free north star metric worksheet](https://ampl.webclat.com/resources/north-star-metric-worksheet), [Amplitude Experiment: web vs. feature flags](https://ampl.webclat.com/blog/amplitude-experiment-web-vs-feature)