Day 30 as a PM: The Art and Science of Prioritization
How do you decide what NOT to build?
About us: Andrew (AM) and Chandrika (CM) met during their MBA program at MIT Sloan and connected over their passion for product, growth and paying forward the help they got transitioning into product management. AM currently works as a Product Manager at Moveworks and CM works as a Product Manager at DocuSign.
For this post, we have a guest editor, our friend Surya (SKT) who is a Senior Product Manager at Amazon, working on Amazon Fashion as part of the Retail Leadership Development Program.
A large part of the prioritization problem for Product Managers is not necessarily to decide what to build, but in some ways decide what NOT to build. There are usually a lot more projects that the team could work on, features the team could build than the actual bandwidth and resources available.
Here we share our experiences of the planning and prioritization processes across three organizations of different sizes and at different stages with very different product offerings.
Q1: How does the planning process work in your organization? 📈
AM: At Moveworks, we do a bottom-up planning process, in which Product Managers create initiatives or new product feature requirements and socialize with engineers to gain perspective but also identify any pure ENG projects that are needed to reduce tech debt, for example. The norm of “socializing a written memo” is vital during this stage to gain feedback from key stakeholders. Afterwards, the plan is sent back up to the co-founders and leadership team to create larger initiatives to instill alignment across all groups. In addition, they add a perspective of long-term product goals, validated against customer conversations. The bottoms-up process has been important in achieving complex, highly cross-functional initiatives that are needed to advance the company as we scale and grow quickly.
CM: At DocuSign, we go through an annual operational planning process (OPP). This is when the company leadership decides on the biggest priorities for the business for the next year. This is a bottom-up process where each team works on drafting up their plan for the upcoming year and then the leadership team takes all these individual team plans and comes up with organizational level priorities for the year. Apart from the annual OPP, in the product development organization we go through a quarterly planning process where we align with various stakeholders on what we will be working on for the next quarter. And at a team level, we go through bi-weekly sprint planning to continue sharing progress on the initiatives and the KTLO (keeping the lights on) work such as bugs, maintenance work, tech debt, necessary enhancements.
SKT: At Amazon, we use the “Working Backwards” approach in everything we do – starting with the customer and working backwards. There is a strong writing culture and teams write narratives for every strategy, project, initiative or plan working backwards from customer needs. For annual planning, every team puts together an Operating Plan which goes through two review cycles. This plan will outline the team's guiding principles, strategies for next few years, big ideas and projects. This gets reviewed and priorities are finalized for the upcoming year with business and financial goals for the team. My role also requires me to partner with various teams and get my org’s business requirements and projects on their operating plan. As a result, a large part of the planning for me is maintaining these relationships with my stakeholders, going through the intake process for these partner teams and making sure the project narrative documents are thoroughly reviewed and agreed upon.
Q2: How do you prioritize on a weekly/bi-weekly basis? 🗓️
AM: This is an on-going iterative process as we continue to scale the company. Product has to balance pushing long-term product goals (“small rocks”) and addressing short-term enhancements / bug fixes to keep customers happy (“grains of sand”). Also, Product has to consider engineering capacity (“glass jar”) on a weekly basis*. In other words, the glass jar can be packed to the rim with grains of sand, but no small rocks which are important to on-going product development. So engineers can be busy creating short-term enhancements and addressing bug fixes but miss on building new features. On the operations side, we use JIRA, Confluence, weekly ENG/PM and Customer Success/Product meetings to prioritize what’s important.
*Concept is abstracted from “The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change”, by Stephen Covey
CM: On a bi-weekly basis, we prioritize projects and tasks through backlog grooming. I typically go through backlog grooming with the Program Manager, the Engineering and the Design lead on my team. We use JIRA to manage our projects at a team level. Anyone in the product development org can have access to all project boards and can add tickets to the backlog, file bugs or enhancements. This bi-weekly grooming helps us cut through the clutter, prioritize any high priority (P1/P2) bugs and que up stories, enhancement tickets for the next sprint.
SKT: I have seen having a clear north star for every initiative, program, role or team goes a long way with any short-term or long-term prioritization. The initiatives I work on are long-term and strategic in nature which do not require me to do short-term prioritization. Although to deliver results, I often have to influence my stakeholders to prioritize business requirements on their roadmaps. Prioritizing these business needs are primarily based on why, how and if we should solve them, i.e. making trade-offs backed by data. So diving deep, earning trust and building consensus becomes critical. For tactical execution, I know only one way – working backwards from set goals and deadlines.
Q3: What ceremonies does your team have and how frequently? 🤝
AM: On a weekly basis, there are multiple types of meetings: PM sync (to socialize ideas and share learned insights), PM-ENG (happens on a per product basis), PM-Analytics (aggregate requests from Product to our Data team), and Customer Success-Product sync (address backlog and prioritize incoming customer of issues/requests). The number and types of meetings will evolve each half but the most important concept is “socialization” of ideas. It is important to keep everyone aligned in your area by having continuous conversations within certain groups.
CM: In my team (engineers, designers, tech writers working on the product area), we have daily standups, bi-weekly grooming and bi-weekly retrospective and sprint planning sessions.
The daily standups are 15 min check ins on what various team members worked on yesterday, what their priorities are for the day, if they have any blockers or any other area they need help with. For standups, we use a Kanban board that we put up on a large screen (or a zoom call in the WFH setting) and go through the tickets for each team member.
The bi-weekly retrospectives serve as a forum for everyone on the team to talk about what worked well for them, what could be done better and then taking action items for suggestions based on what could be done better. The retrospectives are quickly followed up by sprint planning sessions where the team goes over the tickets prioritized from the backlog grooming and sized with points. At the end of the sprint planning, we look at the number of points on each person’s plate and make sure it's an achievable number.
SKT: My team has 15-min stand-ups every alternate morning to discuss any dependencies and blockers. We review business metrics and projects on a weekly and monthly basis. Cadence for recurring connects for my work streams with stakeholders in other teams are either weekly or biweekly. Teams with dependencies also host weekly office hours and bi-weekly roundtables to share information, feedback, and best practices. It is also very common to put a meeting on anyone’s calendar for a quick connect outside of our schedule if needed.
Meetings for proposals, alignment, demo, or leadership updates will always have a written document. Teams typically spend the first 15-20 minutes of an hour long meeting to read and take notes in silence. Documents are written in a way that anyone without the background is able to understand them and is able to participate in discussions.
Q4: Could you share your prioritization framework? ⬆️
AM: There are quite a few frameworks out there (I’ve counted over 20 in preparation of this blog post). The truth is that you will need to assess each prioritization framework to find what is most suitable given your product, team dynamics, business model, and industry. Moveworks has its own unique process for that matter. When I researched frameworks, I started with Almanac, specifically Framework: 5 Prioritization Methods for Product Managers and then crafted a framework that made sense for my product and organization.
CM: There are various frameworks available for prioritization and you have to see what works best for you in various situations. The two frameworks I have used so far are -
Jobs to be done framework - This has been useful while trying to define the vision of a product from scratch or reimagining a feature. We have used this in workshops which are a series of brainstorming sessions with small groups. Brainstorming sessions can oftentimes be a lot of discussions, without any concrete outcomes at the end. This framework helps team members focus on outcome driven ideation.
Now, Next, Later - I have found this framework helpful while building the roadmap and giving visibility to external teams into how we are thinking about prioritizing various initiatives. It’s not always possible to have firm dates for each initiative and this framework allows you to share the roadmap, without getting into the specifics of monthly or quarterly dates and commitments.
SKT: Every team creates their custom framework depending on the product or part of the business team owns. Key to designing a prioritization framework is to have a mechanism which would make decision making easier and consistent. Most frameworks I have seen broadly follow three elements: intake, assessment, and decision. Initial process can simply be a list of all tasks or a formal intake process for any dependent team/customer to submit projects, initiatives, requests. Writing narratives with clear customer impact will definitely bring clarity, thoughtful discussions, and buy-ins from other teams. Next, assessments can be quick or thorough depending on the specific request. If an issue can be quickly resolved, it won’t make sense to push it to backlog. While new projects, initiatives, or enhancements may require thorough assessment and teams will have some rubric to score one over other. Scoring also differs by team but will cover customer impact, scope, business impact, estimation of efforts and investments etc. Teams can then prioritize initiatives and decide which ones go on the roadmap, backlog, or to send back with feedback.
If you found this valuable and want to support us, consider buying us a coffee!