Why your product roadmap is failing - Part 2

Using Sequencing to get to the perfect roadmap

In the last post, we briefly introduced the idea that your product roadmapping exercise might be falling short because it’s likely incomplete if it’s missing two crucial phases. We then looked at the first phase - estimations - and a simple framework that you can use to gather estimates for your projects. In this post, we look at the second phase - sequencing - that will set your roadmap up for a much more predictable delivery.

SEQUENCING

Sequencing is just what it sounds like - the process of planning the order in which projects will be executed.

You might be wondering why this is important for a product owner to know, or drive - that’s the job of a project manager or engineering manager right? Well, technically yes, and they will most likely be doing that all through the quarter and changing this original sequence. But I suggest that as the product owner, you do one round of sequence planning yourself with your engineering manager, or whoever is responsible to drive delivery in your organization.

This is primarily for three reasons:

First, before engineering takes over, you as the product owner need to ensure the required product specs and designs are ready, which itself might take weeks, depending on the complexity of the project. So, you need to know the order in which your specs are written.

Second, you want to make sure that your high priority projects (remember marking them earlier?) are definitely picked up and released in due time in the quarter. It’s worth noting that this first sequence that you come up with might not be followed or is heavily revised as the quarter plays out, but this exercise is a great way to align with your delivery manager on your “non-negotiables”, so that they know what to prioritize through the quarter during execution.

And third, the sequence leaves you with an estimate of each project’s release date, which is great visibility for your product marketing, sales, and customer success teams to plan their activities around.

Remember, creating visibility across the organization is one of your primary jobs as a product manager.

Here are a few guidelines to keep in mind while sequencing your projects:

  1. While from a goals or roadmap perspective, a quarter is a reasonable time-frame, it’s relatively harder to plan engineering delivery accurately for 12 weeks. If you’re a lean team, I suggest planning engineering delivery in 6 week periods, or simply put, two halves of a quarter. For each of the projects, mark if you want it to be released in the “first half”, or “second half” of the quarter.

  2. For the first half - front-load all your high priority projects (I like calling them “star projects”) to make sure they’re picked up asap. Additionally, try taking up all medium priority but large effort projects (based on your estimates) in the first half too, to give them ample time to be delivered. I also recommend front-loading high impact projects, or projects that you think will take time to show their intended effect after release. Everything else goes into the second half. Note that this process is much harder than it sounds, and it is where you wield one of your superpowers as a PM - ruthless prioritization. 

  3. Use the estimations that you had derived with your engineering team to tentatively plot in which week each project can be released and work backwards. Slot in the product spec’ing and design effort right before that, to know when you need to be ready with your specs and mocks. In my experience, spec’ing and design collectively doesn’t usually exceed four weeks of effort (again, single person working on it) for 90% of the projects, unless it’s a super elaborate project.

  4. I know it’s expected for PMs to be multitasking, but try not to plan spec-work for more than 1 project for a single PM in a given week, unless it’s really small effort. Writing specs takes up considerable mind space if done right, and should not be rushed. Also, keep in mind that PMs are also quite involved during the engineering phase of a project, especially towards the end, so that will take up a lot of their time as well. This is where the second PM superpower kicks in - multitasking.

  5. In your release sequence, don’t forget to plan for Beta cycles, internal “dogfooding” sessions, review cycles, and the actual time to take the feature from QA sign-off to production.

  6. Finally, as the product owner, hold your entire team accountable for the delivery timelines - including the PMs, designers, and engineering teams. Granted that the actual effort estimate of a project is best done when the specs and designs are ready, but they shouldn’t be massively deviated from the original estimates.

As a product owner, you are responsible to bring your entire team together, align them towards the product vision, and coordinate their march towards realizing that vision. You also set certain expectations with your company’s leadership, and you are judged on how well you deliver them. With proper planning, you de-risk the delivery of your quarter’s roadmap and can instead start your quarter feeling assured that you have all the resources you will need to make the quarter a success and deliver your commitments.