Note: This article was originally published on Medium — October 16, 2020.

When I was starting out in textbook publishing, we did financial simulation models for each new textbook. Each new book got its financial simulation alongside a templated marketing brief that was circulated around in a red folder so that everyone would sign it. The “red folder” process was how books got approved.

It was a deeply flawed process. Sure the bean counters would argue that it helped contain costs, but the unspoken way things actually got done were a few market realities:

1) Those financial simulations went out the window if the book was a priority of someone in management and

2) often those sales numbers were based on shifting sands. One large sale could double or triple a projection. One lost sale could cut them in half.

And, here’s the biggest reality: no single book is self contained. Although the financial simulation made it seem like it was, each textbook was just one edition. With each edition, you could grow or shrink. Invest more, and you were growing — not just for one edition but the edition after that. Invest less, and you could destroy a series — or, in general terms, an entire product line.

More than a decade ago, I stopped working in textbooks. Now, I work in software, but occasionally, I see the same thinking that went into textbook publishing show up in software, and I get a foreboding feeling of déjà vu.

Usually what happens is that someone from finance or someone with an accounting degree thinks that doing financial simulations will make things more efficient. And, I am empathetic to the drive — I have an MBA myself. But, because I have an MBA, I also know that financial simulations can dance to whatever the assumptions are, and if you are not careful (or trustworthy), you can hide a lot of bad things in the assumptions.

And, what’s more, because I’ve seen this happen, I know how it can fail pretty badly. As much as I encourage people to read Rich Mironov’s insanely smart Four Laws of Software Economics, some finance people don’t get it. They want the false security that a financial model gives them.

So, as I thought through how roadmapping should be done, I thought about a how to put it in relationship to financial planning and how to allocate across products in a portfolio. In doing this, I come up with 6 points:

• Allocate Software off a Fixed Base
• Understand the Constraints
• Make the Benefit Tangible
• The Product Roadmap Should Manifest the Strategy
• Manage Software like an Ongoing Concern
• Avoid the Accounting “Death Spiral”

Allocate Software off a Fixed Base

Creating a software roadmap is best practiced as an exercise in allocating off a fixed base. What does that mean? That means that the resources needed to make something are fixed — namely the time and attention of the product, engineering, and design people who are going to work on a project. In your planning, don’t think those are going to get more efficient or better in the next six-to-twelve months — even if you are growing.

But, what if we are hiring more? Over six-to-twelve months, there’s a good chance that will even out, but don’t plan on it. Hiring, training, and onboarding takes time and resources. Specifically, it will take the time and attention of the people who should be working on the product. So, adding more people only helps over a longer time horizon.

On that note: Everyone I have ever worked with knows Brook’s Law. Over 40 years ago, Fred Brooks noted that adding people to a late project just made it later. The underlying principle is what makes software allocation a fixed cost proposition: Yes, you can grow the team, but only over time and with consequence.

Another point: everyone I have ever worked with knows Brook’s Law, but no one thinks it applies to them. I call this the Bennett Corollary: “Simply knowing a ‘law’ makes you think it doesn’t apply to you, but it does.”

Knowing a popular “law” — like Brook’s Law or Conway’s Law — makes you think it doesn’t apply to you. But, it does apply to you.

Understand the Constraints

One of the dangers of the financial simulation mentality is it reduces everything to money, and money is a dangerous abstraction. Money can be moved easily from product to product, initiative to initiative. There’s a reason they call it “liquid.” Money looks the same if it is a PM, a designer, or an engineer. Money doesn’t need time to learn the tech stack or the tech debt.

With real projects, there are real people, and good managers understand people. They understand their strengths and weaknesses, likes and dislikes. You might want to do an entire front-end switch on a product, but if you have all back-end engineers and no designer, well, I wouldn’t recommend it.

An invaluable part of a software product leader’s role is understanding the constraints about the software and the team and being able to express those up to management. And, when necessary, figuring out how to limit them.

Moving people between projects often has a cost. New teams. New languages to learn. New interactions and designs. All of it needs to be taken into account because if managed properly, this can also be a benefit: Some people get tired of working on the same thing — the same product, the same tech stack. And although it might be advantageous in the short term to keep them with what they know, if they are craving something new, they can always find it at another company if you aren’t mindful.

