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:
What is a work plan?
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).
What are the 3 steps of a work plan?
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!
1. Preparation
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:
- Create an initiative document
- Establish a user story or similar
- Verify how the idea fits the current product fundamentals and focus
- Choose the product metrics to address
- Perform research and early product discovery
- Identify the internal stakeholders
- Create a ticket in your product management software
- Plan a project kick-off meeting
Create an initiative document
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.
Establish a user story or similar
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].
Verify how the idea fits the current product fundamentals and focus
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!
Choose the product metrics to address
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.
Perform research and early product discovery
While it’s not always possible to get all the information you need, try to research the answers to the following questions:
- Was this solution tested in other areas of the product or by competitors or semi-competitors? For example, the “stories” feature worked out great on Instagram, but it was a disaster on Skype
- Is there a science paper that evaluated the idea in a controlled environment? For example, have scientists evaluated the impact of gamification on users’ behavior?
- Are you able to estimate the impact of the initiative on product metrics or are you performing a pure “guesstimation”?
- Which user personas will benefit from the update?
- What are the other ways to solve the same problem (this is just a sanity check step to see if you can come up with even a better idea)
Identify the internal stakeholders
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!
Create a ticket in your product management software (most likely Jira)
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.
Plan a project kick-off meeting
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.
2. Kick off
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:
- Product manager presenting their findings
- Discussion on those findings to make sure all meeting members are on the same page
- Planning out the high-level technical elements needed plus the timeline
- Agreeing on the potential risks and brainstorming solutions to mitigate those
- Seeking an MVP that can be implemented to test the product hypothesis as early as possible. This can mean different things, from a product discovery process where a mock of the update is presented to random people, to a full-blown working update with perhaps only a selected pool of intended functionalities
- Drawing expected timeline and check-in points
- Deciding on the next actions, expected delivery dates and parties responsible, i.e.,:
- Finalize the design – Mart – by the 14th of August
- Build the API – Donna – by end of August
- Prepare the tracking specification – Lucas – early August
- Clearing the necessary architecture changes with team Astro – Monica – ASAP
- Expected MVP release – Jane – second sprint of September
- Agreeing on the requirements. You can come up with a draft of the update’s requirements for the Jira ticket, but it’s best to run them with the stakeholders and include their input
- Final Q&A session to make sure everyone leaves the room at least in peace, if not optimistic and confident
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:
3. Evaluation
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:
- What happens next after the MVP is successful (or not)?
- What parts of a successful MVP should be improved first and foremost?
- Does the result of this initiative impact your roadmap going forward? How?
(i.e., when your experiment is done as a small side project, but is so successful it promises way better results than other roadmap items planned) - Can other parts of the product/company have any stake in this update? (i.e., If a new feature introduced in the mobile app is successful, perhaps the web browser version of the product should follow suit?)
- Are there any opportunities this update unlocks?
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!
Let’s make it easy for you: Template with an example
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!
Conclusion: “I love when a plan comes together”
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
The post How to create a work plan (examples and template) appeared first on LogRocket Blog.
from LogRocket Blog https://ift.tt/S1a3bpI
Gain $200 in a week
via Read more
