Business Before Backlog
Most roadmaps are a pile of features looking for a reason. The fix is to start from the product and the P&L, then build the engineering to match.
Hand me a roadmap and I can usually tell within five minutes whether the team is building in service of the business or just building. The tell is simple: can anyone in the room say, in one sentence, what business outcome each initiative moves? When the answer is a shrug, the backlog has quietly become the strategy. That is backwards.
Technology in service of the business
I think from a product and business point of view first, and everything derives down to technology and engineering in service of business development. Engineering is the most expensive way a company has of expressing its priorities, so those priorities had better be the business's, not the loudest engineer's and not the shiniest framework's.
What it changes
- Every initiative is tied to a number it is supposed to move. If we cannot name the number, we do not start.
- Work that does not move the business gets cut without ceremony, including work the team is fond of.
- Architecture is weighed in business terms: speed to revenue, cost to operate, risk to the thesis.
- Engineers understand the why, not just the what, so the thousand small decisions they make each week point the same direction.
It is the same instinct I bring to a turnaround, where the job is not clean architecture for its own sake but protecting and compounding the value of the asset. More on that here.
Start from the business and the backlog almost writes itself. Start from the backlog and you get a very busy team shipping things nobody asked the market about.