September 15, 2021

Lesson 8: Roadmaps

Lesson 8: Roadmaps

When I was somewhat younger during the ancient period called pre-iPhonean, our family went on a vacation where we rented a Lincoln Town Car. Back then Hertz proudly offered a miraculous invention known as NeverLost. It was new innovative tech, and as far as GPS goes by today’s standards…

…it sucked.

You had to plan your entire fiasco of a trip around the whimsical nature of cloud formations because any amount of overcast would entirely block the GPS signal.

“I see a tiny stratus cloud up there,” my dad would say as the Neverlost flickered in and out of connectivity. “Welp, we’re lost.”

We spent much of our vacation pulled over on the side of the road, waiting for connectivity. The fact that it was called Neverlost was a joke because you spent most of the time being lost. Perhaps “AlwaysLost” would have been a more accurate name…

…but admittedly it would have been terrible PR…

…like the poor Samsung marketer who has to convince people their phone isn’t going to catch on fire…

…The Samsung Neverfire.

As for the Neverlost, even with its less-than-reliable GPS signal, at that moment in the early timeline of GPS history, Neverlost was one of the coolest inventions we had ever seen…

…and as a bonus, it didn’t catch on fire. 🔥🔥🔥

My father, on the other hand, glowed like a hot ember as he marveled at the modern wonders of new technology. About every 10 minutes he would look at the paperback atlas and say, “I don’t need you”…

…That poor paperback Atlas is still attending therapy sessions to deal with abandonment issues.

The Hertz Neverlost was my first real experience with a roadmap in that it provided directions and told us where to go.

I mean, that’s what you’d think a roadmap is supposed to do, right?…

…which brings us to the Product Roadmap.

Like the Neverlost, the product roadmap is supposed to provide clarity and direction. It is supposed to tell you where to go. Yet most of the time you are dealing with conditions out of your control like those mother f***ing stratus clouds, not to mention other surprises along the way:

  • potholes => bugs
  • kids screaming from the backseat => client demands
  • road construction detours => new sales contracts
  • the occasional herd of cattle blocking the road => legal compliance
  • frivolous site seeing adventures => executive whims

And regardless of the obvious absurdity of it all, every leader in your organization will pretend like none of this happens and expect you to produce a product roadmap that has the equivalent accuracy and technological prowess of today’s Google Maps.

“Tell me exactly where this product is going, when we will get there, and where we can get food along the way,” your CEO will say…

…Uh oh.

In this lesson we are going to discuss why the typical roadmap, even though you have to have one, is a stupid idea and the only thing it does is pave a road to failure…

…it ain’t easy.

Seriously, if making software was as easy as making a Gantt chart of uninterrupted step-by-step procedures to a final delivery date, then we would print it out like the old-school Mapquest instructions:

“Start out going North on UX street. Merge onto Agile Ceremony HWY. Turn right at DEV BLVD. Exit the QA ramp. End at Your Delivery Destination.”

Unfortunately, how many times have we tried to follow the printed out directions but we end up abandoned on some desolate dirt road with a flat tire and no gas…

…Leaving you with the only viable solution of hitchhiking to another initiative…

…only to realize you hitchhiked with a psychotic ax murderer…

…and he’s going to murder your career...

…it ain’t easy.

To be clear, when I rant against the roadmap, I’m speaking out against the Gantt-chart inspired roadmaps. You know the kind where each phase is broken into step-by-step procedures. These are usually the unintended consequence of an uninformed demand by some unknowing executive who thinks product creation is unequivocally a factory assembly line of uninterrupted linear process…

…how un-true.

Instead of clear Mapquest instructions, how many times have you followed this 10 step roadmap strategy?

Step 1: Ideation
Step 2: Design
Step 3: Start Developing Prematurely
Step 4: $#!+, the design doesn’t make sense
Step 5: Remorse that Phase 2 is over
Step 6: Develop a senseless product anyway
Step 7: Uh oh. We don’t think there’s a market for this
Step 8: We’ve invested too much at this point. Just get it done
Step 9: There’s never any time for QA
Step 10: Deliver an over-engineered piece of garbage nobody wants

This is the status quo. Not the exception. And it is always the PMs fault…

…It ain’t easy.

Once you realize that a procedural roadmap is just a delusional false sense of security that never works out, you’ll kick it to the curb.

“Get out of my car!” you’ll yell at your roadmap. “Where we’re going we don’t need roads.”

#nameThatMovie

The overly simplistic answer is that innovative product creation isn’t a sequence, it’s a collaboration. You are in the business of exploring and creating things that have never been done before. And there is no roadmap for unexplored territory…

…just ask Ferdinand Magellan, who undoubtedly was asked by his boss for a map of his adventure.

“My job is to create the map, you moron,” Ferdinand thought to himself.

Under duress, however, Ferdinand was forced by the moron to chart out some bogus coordinates for the sake of an upcoming leadership meeting. Then, after sending it to his boss in whatever the 16th century equivalent was for Power Point (maybe Charter Point), he privately wondered how the future of his mission could have any success under such idiotic leadership. He set sail anyway, knowing good and well that his forcibly created roadmap was useless.

Do you relate to this (probably true) story of Magellan, being forced to create a roadmap for which you know it has zero chance of delivery as written?

Why do we do this to ourselves?

More importantly, in a business world where overly detailed roadmaps are the expected status quo, what do we do?…

…Especially when we know it will only lead us to guaranteed failure and misery…

…and when we know it will only lead us to sink further into the dark recesses of mental insanity…

…and when we know it will only lead to us to a state of unexplainable psychosis where we paint our face like a clown and start wearing purple zoot suites…

…#weAreTheJoker.

Again I ask. So what do we do?

The first thing you do is make a version of a f***ing roadmap. Don’t fight it too hard. You’re not some righteous revolutionary anti-roadmap crusader trying to overthrow decades of institutionalized standard operating procedures…

…keep your rebellion in your heart.

The lesson here is that the one big thing you can do is base your roadmap on key outcomes rather than a list of engineering projects. So instead of “Build Feature X”, it’s better to say “increase product adoption by X” … or something like that. When you base your roadmap on outcomes, it invites the necessary collaboration, teamwork, and creativity to solve important business problems that actually push your product forward…

…you’ll rally the team around solving problems instead of asking people to mindlessly complete tasks.

The lesson here is to start by turning your roadmap into outcomes. It will open up collaborative dialogue on the best way to get there, which will significantly increase your chances of not going crazy.

This way, when a tiny cirrus cloud completely scrambles your Neverlost, which is guaranteed to happen, you can rally the troops to find a creative and innovative path to your destination…

…which sometimes might even mean opening up that old paperback atlas…

…and no, this is not a sponsored blog post for Rand McNalley…

…although if they want to give me money…

…I will take it…

…balls in your court, Rand.