Supplementing product roadmaps with project roadmap.
Understand when and how to create project roadmap to complement your product roadmap.
[Results from last survey: You want to read stories about high-perform PM.
Great! I’ve started reaching out to some awesome PM. But help me by nominating someone you think who’s story is deserving.
In outcome based product roadmaps, I detail a way to create a document that communicates vision, objective, key results, and initiatives. The initiatives are different products/features that you believe will help reach your key results and thus, objective. I describe how I only focus on dates for product features that have hard commitments. This prevents creating artificial dates or managing everything by dates. But say you have a product/feature that has a fixed launch date. How do you ensure the product will be completed on-time? Introducing the project roadmap, a planning document that more explicitly guides everyone from engineering, marketing, customer support, executives, etc., to ensure the release will meet project expectations.
What is a project roadmap?
I define a project roadmap as a document created from project planning. The document takes “the results of other planning processes and putting (sic) them into a consistent, coherent document”1 to understand tasks, ownership, risks, sequencing, and timing.
How project planning helps meet expectations?
There are two expectations when we build new products or features.
First, there’s the outcome expectations. We expect (or hypothesize) the product/feature will achieve a specific business outcome. There’s no guarantee this will occur. Through diligent product discovery, we can increase the probability of success.
Second, there are project expectations. We expect the product/feature will be built within a certain budget, time, and quality. There’s also no guarantee this will occur. Project management helps increase the likelihood that we meet project expectations.
With these two expectations, there’s four possible results.
Golden 👑: The product/feature meets or exceeds outcome expectation. Depending on how much the outcomes targets are exceeded, there is some “allowed” slack in missing project expectation (e.g., over time or budget). This slack is often “unspoken” or implied. Ultimately, business people care about outcome results and this highlights that people are willing to trade-off some project expectations in exchange for better outcomes.
It’s just okay 👌: The product/feature mostly meets outcome expectation, but doesn’t exceed. “It’s just okay”, better than if no product/feature was launched. However, you generally can’t go negative on project expectations.
Try again: The product/feature fails to meet or results in negative outcomes (e.g. unexpected decreases in key result). However, if the project expectation is mostly met or exceeded, there’s an opportunity to try again. Many new products/features will fall into this category, sometimes the hypothesis that initiated the product was just wrong. If you have money/time and met or exceeded project expectations, you are often given the opportunity to try again.
Fired 🔥: Things are bad, all around. They could be bad because:
Top left corner: The project exceeded project expectations, but the product/feature resulted in significant negative outcomes. I call this “drilling holes efficiently in all the wrong places”.
Bottom left corner: It’s just bad all around. Negative outcome and project. These are the easy ones that result in explicit firings for performance.
Bottom right: The positive outcomes don’t make up for the project execution issues. I call this “burning relationship bridges” because usually, the focus on meeting outcome expectations at all cost contributed to the project going over budget, over time, or poor quality.
As you can see, there are a lot of places where you could be 🔥. Learning about project planning and project management increases your chances of meeting or exceeding project expectations, which gives you a chance to “try again”.
How to conduct project planning and create a project roadmap
Determine if you need a project plan. Not all products/features need project planning. I recommend project plans for product/feature with hard commitment dates. In addition, here are other criteria to guide your decision.
Impact on failure: -> hard-commitment dates
Anticipated project duration: -> multi-month
# of roles involved -> 4+ roles (A role is defined as a function such as marketing, legal, public relationships, etc.)
# of people involved: -> 7+ individuals
The more of these check items you check off, the greater the benefit from conducting project planning and creating a project roadmap.
Start identifying tasks in a project roadmap template. I’m intentionally skipping the important step of documenting project goals because I assume you have a product roadmap with objectives and key results. As a result, the project roadmap is a complementary document used for breaking down in detail how a specific product/feature will help you achieve a key result. Rather than rehash your goals, reference your product roadmap to help people connect the dots.
Start with Project Roadmap Template2. Spend 30 minutes identifying possible tasks, deliverables, and owner. Fill in as much of the details as possible, especially areas outside of software development, by making educated guesses or put dates for people to react rather than leaving it blank.
Project planning is both independent and collaborative work. The best way I’ve found is via a combination of email, 15-30 minute kick-off meeting for project planning, independent work, and collective review.
Email: Should summarize why you need everyone’s help, what is project planning, what you’ve done with the project roadmap template, why you need others to help review and detail tasks, deliverables, and owners. Remember, the goal of project planning is to help meet project expectations (e.g., timing, resources, etc.), so you can use that to remind people.
Kick-off meeting: This isn’t to rehash the email, but to use the meeting as Q&A on why you’ve gathered a group of people together. Make sure you invite task owners you’ve assigned. And if they come and haven’t read the email, it’s okay. Tell them to just read your email now.
Independent work: Just as you spent time identifying tasks and prepping the Project Roadmap Template for the email, it’s now time for others to think, edit, and add. Remind people the goal for project planning isn’t to detail every task (e.g., “write copy”, “review copy”, “submit copy for legal review”). That’s often too much detail and no one wants to read it. A good approach is to ask what deliverable/decision needs to be done? So, in the above copy example, it might be “Legally approved copy on product packaging.” This allows people to identify tasks by working backwards from outcomes to then review the key tasks/steps necessary to highlight.
Collective review: Set a date and time for collective review. Make sure this is announced during your kick-off meeting.
With independent prep-work done, it’s now time to quickly bring people together. The goal isn’t to rehash every detail, but to identify dependencies to help sequence work. I’ve seen many of these “dependencies” discussions become long drawn out meetings that add little value with information highlighted as “dependent.” Don’t do that. Instead, focus on two types of dependencies in written form:
I’m doing something that will impact you
Statement -> “I am doing <XYZ> which I believe will force <you/other team> to do <ABC>. I must do <XYZ> because <reason>. We <shouldn’t/couldn’t> eliminate this dependency because <reason>.I need you to do something so I can do my job
Statement -> “I need <person on team> to do <XYZ> before I can do <ABC>. My work or decision can’t move forward until <XYZ> is complete because <reason>.”3
Finalize project roadmap by identifying “what must be true” milestones to hit launch date.
bottom up approach
top down, target/wish approach
deciding on a middle ground
Decide on a meeting cadence during the project. While the planning is complete, now comes the work of execution. I recommend organizing a 30 minute cross-team on a weekly basis, because you’re going to need to adjust your plans.
Principles for creating good project roadmaps
Don’t build in Google slides, ppt, or word.
In slides, you’ll spend too much time fiddling with boxes, arrows, and charts. In word, everything becomes long and verbose. Use Google Sheets/Excel or pick a specific project management tool if it’s available for use by EVERYONE on the project team. You don’t want to become the scribe just because you’re the only person who can edit the project roadmap.Start with end-dates, not starting dates.
Work backwards rather than from the start. Not only is it a different thinking process, which engages more actively thinking, it forces you to consider when tasks actually need to be completed. This reduces “sandbagging” for time by artificially putting a deadline for something when it isn’t necessary.Don’t track % completed for a task.
Many project roadmaps have percentage completion tracking per task. DON’T! Tracking this done mostly by manual entry with poor accuracy. People are bad at guessing percentages for completion of their own work.4 I can’t tell you how many times I’ve entered 70%, 80%, 90%, and then gone back to 70% because of some “new” thing uncovered. While the intention to use % is to create more certainty is positive, it doesn’t work in practice. Keep it simple by tracking if the task is done, @ risk, or dropped if the task is no longer necessary. Encourage candor in discussing risks, both large and small during weekly project meetings.Keep timelines weekly.
Don’t make project roadmaps that are daily. You don’t have the time to be a dedicated project manager for this level or micromanaging. People also hate it and it encourages granular information that’s not realistic. If your project has a hard commitment date and it’s less than 1 month, you need a different technique than project roadmap template.Invite individuals into standup for initiatives without project planning or project roadmaps.
Just because an initiative doesn’t have any project planning, doesn’t mean you can’t or shouldn’t involve people to collaborate. Invite them (typically marketing, legal, someone outside the product development team) to your standups, both as a listener but also so they can share what they’ll be doing to help move the initiative forward.Plan for people’s vacation and holidays.
It’s often forgotten, but when planning work, consider vacation and holidays. You’ll be surprised when projects are at risk from day one because the overall project timing assumes no vacation, holidays, or even people getting sick. Aim for 80% capacity, not 100%
There’s a saying that product management isn’t project management, but being a good product manager at a startup requires project management skills.
Templates:
Sources:
A Guide to Project Management Body of Knowledge (1996 Edition)
Adapted from Smartsheets