October 29, 2020
A couple weeks ago I wrote a post to help Engineering leaders get ready for annual budget planning and avoid common mistakes. This is essentially a companion piece focused on the product / roadmap planning part.
I’ll start with a bit of pep talk, since I don’t know many Engineering leaders who relish the idea of trying to chart out a full year’s worth of roadmap. It’s tempting to assume that since the roadmap more directly belongs to Product Management, it’s “not my problem.” I can totally empathize, but two quick rebuttals:
Generating some excitement around what can be accomplished in the year to come is important both to your company and to your team. Yes, there’s tons of uncertainty involved in building software, and yes it’s true that by next fall everyone will have moved on to new ideas anyway. But – especially as the end-of-year roadmap relates to budget planning – this is the time to play to win, rather than play-to-not-lose, or not play at all.
Every now and then I meet an Engineering leader who can successfully run the playbook of “my team is built to be a high-performance delivery machine, I focus on that and then we can build whatever the business needs.” But usually this approach fails. Successful engineering executives almost always understand how to collaborate with the business and leverage their team’s unique skills for competitive advantage.
I’ll skip the part about “what a good roadmap and product plan looks like,” or how to create one. Instead, I’ll point you at two of the many great write ups that are already out there. This high-level framework from Jeff Gothelf is great, and in my opinion makes sense for most agile businesses. Apologies if you’re building rocket ships – but in that case you probably don’t need my advice anyway. For an awesome deep dive into the end-to-end process, check out The Secret to a Great Planning Process – Lessons from Airbnb and Eventbrite.
Personally, I use the following shorthand framework to think about the different layers of a good product roadmap:
Goals = What are we trying to accomplish? These can be quantitative (quadruple revenue!) or qualitative (build that rocket ship!), and can be fleshed out to varying degrees of detail.
Ideas = What can Product and Engineering do to accomplish those goals? What can we build, hopefully better than anyone else can?
Plan = How much time and what resources are required to execute those ideas? This is the part of the roadmap where you actually map out key deliverables over time.
With that framework in mind, there are a few lessons my co-founders and I have learned from a couple decades of practice, as well as a few years of close collaboration with many of our amazing customers at Jellyfish:
Lesson One: Goals need to be clear.
It may or may not be Engineering’s job to define the goals, but it is every executive’s responsibility (including Engineering) to make sure that the goals are well-understood.
Lesson Two: Ideas can come from anywhere, but are better with strategic input from Engineering leadership.
Don’t settle for just answering questions like “is this possible?” and “how much time and effort will it take?” The best Engineering leaders do more than just keep ideas grounded in reality (though that’s important too) – they know where their teams excel and what they can build better than anyone else can.
Lesson Three: Putting a Plan on paper is the hard part. But you have to do it anyway.
Over the years I’ve been through many frustrating planning efforts, sometimes as the one asking the questions and sometimes as the one expected to answer them. Are we estimating or committing? Do we all understand the inherent uncertainty here? How do we put ourselves in position to accomplish as much as possible, without spreading ourselves too thin or taking on too much risk? These are all tough questions, but Engineering leaders are expected to have answers.
Lesson Four: Remember the 80/20 rule.
The reason why we stopped doing Waterfall a long time ago is because we learned the hard way that trying to figure out every last detail in advance doesn’t work. 20% of the work should get you to an “80% accurate” plan. And 80% is probably as good as it’s going to get. Spend whatever time you have left getting buy-in and feedback from your team, so that you’ll be able to better manage to these plans once real life gets in the way.
Hopefully this gets you fired up to make this iteration of your product roadmap the best one yet. And just to repeat some advice from my last post, in an attempt to make this process that much easier: spend some time reviewing recent history, and bring data to the discussion. Whether you’re using an Engineering Management Platform like Jellyfish to give you a clear readout on all the work your team has done, or you’ve got it covered with spreadsheets and slides, the actual planning part of roadmap planning doesn’t need to be totally hypothetical. Understanding the work you’ve done recently, and how it compares to plans and roadmaps of the past, will go a long way to getting this one right.
