Sachin Rekhi

One of the critical responsibilities of product managers is driving the overall execution of their product. Relentless execution will ultimately determine whether you'll be able to make your product vision a reality. Driving the execution of your product not only means doing whatever it takes to make your product win, but it also encompasses a set of core project management responsibilities. While many product managers are familiar with agile methodologies for managing a development team, I don't believe it provides a full view of how a product manager should be effectively managing their overall product process.

Today I wanted to provide a complete picture of a modern project management process for product managers. This covers a set of planning and project management activities that product managers should drive annually, quarterly, bi-weekly, and daily to effectively manage a product development process. It's rooted in the agile movement, with a deep recognition that customer needs and product requirements are ever-evolving and agility is absolutely paramount to enable you to swiftly change plans as soon as it's appropriate. At the same time, it recognizes that planning is absolutely necessary for enabling blue-sky thinking, thoughtful trade-offs of priorities, driving team alignment, and ultimately for enabling you to realize your product's long-term vision.

Let's walk through each planning activity, it's purpose, and benefits.

Annual Planning
The annual planning process is an important opportunity to take a step-back from the day-to-day execution of your product. It often starts with a re-assessment of the market you play in, taking the time to look at the industry you operate in, think through emerging or waning technology trends, and taking an updated pulse on your standing in the market. It's a good time to reflect on how well you are serving the needs of your customers and their overall satisfaction with your product offering.

It's also a good time to ensure that the vision you've established for your product is still appropriate. While a vision should have long-term stability and should change rather infrequently, there do come occasions when it makes sense to revise it. Treat the annual planning process as a check-in to ensure your vision is still serving you well.

While the output of an annual planning process can take multiple forms, I've found 5-year roadmap themes to be a great aid in facilitating the right level of discussion. I've typically seen this done as a single slide or single-page document. While the upcoming year will have a great degree of specificity, the outer years will likely only have a few sentences or bullets associated with their themes. This exercise facilitates long-term thinking into where you ultimately aspire to go, but also forces a very real trade-off discussion of whether the next year is going to be the year that you start to take on some of these longer-term objectives or not.

For example, we are currently experiencing an explosion in artificial intelligence and machine learning capabilities and for many consumer & B2B services, it's important to understand this technology trend. After careful consideration you might decide that your product is a perfect fit for it, the time is right, and you have the right team capabilities to put machine learning related themes into next year's roadmap. On the other hand you might decide that it's not well-suited for your product, you have far lower-hanging customer challenges that need to be addressed, and the next 2 years are not the time for you to pivot away from your existing roadmap. This is exactly the kind of discussion you want to facilitate with your team's stakeholders.

When it comes to costing & estimation, I find that roadmap themes are too high-level to be able to get granular costing of effort required. And since the actual implementation of features can be so far out, the effort required for granular costing is rarely worth it. Instead I find leveraging experienced product & engineering leads with a specific stated team size can usually provide t-shirt sizing (S, M, L) that can be used to have a high-level trade-off discussion of what can realistically fit in this upcoming year vs. not.

As an example, Facebook released a 10 year roadmap which mimics the later years of the 5-year roadmap themes that I mentioned in terms of just high-level bullets, though you'll want to have more detail in the 1st and 2nd years than shown here:



Quarterly OKRs
Quarterly OKRs provide an opportunity to concretely define the product outcomes you plan on achieving in the next three months. I like using OKRs, or objectives & key results, because of their specific focus on measurable outcomes. The objective defines what you want to accomplish, usually covering the product functionality or improvements you plan on shipping. And the key results defines the measurable product outcome you expect to achieve, including specific metric lifts you expect to see as a direct result of the product initiatives. These tend to be acquisition, engagement, or monetization metric lifts. But it could be anything worth measuring (increase in net promoter score, reduction in customer support tickets, increase in sales velocity, etc).

Taking the time to appropriately cost and estimate both the effort it will take to execute the desired product initiatives as well as appropriately forecast the metric lifts is a very important part of quarterly OKR planning. Here you do need enough specificity in the product initiatives including high-level scope in order for engineering to appropriately cost what they will be able to accomplish with a given set of resources assigned to it in the quarter. Similarly, product should develop as accurate of a forecast on the expected metric lift as they can. This is undoubtably a tough exercise, but putting a number out there is important. You should leverage as much past data on how your various initiatives have moved metrics in the past to come up with appropriate proxies. Even though you're estimate will likely be off, having an estimate and seeing how you did against it at the end of the quarter is the only way to tune your product intuition on what kinds of initiatives are in-fact metric-moving initiatives. Without going through this exercise on a quarterly basis, you'll never build this muscle.

Each quarter your product team should come up with 3-5 such OKRs and these should easily fit on a single slide or single-page document. Having any more than this is usually means a lack of focus for a product team. Of course this list will certainly not cover absolutely every product change you'll end up making in the quarter and that's fine, but this is an important prioritization exercise to rally the team behind the most important efforts as well as the priorities in terms of impact you're team is hoping to have on the product's success.

