Who Asked for This?

An engineer at a Series B startup recently did something their leadership team probably didn't want done: they traced 22 features back to their origin. Three came from actual customers. Six were competitive reactions — someone saw a competitor ship something and panicked. Four came from a single executive's Slack channel. Three were tech debt dressed up as roadmap items. And six couldn't be explained at all. When they asked around, the answer they got was "I think it was from that offsite in Q3" or just shrugs.

This story spread through engineering communities because it hit something true. Not as a horror story. As Tuesday.

Another team tried a similar audit — tracing tickets to any source at all, anything with a timestamp and a customer name. They landed at 14% traceable. The other 86%? Vibes.

This is what roadmap entropy looks like from the inside. Features don't appear because someone decided they were the most valuable possible use of engineering capacity. They appear because no one stopped them. Competitive anxiety generates a ticket. An executive's passing thought becomes a sprint. Tech debt gets repackaged as a feature so it can compete for priority. And the absence of a real "why" gets filled by whoever is willing to tell a story.

The result is a team that's always busy and rarely proud.

Three Legitimate Sources of Work

Not every feature needs a customer origin. Internal conviction, technical investment, and deliberate bets on where the market is going are all legitimate. But they need to be exactly that — deliberate.

Customer pull: someone with a real problem asked for this, or research shows it's blocking adoption or expansion. The connection is traceable. You can name the source.

Strategic conviction: leadership made a decision — not because a competitor did it, but because they have a thesis. A belief about where the market is going, what your customers will need next, or what will create durable differentiation. The iPhone is the canonical example. No customer asked for a phone without a keyboard. But that wasn't a random bet; it was a disciplined conviction about how computing was about to change.

Technical investment: this reduces drag or prevents future failures. It's a bet on the system's capacity to serve the first two sources. When it gets mislabeled as a feature — because labeling it honestly means competing for priority — that's a symptom of dysfunction, not a solution to it.

Everything else is noise. And noise is expensive. It consumes the same engineering capacity as real work, occupies the same sprint slots, and generates the same maintenance burden, without generating a proportional return.

The Competitive Reflex

The most common source of roadmap noise isn't rogue executives or mystery offsites. It's the competitive reaction. A competitor ships something, someone senior sees it, and a ticket appears. This pattern is particularly insidious because it feels rational. It looks like market awareness. It comes with a story.

But reacting to competitors means letting them set your roadmap. You're building what they decided to build, probably six to twelve months after they made that decision, and almost certainly without the customer signal that drove it. You're optimizing for their hypothesis about their customers. Not yours.

The companies that win don't watch competitors to know what to build. They watch customers. Competitors are useful for understanding the surface area of the market — what problems exist, what solutions people will pay for. They're not useful for selecting next sprint's work.

When someone says "we need to build X because Competitor Y just shipped it," the question isn't "how long will it take?" It's "what customer problem does this solve, and do our customers actually have it?" If there's no answer, the feature doesn't deserve a ticket.

Why This Is a Leadership Problem

It's easy to frame roadmap entropy as a product management failure. The PM didn't enforce discipline. Discovery was weak. The backlog wasn't groomed.

But in most cases we've seen, the product function isn't the actual failure point. Product managers are caught between what customers say they want, what sales says they need to close deals, what executives decide is strategic this week, and what engineering can actually deliver. That's a cross-functional coordination problem. It requires someone who can look at the full picture — technical feasibility, strategic fit, customer demand, resource cost — and say "not this one." Consistently. At every intake channel. Regardless of who's asking.

That's a CTO function. And in startups that either don't have technical leadership or have one buried in execution, this function goes unfilled. The backlog becomes a first-in, first-out buffer. The roadmap becomes a list of everything nobody said no to.

The pattern is predictable: without a technical leader whose job includes defending why, every feature gets in on the strength of whoever sponsors it most aggressively. The loudest executive wins. The most recent competitive sighting wins. The offsite idea that nobody pushed back on wins. And the team ships 22 things, three of which anyone actually needed.

The Feature You Don't Build

The best technical leaders we know aren't the ones who shipped the most features. They're the ones who prevented the most regrettable ones.

Keeping work out of the system is harder than getting it in. Every feature has a sponsor, a story, and a reason that sounds compelling in the moment. Saying no requires seeing past the story to the underlying question: does this serve the people we're trying to serve, or does it serve our anxiety about not doing enough?

The discipline is traceability. Every item that enters the roadmap should be traceable — to a customer, to a strategy decision, to a technical investment with a clear return. If it can't be traced, it doesn't belong in the queue. Not because we're rigid, but because vague justifications for building things always become clear regrets after you've built them.

This isn't overhead. It's the work. Understanding why before committing to what is the highest-leverage thing a technical leader does. Every week that runs without that question being asked, the entropy compounds. The team gets faster at building the wrong things. The roadmap fills up with things nobody defends.

Traceability as Culture

The teams that fix this don't do it by adding process. More rituals, longer planning cycles, heavier templates — these are the wrong response. They create drag without adding clarity.

What actually changes is simpler and harder: "who asked for this?" becomes a normal question, not a challenge. Traceability is expected, not aspirational. Someone in the room is empowered to require a real answer and trusted enough that when there isn't one, the item doesn't move forward.

That standard, held consistently across every intake channel, is what separates teams that build with conviction from teams that build with momentum. Momentum moves. It doesn't always go somewhere worth going.

If your roadmap looks more like a list of everything nobody blocked than a deliberate sequence of investments, the issue isn't your tooling or your sprint structure. It's the absence of someone whose job is to hold that standard — week after week, with every stakeholder, at the moment it matters.

That's what we do. If you're shipping fast and wondering whether any of it was right, let's talk.