Roadmaps are interesting artifacts, because they are used for so many things. Like the words “love” or “remarkable”, roadmap means different things to different people in different contexts. I love you. I also love Tim Tams.
There are multiple clear valuable activities that happen with, or even because of, a roadmap. Driving focus for an organization, getting clarity around which problems you will (and won’t!) solve, and for whom you will solve those problems. For this article, let’s unpack one other use – managing expectations around the timing of what your product is and will become.
A roadmap is not a schedule or a release plan
Have you ever run into someone who treats product and project managers as interchangeable people? Those folks don’t appreciate the difference, and it’s always a great opportunity to spread some education. One simple – perhaps simplistic – way to demonstrate the difference is that a product manager figures out what to do and when (roughly), where a project manager makes sure the team can meet those delivery expectations. This isn’t so much a Venn diagram as a murky and ill-defined border of responsibility. When a product manager shares her roadmap, which identifies areas of investment, laid out against the calendar, it looks like “a release plan.”
The more the roadmap looks like a release plan, the less valuable it is as a roadmap, and the more it starts to perform like a project plan full of dependencies and timing constraints. So maybe the reason people get confused about the difference between product and project managers is that they see us product managers acting too much like project managers.
Yes, you have to manage expectations of internal stakeholders, partners and customers – which includes “when.” If you manage those expectations by saying “here is precisely what feature we will deliver on date X,” you do two things. First, you distill a risk out of thin air – that you will slip past date X, or incompletely deliver the specific feature you’ve promised. Second, you paint yourself into a corner – what if sometime between now and date X, you decide that what you really need to build is a different feature; or you need to solve a different problem; or maybe pause new-feature development, to improve the stability and reliability of your platform? Your hands are somewhat tied. You are locked in. Choose your own metaphor.
The old saw about the iron triangle comes to mind – you can manipulate quality, scope, and schedule; you can only commit to two of the three. One of the variables must be independent. Project managers understand this, and learning how to manage the expectations and tradeoffs around this is part of project management 101. Now add back in the variable of “we want to build a different feature instead” – and you are outside the charter of project management.
The key (or secret, or “only effective way I’ve found so far”) to managing this is to control expectations at a higher level of abstraction. A great way to do this is to talk about the problems on which you are going to focus during a given timeframe. This is not committing to build a specific feature; this is committing to address a specific problem. This is the essence of a thematic roadmap.
There’s a reason why this is good – it isn’t just legalese or dodging a commitment. What your customers (should) care about is solving their problems. What they should not be dictating is the specific tools they want, with which they hope to solve their problems. In theory, as a team building solutions for multiple customers, you will have deeper, market level insights into the problems; you will have more expertise in the technology of solving them; you are skilled in the craft of solving the problem. As a company, you are better suited to figuring out the appropriate mechanism for solving the problem.
The expectations you should manage are two-fold. First, help your customers (and partners and stakeholders) shift their focus from (a) the specific feature they believe will address a specific manifestation of their problem to (b) acknowledging the value of their problem and how they would define success at solving it. Second, help your customers understand that you will invest (some proportion of) your efforts in a given time period, towards solving each problem.
There are many resources on building thematic roadmaps – hopefully this article unpacks a bit of the rationale for why thematic roadmaps are important.
Now, next, and not yet; the dynamics of roadmapping
There’s another dynamic of roadmap development – deciding what to do first. And there are many exercises you can do to work through achieving agreement about which problems will be solved first (for customers) and which problems can wait.
Here’s a simple technique which works very well. Given a set of problems worth solving (problem A for customer X, problem B…), have your team reach consensus in putting each problem in one of three buckets.
- Now. This is the activity of the current release. Classifying something as “now” means it is what the team is working on “right now.” For some conversations and teams, it could mean this month for other teams and decisions it may mean this year.
- Next. Everything that can’t wait, but isn’t needed right now goes here. At the start of your elicitation exercise, this bucket is typically underpopulated.
- Not Yet. These are items that can wait. This is often an indicator of things that are not as valuable, but it can be something incredibly valuable but less urgent. Your team will identify some items in this bucket.
What classically happens is that there is too much stuff in the “now” bucket – not all of it can be done now. So switch your elicitation exercise to be one of determining which of the now items can reasonably be delivered next instead and move it into the next bucket. Repeat until your now bucket only holds what the team believes it can accomplish.
Now you have the ingredients for a thematic roadmap.
You also have the opportunity to change specifically what you will provide, as a solution to the selected problems, as you get smarter about how best to solve the problems.