The Product Plan vs. the Project Plan

two orange goldfish in clear glass bowl

Great product managers ask questions — lots of them. But product managers need to answer questions too. And the more complex the work, the more questions abound. When I was working at another SaaS company in the HR space a few years ago, this became very clear.

As I worked through my vision for an upcoming product release, I presented the product plan to my colleagues. They were as excited as I was, but they had some questions. Actually, they had a lot of questions.

Do we have the right team to make this product launch happen? How are we going to market the new functionality? When do we need to update our support website? Should we train sales?

The volley of questions was understandable. Think about a major launch, such as bringing a big new product integration to market — especially one that involves well-known, third-party partners. It is a massive, cross-functional undertaking with seemingly infinite questions to be asked and answered.

At Aha!, we know that a solid plan is critical to getting that work done. We talk to hundreds of product managers each week and know we are not alone in this belief. But sometimes these conversations highlight a common confusion. Not everyone is clear on the type of plan that is needed.

Do you need a product plan or a project plan — or both? You might be surprised by how many product builders get caught up in the nuances of this question.

The differences are subtle. But they are also important. Let’s use that “big integration” example to explain. You would need a product plan to define the product requirements. But you would also need a project plan to account for all of the work and deliverables to get the entire company and partner ready to launch the new functionality and customer experience.

In the most basic terms, each plan answers a simple question:

  • The product plan answers the question, “what do we build?”
  • The project plan answers the question, “how do we deliver a complete and delightful new customer experience?”

The owners of the two plans are probably obvious — the product manager owns the product plan and the project manager owns the project plan. The two collaborate closely. So it is critical that each person knows and owns the details of their plan. (And yes, it’s true that the two people are often really just one person — the very busy product manager.)

Here is how to distinguish a product plan from a project plan:  

Purpose
The product plan lays out what is going to be delivered and hopefully ties it back to the key strategic product initiatives. It outlines the features that will deliver on that strategy.

The project plan lays out what needs to happen cross-functionally to deliver the new customer experience. It includes a series of activities that have a defined outcome and a fixed start and end date.  

Timeline
The general product plan may span a long time frame with work tied to big-picture goals and initiatives. The immediate plan in our integration example would tie to the new functionality that is going to be delivered. 

The project plan is directly tied to specific milestones and tasks related to the new product launch. In our integration example, these tasks could include updating support articles. A milestone might be the date by which the entire sales team should complete training.

Components
The product plan usually contains the following:

    • Product goals
    • Strategic initiatives
    • Key releases which will deliver on the goals
    • Major user stories or features
    • Requirements

The project plan usually contains the following:

    • Project goals and objectives
    • Resource allocation and budget
    • Important milestones 
    • Tasks for cross-functional teams
    • Partner responsibilities (if there are any)

Roadmaps
Product roadmaps show high-level strategic initiatives, key upcoming releases, and features. Sharing these roadmaps helps cross-functional teams understand the overall strategy, why certain features are being implemented, and what will need to be delivered to ensure the overall customer experience is considered.

Project roadmaps show the timeline of specific tasks and milestones required to support the overall customer experience. Sharing these roadmaps ensures the each team understands the timeline, their role in achieving it, and the importance of those milestones. This is especially helpful for the cross-functional teams.

Great product builders know that success is found in the details. That is why it is key to know the subtle, yet critical, differences between a product plan and a project plan. 

It is also important to recognize that these two plans may overlap. For example, you do not need a detailed project plan if there is nothing new to launch.

No matter what you are building, having a plan will keep you on track. It helps you anticipate the questions that the product team will ask and be able to rebound when problems pop up. Knowing the type of plan you need will help you lead your team to success.

How do you use product plans and project plans in your work?

About Ron and Aha!

Ron is a product guy. He is the Director of Product Management at Aha! - the world’s #1 product roadmap software. He previously founded and sold his own company and has been on the founding team of multiple venture-backed companies.

Sign up for a free trial of Aha! and see why 150,000 users at the world’s leading product and engineering teams trust Aha! to build brilliant product strategy and visual roadmaps.

We are rapidly growing and hiring!

  • Customer Success Managers (product manager experience required)
  • Product Marketing Managers
  • UX Designers
  • Rails Developers

Work from anywhere and be happy. Learn about our team — see current openings.

Comments

  1. vikas

    Great article and it would be great if some real examples are given. I mean showing 2 actual plans and what problems the missing/wrong details can cause.

    Reply
  2. Graham Libaert

    Good article and having been both a Project and Product manager in my career the distinctions are well made. I’d roll this up to Products being goal bounded and Projects being time and effort bounded but both should be seeking the end result which is a valuable change or problem solved. The other paradigm I can draw is the definition of a project within the Prince2 framework which runs along the lines of a temporary state and collection of resource & deliverables. i.e. a project is a temporary arrangement to reach a business goal whereas a product is generally a continuous lifecycle. I actually align our organisational projects to initiatives within Aha! as for me projects and initiatives are one and the same – something we need to do to get us another step closer to our business goals.

    Reply
  3. Christy

    I have been very impressed with Aha!’s features, functionality and user experience. I am having a hard time finding a SaaS solution I like as much on the Project management side of things. Any suggestions?

    Reply
    1. Jessica Groff

      Happy to hear you are enjoying Aha! Christy. As for your project management question, it all depends on what you are trying to accomplish. Shoot us an email at support@aha.io – our Customer Success team of former product managers will be happy to help you out.

  4. Helene

    I would really like to see a sample project plan to complement our product planning. I’ve been asked to come up with dates for interim deliverables and milestones (e.g., stakeholder roadmap approval, high level features/epics defined, user stories completed, drafts and final drafts for wireframes, style guides, etc.). I’m stuck in analysis paralysis.

    This is a new process for the business, there is limited “learned lessons” other than don’t wait until the last minute.

    Reply
    1. Keith Brown

      Thanks Helene. There are lots of great examples and sample plans on Roadmap.com, and if you have any specific questions please reach out to our team of former product managers at support@aha.io

Leave a Reply

Your email address will not be published. Required fields are marked *