An equally important part of quarterly OKRs is the end-of-quarter post-mortem, when you go through the past quarters OKRs and score them each as either Green (met or exceeded the key results), Yellow (achieved ~70% of your stated key results), or Red (failed to meet the expected key results). As I mentioned, this is where the real learning happens to improve your team's ability to cost and forecast initiatives. Oftentimes you'll miss an initiative because it was delivered late. This serves as a great opportunity to discuss whether the issue was an inaccurate initial forecast or unforeseen challenges and what might you do in the future to improve your estimation. Similarly, you may fail to achieve the metric win you expected. And again, this is a great opportunity to discuss what could have been done differently for next time to try to find initiatives that will in-fact meet their metric expectations. The post-mortem is also a great opportunity to re-asses what you are hearing from customers and the market and ensure that your annual plan still makes sense in light of this. If not, you're encouraged to change your plan for the upcoming quarter to address the new market realities. There is nothing sacred about your annual plan, it was just a guidepost that you should feel free to move from as new market dynamics become apparent.

As an example, here is potential OKR for an online consumer website:

Objective: Redesign the homepage to focus on driving social actions
- Key Result: Increase social actions (likes, comments, shares) per session by 20%
- Key Result: Increase homepage weekly active users by 15%

Bi-Weekly Sprints
Bi-weekly sprints are the core mechanism by which engineering teams are run. The sprint planning meeting takes the form of your classic agile notion of picking off items from your overall product backlog and adding them to the upcoming sprint's backlog, with the engineer who is going to be responsible for the task directly costing the associated effort and committing to completing the tasks he takes on during the sprint planning process. This includes product features that are planned to be implemented, bugs that will be fixed, as well as any engineering tasks they are also taking on. It's helpful to include all R&D functions in this process, so design also commits to what design deliverables they are going to finish in the upcoming sprint, as well as product committing to various requirement and spec deliverables as well. The output of sprint planning is a single list of prioritized tasks for the upcoming sprint with associated costs & owners. The goal here is to not change the sprint tasks during the sprint in order to allow the team to focus on effectively completing those tasks and avoid randomization and instead only consider changes in the next sprint. The 2-week sprint timeframe is short enough that you can still be very agile but provide enough predictability and focus to engineering teams to make meaningful progress.

At the end of the sprint, the team holds a sprint review to show off the shippable product functionality completed in the sprint as well as a sprint retrospective to look back on how the team faired in sticking to the sprint timeline. A sprint schedule is a probability. And what you want to be doing is always improving your team's ability to accurately forecast to make the probability higher in the future.



Daily Scrum
It's helpful as the first thing in the morning each day to have a quick 15-minute standup with the full R&D team where each individual briefly discusses what they accomplished yesterday, what they are planning on accomplishing today, and if there is anything blocking them from meeting their sprint goals. This allow the team to assess how they are doing against their sprint goals, resolve any bottlenecks, and potentially move around team resources to address those bottlenecks if needed. The goal here is to avoid issues festering for days, resulting in the project getting delayed and instead have an opportunity to address it every 24 hours to keep the team running as efficiently as possible. This in-person live format works better than issues lingering in long unresolved email threads. This is typically run by a scrum master (usually an engineering lead or delegate on the team) who goes around to each team member and ensures each bottleneck is addressed either during or immediately after the standup.

I've started to see some teams turn this into a Slack/HipChat channel discussion instead of an in-person session. While I like the daily ritual of getting the whole team together in-person, the chat version does work. It's important though to make it a live session so issues can still be immediately addressed.

In addition to a daily scrum, it's also helpful to have a daily bug triage process which reviews new bugs, appropriately sets the bug's priority, and assigns the bug to the appropriate engineer. I also encourage you to establish bug SLAs (service level agreements) that define when a bug is expected to be fixed based on it's priority. For example, P0 bugs that are incredibly severe are reason to stop everything else and get the bug fixed immediately. P1 could have an SLA of fixed in production within a week. P2 could be fixed in production within a month. It's best if you can assign someone to go through this task for new bugs on a daily basis in case there are any new P0 bugs that need immediate attention. I've typically seen this done by either an engineering lead, a test lead, or product manager.

Project Management Tools
There are a variety of tools available which are typically used to streamline project management activities.

I've typically seen annual planning and quarterly OKRs published in a team wiki (like Confluence), in shared documents (like Google Docs), or shared slides (like Google Slides). Since each planning document is never more than a page each, it's pretty easy to keep the full history of past and present versions altogether.

Sprints are most often managed in a full project management tool. Any of the popular project management tools work well, like Atlassian JIRA, Asana, Trello, Wrike, or Basecamp. Some specifically have support for sprint planning and daily standups, enabling you to run your daily standup more efficiently with a scrum board that everyone can see, including Atlassian JIRA and Trello. Pick a tool that your team is familiar with and comfortable using as they'll ideally be in there frequently updating the status of tickets.



It's important to remember that there is nothing sacred about the specific intervals references here (annually, quarterly, bi-weekly, daily). You can easily customize these to meet the cadence of your product development cycle and industry dynamics. These cadences though have worked well for me across a variety of desktop, internet, and mobile applications I've built throughout my career.

I hope this provides an overview of a modern project management process for product managers. While it may look like a lot of project management overhead, the reality is that each of the planning tasks is fairly quick and the output of each planning activity is never more than a single page of roadmap themes, OKRs, prioritized tasks, etc. The overall planning process not only facilitates long-term thinking, course correction, and learning, but is absolutely essential for enabling your team to achieve it's ultimate product vision.