Missing Tracks in our Roadmaps

Every company, with or without planning, runs two tracks with design, product, & engineering:

We often talk about "bias to ship"; but if you ship too much on the New Track; debt will increase exponentially.

If you solely focus on the debt track, it will add to the new track once we've found a reliable solution.

Things get worse when you sit down to define — What is new vs fixes? What's critical? — these definitions are blurred.

New creates debt which requires new-new stuff, and the cycle repeats.

We have no formalised process to break this spell. But our friends at agile are, as usual, onto something. I love stealing ideas, and this time I want to borrow — "Sprint Retrospective".

Where the teams gather to see what went well, what went wrong, what needs to change.

What if we extend this idea to full organisation, and officially add it to our roadmaps:

Every single time a user story/feature/request makes it through either new or debt track; we must run it through retrospective with all teams involved.

During this phase, we talk about things like:

• Track & document failures and lessons
• Success, the real reason why it worked
• Remove things that didn't work; document what didn't work and what (as a result) should change about company, idea, process

This can help us get rid of sunk-cost bias, which gets magnified with confirmation bias in a group. If we kept asking why, how many of our features & products will survive?

You are reading a post that I wrote a long time back—at least 5 years ago. Take it with a bag of salt.