Rich Mironov reposted his great article, Magical Thinking and the Zero-Sum Roadmap, about the physics of roadmaps yesterday at the same time I posted my closely-related tidbit about delivering late being better than delivering on time but with low quality. Not a surprising coincidence, since getting product out there is something that occupies our minds tremendously. Rich summarizes his key point as Mironov’s Roadmap Theorem #1: “You can’t put something new into the current development plan without taking out something of equal or larger size.” And that’s a law of physics. Just because the software you write doesn’t need to obey the laws of physics doesn’t mean that the laws of physics don’t apply to its creation.
Predicting the Future – Another Name For a Roadmap
We all love roadmaps, at least our bosses do. They want to know what’s going to happen in the future, and usually they also want to know how much of you’re going to sell, and how each individual feature is going to pay for itself. If you think back to my “Radically Different Manifesto For Agile” post of two weeks ago, you’ll recall my first thesis was “It’s fundamentally better to not try to predict the future. Do your best to predict only as little of the future as you can get away with.” The other points in the post align with that, all based on the ultimate point – predicting the future in detail is impossible. This is a statement we all agree with, right?
Of course, you can predict some big things, what Daniel Burrus in Flash Foresight
The Creative Act
So, we know that the details of the future are impossible to predict. But that’s compounded, at least in the software world, by the fact that software doesn’t obey the laws of physics. Another way to say this, as Kurt Leafstrand did in his Medium article Don’t Build, Compose, is that in a software startup, “You’re writing a novel, not constructing a bridge.” Or, not to put too fine a point on it, creating software is not engineering in the same way building a bridge is.
Software is a creative endeavor, more like writing a novel. I talked about this last week in Product Management and Fear. There is no right way to get to the goal, for every new feature in your product you’re starting with a blank page, and you’re likely to go down a lot of rat holes before getting to a form that’s delightful and delivers value. In the article Leafstrand says engineers often need to “tweak the storyline a bit.” I’d go farther – “tweaking” doesn’t quite capture it – I’ve heard authors describe needing five completely different drafts of a novel – different tense, different voice, different characters – before they find an approach that works. As product people, our fantasy is that we’re only a few tweaks away from success, but sometimes we need to shift gears completely in order to make progress. (Hell, every paragraph of this blog post has gone through at least three edits!)
We are therefore put into a difficult place – we want the ability to predict the future (that is, a roadmap), we have constant pressure to add to the roadmap without changing the dates, and we’re writing a novel, in practical terms.
Roadmaps Become Perceived As Reality
And then, unfortunately, the roadmap usually transitions, in peoples’ heads, into reality. Our best guess at predicting the future, which was at best always optimistic, becomes the expectation outside of the product team. In the meantime, inside the product team reality is asserting itself and we are doing our best to deliver the most value we can using agile to prioritize the most important features first, and striving to avoid what I wrote about yesterday (delivering something “on time” but crappy) and instead deliver something incredibly useful, engaging, and that people will buy. On whatever schedule that takes (within reason).
There, in a nutshell, is why product management is not just a fun job, but a tough one. If you can dance that dance, and not get fired, and still get software out, and love doing it, you can be a product manager.