As a kid, I watched John “Hannibal” Smith from The A-Team often say, “I love when a plan comes together.” The four action heroes appeared to be able to create elaborate plans to solve their challenge of the week and execute them on the spot. Well, I never thought that as an adult product manager, I would be saying the same words.
In practice, my planning comes with way more hurdles than the TV action heroes faced. However, both the A-team and the product teams still need a work plan to achieve success!
Skip ahead:
Now, what is a work plan in product management, especially in an agile product management world? A work plan is a high-level document that helps you gather any initiative’s goals, timelines, risks, and other aspects for a future update. It helps you coordinate and monitor these details to make sure the work is going accordingly.
“Wait a minute!” – you may shout – “That sounds like project management!”
Well, I need to agree here. But, this work plan is not there for you to get timelines from your team and monitor them with a stopwatch.
No.
This is a communication tool. This is how you help yourself, your team members, and your stakeholders get a common understanding of upcoming challenges. When you work with your team on the plan, the right people get their chance to voice their concerns and ideas.
Also, in the product management world, it is not about setting everything in stone. It’s about being able to create clarity where possible (say, the problem you want to fix with the new initiative) and identify the moving elements (i.e., where will the development go once a certain aspect is A/B tested).
To understand a tool work plan for a product manager, let’s divide it into three stages:
Let’s take a look at them one by one!
Every change starts with an idea. However, the idea is simply not enough to convince anyone that it’s a good one. Thus, here comes the bulk of, often lonely, work of a product manager. In this stage, you should:
This is not your Jira ticket — not yet. This will be your work plan’s main document, where you will gather all the notes and key information needed. For now, this can be a private document, but be aware that you should be able to share it with anyone at any point.
It’s not your notepad, but a document collecting all aspects of the initiative. This document will later be super handy when crafting any other communication or updates connected to this initiative. Be sure to record the information you collect from the following points in this document.
While the book approach dictates that you start with a problem to solve, let’s face it, we usually work on solutions. However, a solution looking for a problem is most likely nothing more than a waste of time.
Thus, provide the right context for your initiative, the intended user group and the value the idea delivers. This will set a solid foundation for the rest of the work you are going to do. Thus, start by filling in this sentence:
As a [description of user], I want [functionality], so that [benefit].
Every product idea needs a good context. It has to fit the current product vision and strategy, and address current goals and OKRs. Without it, it will be a distraction from the current direction. Doesn’t mean the idea is bad, but timing is also important. You can still plan it! Duh! A well-crafted work plan can be a basis to define the next period OKRs!
If you verified the context, it’s time to link your solution to your product metrics and goals. It’s OK to have ideas that don’t address any metrics directly, but build product quality to increase long-term retention. However, it will be far harder to sell such work to your stakeholders.
No worries, you just need to adjust your pitching strategy. Maybe the idea is worth pursuing as a side project or hackathon initiative. Anyway, make sure your flagship initiatives at least plan to improve some of the key product metrics. It’s best to also include that in a written product change hypothesis.
While it’s not always possible to get all the information you need, try to research the answers to the following questions:
From developers, researchers, business analysts, and other product managers to high-level executives. This will help you down the road in making sure all the right parties are up to speed!
At this stage, you should be able to create your epic and copy-paste relevant information from the initiative’s document. It’s a formality at this stage, as you basically have everything to create an exceptional epic.
Once you did all that due diligence, it’s time to call in a meeting and get all the needed stakeholders in one room to get everyone on the same page. However, the main goal will be to create a more tangible product plan and identify the unknown risks and gaps that could prevent the idea from becoming a reality.
Now that all the product manager’s preparation work is completed, the kick-off meeting can be treated as sort of a handoff meeting. While the PM doesn’t move on to researching another idea right after this meeting, the responsibility of making it happen is essentially passed on to the development team. Or at least it should be like this.
If you are a product manager that also performs the project manager/development team leader duties, you will have to see all the work through until the end.
Anyway, regardless of your role, here are the elements you need to tackle during the kick-off meeting. Remember to record everything in the initiative document! The meeting here should consist of the following elements:
Now, as I mentioned earlier, what happens next depends on how your organization defines your product manager role. This might be a point after which you only check in with the team to share your opinion on the deliverables and collect status updates for your communication. However, you may also be the person who needs to change this into a full-on project management role, with full oversight, daily reports, and addressing any hurdles the team should face.
Sidenote: honestly, if you are closer to the second possibility, please consider changing employers. You won’t be growing as a product manager if project management takes the bulk of your job.
Assuming you work in an agile organization, the plan is now being realized and adjusted on the fly based on what will happen. The timeline can be pushed back for multiple reasons, but that’s OK.
Timely delivery is not about setting dates and deliverable outcomes in stone — it’s about using agile scrum to deliver the optimal value to the user and knowing how to do it transparently. It’s a neat compromise between chaotic-on-the-fly decision-making and a complex predefined structure project execution plan as presented by, i.e., PRINCE2 framework.
As you are, hopefully, an agile product manager, let’s look at the final stage of the plan:
This is a bit fuzzy part where you are meant to reflect on how the plan is coming together. While you will be making your decisions based on the MVP and following releases’ performance, it will be really impressive if you are already prepared for certain outcomes.
Try to answer the following questions:
Generally, sit down and speculate what you should do next. Don’t wait until the update is released to do that, as that will be a waste of time. If you find a successful result, you should pursue it immediately – every day you don’t build on your previous success is a day lost!
Hope you liked the framework above and would like to give it a go! If so, this article comes with both a work plan template and a filled-in example of a work plan for you to use.
I hope you will use it and it will be easier for you to deliver your next initiative to the kick-off meeting stage. Good luck!
I believe some of you were skeptical when you saw the beginnings of this article. A work plan for an agile product manager does seem to contradict the basic foundations of how the role should be executed.
I hope however that now you see that “agile” doesn’t mean “without a plan.” On the contrary, being agile is not about working without one — it’s about having a solid understanding and foundations to be able to adjust the plan on the go while maintaining the right vision and ability to still attain any pursued goal.
I hope this article will help you achieve those!
Dr. Bart Jaworski, Senior Product Manager at Stepstone, ex-Microsoft
Check out my product management resources: drbartpm.com
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Subhayu Ghosh discusses getting to the core of the customers’ problem instead of needing to develop the most innovative solution.
The waterfall methodology is a sequential project approach where each phase of a project must be completed before moving to the next.
Authentic leadership occurs when you’re genuine and act consistently with your principles and values, as well as with honesty and integrity.
Ajoy Krishnamoorthy, Chief Product Office at Cin7, discusses data-driven decision-making and his experience launching v1 products.
Learn more →