Focus on a Tangible Benefit

Just as on the cost side, money abstracts the benefits. It’s like the South Park underpants gnomes all over again — there’s some step missing, but we know that revenue will just happen.

If you focus too much on the money, you lose track of the assumptions, and it’s often the assumption of the benefit that is the most important item when allocating for a roadmap. Assumptions can be anything from new customers, retained customers, greater spend from current customers, lower costs from new technology, and so forth. But even beyond that, you have to know exactly how the benefit is to be derived and to whom.

For product people who are used to writing user stories and acceptance criteria, this part of the roadmapping process is the “so that” writ large. Everyone who has ever written a user story knows that if you leave out the part that follows “so that” you really don’t understand what you are trying to do. Similarly, as you allocate during a roadmap, you have to be able to trace the work being done to the benefit to the company and the customer. And, that needs to be repeated so that everyone understands it. (And if they don’t believe it, they need to be able to question it.)

The Product Roadmap is Strategy Made Manifest

Any product leader will get asked about why something is on the roadmap or why something else isn’t. Often, we mumble something like “finite resources” or “investment priorities,” and try to shuffle on. And, generally when we are doing that, it means that the company doesn’t have a strong enough overarching strategy or (worse!) the company doesn’t have a strategy that everyone believes in.

Any product roadmap is rooted in the company strategy. The company strategy should outline what the company is to be, what customers the company is going to benefit, and how it is going to win in the marketplace. The Product Roadmap is a reflection of that.

But, a good strategy isn’t just the aspirations of the company, it also takes into account the company’s current situation — its current customers, its ongoing need to service them, the ability to grow, and — critically — the competitive situation.

With that in hand, the product leader shouldn’t need to circulate a red folder for approval because the other team members know and agree on what’s important. And, if it is asked why something isn’t on the roadmap, anyone — not just the product leader — should be able to answer the question.

Any product roadmap is rooted in the company strategy.

Manage Software like an Ongoing Concern

Products have lives. They grow and they stumble. At best, they become mini-businesses of their own, and there is opportunity to manage them as a business.

As you manage a business, you don’t run a single financial simulation and walk away; rather, you set up that business with a P&L statement that might show losses for months and years in the beginning, but will, eventually, become positive and thrive.

And, like a business, you have to maintain software because, and this can’t be stressed enough, software breaks all the time. Everything is breaking. Technology that was the new hot thing this year needs to be updated constantly. New versions and new vulnerabilities are always coming, so you have to manage that. One of the constraints off of that fixed base is inevitably maintenance, and there is always a forgotten cost of maintenance with software.

Avoid the Accounting “Death Spiral”

Each of the points above is designed to help you avoid the “death spiral” of managerial accounting.

As I remember it explained to me, the “death spiral” of managerial accounting is when you shut down a line of business because it’s margins aren’t attractive. But, in doing this, you have to reallocate the unallocated fixed costs to the remaining businesses, and realize that made their margins worse. So, you shut down another business. The same thing happens.

It sounds fanciful, but in practice, this happens until you are faced with reducing staff because you made growth miscalculations, misunderstood fixed costs as marginal costs, and lost what sight of the real benefits of what you were building. And, while you can always think to turn it around on paper, smart people start looking around and think, “wait, why am I here?” And, they will leave.

Conclusion

Answering those fundamental questions was what that “red folder” process was trying to solve: at its best, it was a coordination mechanism for the team to — quite literally — sign off on a folder. But, in practice, everyone knew it as a formality — a way to tell people, “well, you signed off on this,” and in practice, I watched editors stuff folders at quarter end to boost the sales projections and then really get to the business of making product once the approvals came in.

When I’ve seen allocation processes work well, it does because of the shared understanding of the extended team. Not just the product and the engineering teams, but the other teams as well — from sales to success and support, to product, to engineering, and marketing. That team functions as a team — understanding the business strategy and priorities.

And, when it works well from a product perspective, it’s because the product leader understands not only the business priorities, but also the fixed base and constraints — what can be done with the time and people in the organization — alongside with the future vision of what the product and the company should be.

Product Roadmap