I’m struggling how to approach creating a roadmap for a product.
I believe in iteration based on user feedback, but my company wants me to create a year long roadmap.
How on earth can you know what the team should be working on in 12 months’ time?
Do I just make up some bullshit and then change it nearer the time?
Don’t list features and deliverables. What the roadmap should do is communicate your strategy. Show what problems you intend to solve in each quarter that connects to your company’s overall strategy. (Ie. Got a problem with churn at the corporate level? Great for one quarter have a team focus on improving engagement. Know some troubling flows or have a great measure of success? Include that as what you want to improve. Don’t know where your opportunities are? Put some discovery or research in the quarter before you intend to solve it.
Edit: one last note on this approach, it’s less likely to change than being waterfall and listing features you have no idea if you can build in the allotted time. It is, however, still likely to change the farther out you get. All it takes is one dramatic entrance from a new regulatory requirement, new global pandemic, new Google search algorithm, whatever flavor of pain you can imagine to completely alter your opinion on your biggest problem to solve. So don’t sweat it if future you have a better grip. All roadmaps change, but it’s so much easier to compare two problems and their relative impact then it is a specific feature to another.
@RichardsonEva, Well, yes and no. This is the kind of answer that sounds great on paper but doesn’t always work in real life.
I agree that this is the “right” way to do a roadmap and works really well for PMs, but in practice Sales and CS tend to get hammered if they can’t speak to actual solutions that are being built and this can cause tension with PM. An enterprise customer doesn’t want to hear “we’re focused on improving engagement” and asking a CSM to say that is ridiculous. You have to give internal teams something to work with.
I think it’s far more effective to communicate fidelity and likelihood of change. E.g., “here’s how this could look but because it’s three quarters out a lot could change.”
That’s actually where having a strong vision comes into play. What I’ve found works really well is working with a designer to mockup the ideal product to get people on board. When you have a list of features, people get attached and complain when they don’t get that specific thing. But when you spec out what could be, especially visually, they tend to be a lot more flexible.
This isn’t just for B2B, but also for B2C. We do 6m roadmaps + strategy, where we split the roadmap into incremental, big bets, delight. All of these will have some mid-high-fidelity designs of the solutions.
It is tough to get people excited just with strategy.
I have worked with enterprise customers for years and you’re right they usually ask for more. It’s your job to sell the approach and earn their trust by proving your strategy is aligned with their goals. There are ways of adding the right degree of fidelity for your audience that don’t set you up to be a liar or hurt your teams by excluding them from building the solution. This in the long term makes a greater impact on their loyalty then showing them constantly moving goal posts and hearing ‘why should I believe you this time, you told me 6 months ago this would be done by now’.
Right! Exactly. I think we’re largely saying the same thing.
I don’t think this is very sound advice. This might be fine at the executive level and for prospective customers, sure, but if you have anyone ask a question around “what does that really mean”, you’re screwed.
This is way too fluffy imo. You need more granular detail, at the very least down to the planned component level – and further, if your users aren’t giving you the feedback to derive just what to build, than your business should.
Lots of comments here seem to be assuming, perhaps rightfully, that your company just wants a list of features organized along a timeline, and are, in my opinion, too aggressively recommending finding a new job or going against the grain. But none of us know what the company actually wants.
I’d say you should determine specifics about they’re asking for, perhaps by being suggestive on what you’d like, so you can set expectations. Regardless of what they say, take what you believe in - iteration and feedback-driven development - and work it into the plan as actionable items.
If they just want a list of features, then give that to them - by listing out features defined by the problem they solve. “Q3 - Research, design, and implement a feature to address user’s feedback about x thing not working well.”
In my experience, company leadership won’t always talk like a PM, but they don’t necessarily think differently than a PM. See if there’s common ground, then act accordingly.
Fight for making a meaningful roadmap instead, e. g. a Now/Next/Later roadmap. If you lose the fight, you can either:
Understand your overarching business goals, come up with features that match them, do research and confirmation on what is important to your target audience, then layout the order based on priority.
Try figure out where the need comes from. Senior leadership who want to make sure people are busy? Sales people who are consistently asked by qualified leads what the plans for the product / what evidence of active product development you have before they commit to a multi-year license? The reasons can be many and most of them can change dramatically whether the company is a startup or a big corp, whether the product is a B2C tool or a complex B2B/Enterprise platform, etc.
You say you iterate based on user feedback which is great, but I’m sure you have a vision and you or your business have a strategy for your product. Vision, not precision, is what a roadmap should communicate. You can start from something that has a timeline à la now>next>later, and list problems you’d like to solve that match product & business strategy. Avoid matching features with arbitrary deadlines, you don’t need any of that stress. With the not so many info we have, this is where I’d start from.
First of all, you need to have a very clear strategic vision for you product. If you have a clear strategic vision, you shouldn’t have an issue coming up with 12 months of new features, hypotheses to test, etc.
That said, just because your roadmap goes out 12 months doesn’t mean it’s static; you should be re-evaluating periodically (at least quarterly)
I agree with @RobMartin’s now/next/later roadmap - we tie these things to quarters:
Approach the exercise as less of a “we are absolutely doing this” and more like “heres what we think we’ll be doing in 12 months based on the information we have today. As we go along we will learn new things that will change this plan, and we’ll update and adapt as we go.”
I always drive home the idea that the plan is useless, but the act of planning is invaluable. You’ll Ultimately be able to adjust quick and make better decisions if you already know your tradeoffs and impacts because you have a baseline to push against.
Keep in mind that responding to user feedback and long term planning are not contradictory goals - they are complimentary as they each serve a different purpose.
I think about it like I need to get across this ravine. Following the locals who know this ravine intimately are like the short term iterative planning. Knowing why you want to cross the ravine in the first place is the long term strategic planning.
Sometimes in the midst of crossing the ravine, you realize it’s not going to get where you need to go, so you pivot and try a new direction.
You only fail here when strict adherence to the long term plan means you don’t actually achieve the outcomes you need to.
I came across an article on how to do this. You need to communicate your strategy not your list of features. The article concludes with some examples of how to have those conversations with your stakeholders to get them onboard with this.
@DonovanOkang, I like the idea. You’re still going to need to include some features in the roadmap but adding strategy categories helps.
For example, in my 2022 roadmap Q4 I have an item called “workflow automation”. It’s not a feature, but it’s that I’m reserving capacity during that quarter to implement SOMETHING that will help automate the work my stakeholders do. I want to look at their process and automate some element to help speed up the close rate of their work and reduce time on task. Those are my 2 big KPIs that I want to show improvement on after doing this work.
As to WHAT I’m going to have the dev team build, I don’t really know for sure. I have a few ideas of areas we can hit, but I’m going to do some research on where we can get the best bang for the buck and what some pain points are from our frontline teams I support.
But the execs know that my “automation” strategy item fits into an OKR and they know we’re working to deliver value based on the KPIs I expect to deliver improvement on, and I don’t have to communicate extremely specific stuff basically a full year in advance.
Thoughts?
@RobMartin, I love OKRs for representing strategy, and sure if you are clear about how you are measuring success with your workflow automation and you focus on the goals rather than how you are necessarily going to achieve it, it seems all good. I think for features prefer to present them as “bets”. Your strategy is going to be around increasing engagement, revenue, acquiring strategic customers, beating competitors etc., and you should measure your success on how well you do at those things, not how many features you deliver. When you are looking at what to build to execute your strategy then you might indicate a new feature, justify in terms of the strategic objectives by what you know and be candid about your unknown. Stake it as a bet, even be upfront about the odds of success. I find this way of talking avoids the sunk cost fallacy. Also make it clear to sales and marketing that you need to learn enough to know when a bet is going to turn into a commitment. This is hard because management wants commitments up front, but it’s important so you don’t end up committed to something you can’t do, or as I find more common, you were wrong about and shouldn’t have done in the first place.
Have a read from Gibson Biddle. He compares quarterly output driven roadmap and outcome-driven Now, Next, Consider roadmaps
We do agile development and so there’s that struggle of sprints vs yearly roadmaps.
From my experience, I’ve tried to focus on a few quarterly bigger bucket projects. These are things that would generally take a few developers multiple sprints to do. But this would only really take up no more than 50% of the team’s capacity and the remainder I’ll often add “general” areas to the roadmap since we want to include items from those categories in the quarter.
But executive management doesn’t really line up with modern scrum development since scrum doesn’t line up with yearly roadmaps.
Be honest with your leadership on this one. If you have a roadmap that goes out past about six months, one of two things are true.
The roadmap is simply a prototype of the business’s strategy for the next several months. It changes constantly, and it doesn’t represent features, it represents business problems you intend to solve.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.