The new product is on the roadmap. Everyone agrees it matters. The budget exists. It has not started, and it will not start next quarter either unless something structural changes. This is one of the most common patterns in companies with a working product and a functioning engineering team, and it is almost never caused by disagreement.
It is caused by the fact that nothing in the working week is arranged to let it begin.
Key takeaways
- Agreement is not a start condition: Everyone agreeing costs nothing and changes nothing.
- Four structural reasons, and usually one dominates: No protected time, no owner, no boundary, no first slice.
- Urgency always wins over importance: Unless something is explicitly protected from it.
- The fix is structural, not motivational: More commitment does not create hours.
Reason 1: nobody has protected time
The new product is worked on with whatever is left after production issues, support escalations and the existing roadmap. There is never anything left, because the existing work expands to fill the week and always has a better claim on the next hour.
This is the most common reason by a wide margin. It is not a failure of discipline; urgent work genuinely is more urgent. But importance without protection loses every time it meets urgency, and it will keep losing until someone's time is ringfenced or the work goes somewhere the urgency cannot reach.
What breaking it looks like: a named person with genuinely protected days, defended by someone senior enough to say no on their behalf. Or moving the work outside the team entirely.
Reason 2: nobody owns it
Several people are in favour. Nobody is responsible. Requests get discussed and nothing is decided, because deciding is somebody else's job and nobody is sure whose.
You can identify this quickly: ask who would be accountable if the new product does not exist in six months. If the answer is a committee, a department or "all of us", it has no owner.
What breaking it looks like: one name, with the authority to decide scope and to say no. Not a steering group.
Reason 3: the boundary has never been drawn
The new product cannot start because nobody has decided where it ends and the existing system begins. Every conversation about starting turns into a conversation about the architecture of everything, which is genuinely hard, so it gets deferred.
This one hides well, because the discussions are substantive and feel like progress. Months pass in design conversations that never converge, because the question being asked is too large to answer.
What breaking it looks like: decide the interface rather than the architecture. What the new product may read, what it may write, what it must never do. That is a few hours of work and it unblocks everything behind it. We go through it in building a new product without pulling your team off.
Reason 4: the first slice is too big
The plan begins with something that takes three months to show anything. Nobody can commit three months, so it never begins, and the plan stays at the top of the roadmap as a permanent intention.
What breaking it looks like: define a first slice that answers the riskiest question and can be shown in two to four weeks. Not a prototype nobody will use, but the smallest real thing. If the riskiest question is whether customers want it, that slice might not involve much engineering at all.
Which one is yours
Ask the person who would build it what would have to happen for work to start on Monday.
- "I would need to not be on support" is reason 1.
- "Someone would have to decide what it includes" is reason 2.
- "We would have to work out how it connects" is reason 3.
- "We would need three months clear" is reason 4.
The answer is usually immediate and specific, because the people closest to the work know exactly what is in the way. They are rarely asked directly.
The uncomfortable version
Sometimes the reason is that the new product is not actually a priority, and the roadmap is expressing an aspiration rather than a plan. That is worth knowing. A product that has not started in three quarters, with no structural reason among the four above, is being voted on with time rather than with words, and the vote is no.
Killing it explicitly is better than leaving it at the top of the roadmap, where it makes everyone feel behind without producing anything.
Ali Boran Gazel