This month, I am in the middle of my 7th semester-planning session at Microsoft. As a team, we continue to refine the art with each iteration. Based on the learning, here's a summary of what enables an effective planning exercise.

Define OKRs that ladder up to your org

Identify the top-level objectives that the org plans to meet for the planning window. Typically organizations set objectives around the following themes, not in a specific order:

acquisition (new users, customers, etc.)
engagement/usage
revenue
customer/user satisfaction
technical fundamentals (performance, throughput, reliability, tech debt, etc.)
cost (support cases, operations, overhead, etc.)

Understand how your product impacts one or more of these objectives. If your organization has top-level OKRs (objectives and key results), your product OKRs should ladder up to at least one of these objectives. For example, say you own the sign-up experience for a nutrition app product; then your OKRs would map to the acquisition OKR for the nutrition app. And in that case, your OKR would revolve around reducing the friction of the onboarding experience for the target customers.

Starting the planning by defining OKRs ensures you are aligned with the top-level outcomes from the get-go. It also makes getting a sign-off from your stakeholders easier by having a clear set of success criteria.

Prioritize outcomes, not features

You are planning for outcomes, not a set of features. Now that you have a set of granular vital results, you can work with your team, including engineering, design, research, and data scientist, to evaluate which KRs will make the most impact on the outcomes you are after. KR prioritization isn't always apple-to-apple, but it's more objective than prioritizing features. And once prioritized the key results, your feature planning becomes that much more objective and aligned with the top outcomes.

Drive an inclusive ideation process

Planning is inherently an inclusive process. The designer likely knows more about how to reduce drop-offs than you. The engineer knows more about designing a secure OAuth flow, and the support team is closer to the sign-up-related support cases. Take a diverse perspective on the problems and solutions that map to the KRs you defined earlier. Inclusivity also fosters meaningful involvement and commitment from the team that will be building the product features.

Identify mutual dependencies. You might need help from the security and auth team for your sign-up product. Ensure you proactively identify and communicate the asks from your partner teams. Conversely, ensure you are prioritizing the right partner asks that impact their own objectives. Use the OKRs to prioritize partner asks when possible.

Build an actionable backlog

Your backlog needs to be self-served and intuitive. Do the epics and user stories include enough context so engineering can size the backlog items? What's required to identify and mitigate risks sooner? Does the designer clearly understand the problem a specific UX will solve? And last but not least, what KR will each of the feature impact, and how will you track it? In general, build a backlog with crisp user stories and acceptance criteria for each of the features. Attach customer anecdotes and relevant telemetry, so your implementation team knows the “why” as much as the "what" Most importantly, prioritize them by the KRs they map to.

Publish planning outcomes

Share a summary of the key outcomes you are planning to achieve for the next quarter/semester/year with your team and the stakeholders. The summary should include the OKRs and how they map to the organization's OKRs, along with a list of high-level product commitments/features that will drive the desired KRs. Reference the research findings, market analysis, customer stories, and relevant telemetry that support why you are investing in the product features.

Typically, each feature is a hypothesis that, once deployed, would deliver the desired outcomes. So there's an implicit understanding that the backlog will evolve through the semester. The OKRs should stay relatively stable unless your learning guides you to pivot in the middle of the planned window.

Good is good enough

Most importantly, don't insist on perfection. Start small. For example, your first planning session may seem like prioritizing existing commitments. It's OK - can you budget a small chunk of the resources to pilot an OKR-driven planning session? And then, you can evolve with subsequent planning iterations. Your org doesn't follow OKRs. That's OK, is there a goal or a metric that the company cares about most? Start there and build your OKRs that map to those goals. There is always a way to start somewhere and then evolve it.

In closing, product planning is more straightforward than is perceived. Start by defining the outcomes that matter. Break the objectives into granular vital results that can be mapped to features. Drive an inclusive backlog-building process to solicit diverse input on how you will deliver the KRs. Prioritize the backlog using the KRs each item maps to. Report out the planning outcomes, so everyone involved is aligned with the upcoming quarter. Most importantly, enjoy the process - use this as a learning experience and a culture-building exercise for you and the team. Commit to progressive improvement instead of perfection.

Product Management Nirvana

OKR-driven product planning