quarterly planning - Dragonboat

Knowledge Sharing in War Times

Posted on August 21, 2023August 29, 2023 by Paulo Garcia

In both times of peace and times of turmoil, the context in which we operate evolves. It’s not a matter of whether these contexts exist, but rather how well-prepared you and your team are to navigate them.

As astutely stated by Becky Flint in her Peacetime CPO vs Wartime CPO article, the synergy between product and business success is undeniable, with people at the forefront. Your team’s ability to thrive amidst ever-changing circumstances hinges on their context and how you enable them. Beyond the tangible skills needed to weather change, there lies an intangible, unspoken element: the knowledge each individual possesses about the product, the team, the company, and the broader environment.

The Essence of Knowledge

Defining knowledge is a task that could extend beyond the scope of a single blog post. However, within our context, we can at least acknowledge that it encompasses more than just product expertise. It includes the ability to interpret company strategies, the acquisition of traits and behaviours necessary to be part of the team, and more. The sheer breadth of this knowledge is staggering.

Why Does It Matter?

Knowledge, as well as our unique interpretation of it, forms the core of our individuality. It’s what, coupled with our personalities, sets apart the contributions we make within our teams and, by extension, our business landscape. It’s akin to our mental model of the real world.

Considering that most endeavours involve a team, and each team member harbours their own mental models and experiences, the collective strength of a team rests on the expertise and contributions of its individual members.

The Challenge During Turbulence

In times of upheaval, pausing or dedicating time to share expertise with others can be an arduous undertaking. A study that Dragonboat conducted revealed that over half of Product Ops professionals identify “aligning cross-functional teams” as a significant challenge during quarterly planning, a hurdle that impedes business progress.

Suggestion: Watch on demand our CPO Series webinar “Aligning Around the Right Success Metrics”.

Navigating the Terrain

Among the myriad qualities of a wartime Chief Product Officer (CPO), one stands out: information mastery. Yet, there’s one aspect even more critical: speed. In an era where we demand rapid syncs, swift response mechanisms, and instant actions, decelerating seems implausible. But it’s crucial to remember that crashing at 120MPH is far harder (and potentially more disastrous) than slowing down.

If knowledge empowers us and defines our uniqueness, then having the right information at the right time equips us to be agile and efficient. When it comes to knowledge, here’s your immediate action plan:

1. Streamline Your Approach

Invest in well-documented, targeted rituals that can be anticipated. An agenda and the right audience are excellent starting points. Already documenting? Even better. When your documentation replaces a meeting, you’re a true efficiency champion.

2. Centralize Information

Strive to create a centralised repository where team members can easily access new knowledge. This includes ongoing tasks, holiday schedules, best practices, and past lessons learned. Imagine this repository as an extension of your brain — an autonomous resource that empowers your team while liberating you.

3. Construct for the Future

Invest time in crafting a robust information architecture that becomes your digital brain’s foundation. While the content within it evolves, the structure should remain steadfast. Think of it like the pods in a beehive: unchanging in size, yet accommodating the dynamic production of knowledge. Examples of these pods could be “Our Workflow,” “Strategic Direction,” “Collaboration Guidelines,” and more.

4. Promote the Culture

In the midst of challenges, evangelism becomes a vital skill. Convincing others that sharing knowledge is pivotal won’t happen overnight. But it won’t happen at all without investment. Understand that it takes time, and lead by example. Kickstart the movement by documenting your knowledge and showcasing its value to others. Remember, this is a divide-and-conquer strategy — win people over, one by one.

A Platform for Progress

Certainly, you’ll need a platform to facilitate this seamless exchange of knowledge. While jotting down every morsel of insight on paper sheets might sound tempting, there are better options. Enter Dragonboat — a tool designed to structure your team’s portfolio and foster real-time collaboration.

With Dragonboat, you can:

Enhance roadmap visibility
Optimize resource management
Monitor portfolio delivery
Align business goals with roadmaps

To discover how Dragonboat empowers product leaders and product operations teams across the globe to thrive amidst challenges, schedule a call with our experts.

10 Common Roadmap Templates For Your Unique Communication Needs

Posted on September 2, 2022March 31, 2023 by Leah Barco

Product roadmaps are essential in communicating product plans and the reasons behind these decisions. They enable visibility and alignment, critical in product-led, outcome-focused organizations. As product managers have many stakeholders each with varied needs, they need to create different roadmap formats to tell the right story for the right audience. For example, customers may want to see the progress of requested features, while executive teams might want to know how these features help to achieve business goals.

At Dragonboat we work with thousands of teams. Here are the 10 popular and effective roadmap templates we’ve come across. In this post, we’ll share details about ten common roadmap formats and when to use them. You can create all of these roadmap formats in Dragonboat with real-time data.

Lean Roadmap
Strategy Roadmap
Outcome-Based Roadmap
Release Roadmap
Quarterly Roadmap
Theme-Based Roadmap
Team Roadmap
Technology Roadmap
Transformation Roadmap
Milestone Roadmap

1 – Lean Roadmap

What is a lean roadmap?

A lean roadmap, sometimes called a “fuzzy timeline”, provides an overview of what problems can and should be solved in order to work towards your product vision and reach business goals without being an exact outline of what’s going to be delivered and when.

The Now-Next-Later Lean Roadmap template focuses on time horizons over timelines by using three buckets to communicate and align teams on the upcoming challenges, opportunities, and issues:

Now: Initiatives and ideas in the Now Bucket are currently being worked on and are the most defined in terms of details and scope, and are often already being executed by teams.
Next: Initiatives and ideas in the Next Bucket are the ones you’re getting ready for your team to work on, and often in the discovery or planning phase.
Later: Initiatives and ideas in the Later Bucket are further down the horizon without clearly defined details. These are often assumptions of problems you foresee but are not yet ready to be moved to planning.

When to use a lean roadmap?

Product teams can use various lean roadmap formats like Now-Next-Later or expanded like this month, this quarter, this year, or in the future to organize initiatives that best drive product outcomes.

You can also use this roadmap format to communicate your priorities over broad timeframes. It’s a great choice for teams that need to provide an overview of what’s on the horizon, but need flexibility for changing release dates.

2- Strategy Roadmap

What is a strategy roadmap?

A strategy roadmap serves as the link between strategy and execution. This roadmap format visualizes and communicates the key initiatives and plans within a particular timeframe to achieve your organization’s strategic vision.

Strategic Roadmap Template - Netflix style

When to use a strategy roadmap?

A strategy roadmap is used to help product teams prioritize initiatives, allocate resources, and track and manage dependencies to ensure that an organization is focused on solving the right challenges at the right time. A strategy roadmap is what ties day-to-day efforts to business strategy.

Below are some key steps to follow to ensure an effective strategy roadmap:

Assess the key challenges that need to be solved with your strategic vision.
Set objectives that need to be achieved to solve these challenges
Evaluate your capabilities to understand what people and processes you need to have or invest in to meet the objective. (For example, if your objective is to increase sales bookings by 5% you may need sales and marketing resources. At this stage, product teams can also assess required capabilities against their current state to determine how much of a change is required to the capability to meet the objective).
Define initiatives to determine how these actions will be grouped for execution.
Build your roadmap to outline which initiatives will be delivered and in what order.

3- Outcome-Based Roadmap

What is an outcome-based roadmap?

An outcome-based roadmap gives context to roadmap items and their prioritization. This type of roadmapping approach focuses not only on the “what” (outputs) but also the “why” (outcomes). It empowers teams to align toward top-level objectives typically set by an organization in annual or quarterly planning sessions.

When to use an outcome-based roadmap?

An outcome-based roadmap is used by product teams to connect product initiatives and features with product or business goals. This helps product teams focus on delivering products customers love while also driving business outcomes. This type of roadmap is used to align teams with a focus on the end goal instead of specific deliverables to ensure objectives are achieved.

Check out our Step-by-Step guide for Outcome-Focused Roadmapping for more detail.

4- Release (Rollup) Roadmap

What is a release roadmap?

A release roadmap organizes your roadmap via releases to plan and visualize which features will be grouped into which release. It provides an overview of what improvements, features, and fixes will be included in the upcoming release cycle. Release roadmaps can span a few months, but can also be broken down into shorter 2-week sprints.

Release roadmaps are used by product teams to plan feature and product releases across upcoming time horizons and prioritize each release based on impact, effort, and benefit. With a release roadmap, product teams can also easily view and manage timeliness and progress for all upcoming releases.

When to use a release roadmap?

A release roadmap is a great way to plan upcoming releases by linking features and stories in a sprint to show how each of these individual items relates back to the overarching objectives and provides an overview of the company’s strategic direction to engineering teams. In addition, it can be used as a tool to ensure alignment around upcoming releases across multiple departments including product, marketing, and sales.

5- Quarterly Roadmap

What is a quarterly roadmap?

Certain goals like retention and market expansion are almost always present in a business but can fluctuate depending on the time of year, business goals, and other external factors. Planning quarterly helps companies better align their product planning with the changing needs of the business, customers, and market.

Quarterly roadmaps allow teams to focus on the company’s specific needs at a specific time. This type of roadmap format helps structure product roadmaps over a longer term and highlights how they plan to execute within each quarter.

Outcome focused quarterly roadmap template Netflix style

When to use a quarterly roadmap?

Product teams often perform quarterly or bi-monthly planning and build quarterly roadmaps to coordinate release plans and execution across teams. Quarterly roadmaps can be built by goals or by product areas, and typically start at the initiative level for cross-team alignment, and then break down to epic or lower during release planning.

Check out our Step-by-Step Guide for Performing Quarterly Planning with Dragonboat.

6- Theme-Based Roadmap

What is a theme-based roadmap?

A theme-based roadmap is similar to the outcome-based or goal-focused roadmap approach but is more centered on the area of focus than the outcome. With this roadmap format, initiatives and ideas are sorted and prioritized into high-level strategic roadmap categories.

Themes are a way to group similar features, epics, or initiatives. An example of a customer-centric theme may be “improve user onboarding experience.” Once themes are defined, product teams create various epics and initiatives that correspond to those themes.

When to use a theme-based roadmap?

Theme-based roadmaps can be used to keep teams connected with the key business goals and help structure, plan, and prioritize work more effectively. Theme-based product roadmaps are used to break down major initiatives. Themes can be linked to goals and clearly display all associated ideas and initiatives to communicate and justify decisions and prioritization with internal and external stakeholders.

Below are some key steps to follow to ensure an effective theme-based roadmap:

Define Themes: When setting themes, keep in mind that they should be goal-driven. At this stage, it can be helpful to get executive alignment on the goals to help ensure alignment on themes.
Identify initiatives: Come up with the initiatives that will best address the overarching themes.
Determine success metrics: Set metrics to determine what success looks like and make sure goals are measurable so you can iterate in the future.
Collaborate: When setting themes it can be important to make them cross-functional to ensure alignment.
Iterate– As with any good roadmap, your theme-based roadmap is never finished. Revisit your roadmap to reflect on any new learnings or changing priorities.

7- Team Roadmap

What is a team roadmap?

A team roadmap is a way to visualize the initiatives and epics specific to your teams such as product team, marketing, customer success, or sales. Within a team roadmap, there may also be sub-roadmaps. For example, a product team may also have sub-roadmaps to include each specific product team under that umbrella.

When to use a team roadmap?

A team roadmap can be used to gain better visibility on the progress of initiatives and epics specific to your team and also how those are contributing to overarching business objectives.

8- Technology Roadmap

What is a technology roadmap?

A technology roadmap communicates and visualizes at a high level an organization’s technology strategy. Two common types of technology roadmaps are internal IT roadmaps and software roadmaps. Technology roadmaps help internal teams make strategic decisions around their technical infrastructure.

When to use a technology roadmap?

A technology roadmap is often used to strategically plan any complex changes to an organization’s technological infrastructure and addresses things like technical debt. As an example, a technology roadmap may be used when a new system is being rolled out for employees and show when the previous system will be offboarded.

Depending on the type of technology roadmap you’re creating, below are a few steps that should be taken to ensure success:

Identify strategic objectives to clearly articulate the “why” behind the proposed change.
Understand your audience to ensure non-technical teams can easily understand your vision.
Establish key initiatives to support this change.
Align with teams to prioritize initiatives, estimate the impact and effort, and allocate resources to ensure successful delivery.

9- Transformation Roadmap

What is a transformation roadmap?

Digital transformation involves integrating technology across a business to achieve a competitive advantage. The process is often complex and can take months or even years to successfully complete and can include replacing existing traditional processes with digital solutions in response to the evolving business and market needs.

A digital transformation roadmap is a plan that moves your organization from Point A (using your current digital processes) to Point B (using new digital processes).

When to use a transformation roadmap

A transformation roadmap serves to break down the complex process into steps and outline those steps that the organization should follow to achieve business goals through the use of technology. A digital transformation roadmap is used to provide structure to the migration from one tool to the next — including everything from technology, people, and processes — to ensure a successful transformation.

Below are some key steps to follow to ensure a successful transformation roadmap:

Define transformation OKRs
Align teams with your vision plan
Align initiatives with strategic factors and align features within those themes or initiatives
Set metrics to measure success
Assign resources to ensure viability and success
As transformations often have longer time horizons, setting quarterly milestones can help ensure effective delivery

10- Milestone Roadmap

What is a milestone roadmap?

Roadmap milestones are events or deadlines represented by a single date. Product managers can add milestones to their roadmaps to share important dates and events with their team such as product releases, feature releases, or industry events.

When to use a milestone roadmap?

Setting milestones correctly in your roadmaps is an effective planning technique that can make your sprints and progress towards goals more effective. Milestones in Agile planning provide clear outcome-based goals to work towards and can be used to address the accuracy of a team’s priorities towards the goal.

Create, Save, and Share Your Roadmaps

The next step in building a successful product roadmap in any format is to share it with your audience. With all of these roadmap formats, you can easily share them directly from Dragonboat to keep teams aligned and stakeholders informed.

Ready to start creating roadmaps in Dragonboat? Follow along with our Step-by-Step Guide to Creating 10 Common Roadmap Formats with Real-time Data.

How to Do Outcome-Focused Roadmapping (Step-by-Step Guide)

Posted on April 19, 2022March 31, 2023 by Becky Flint

With requests and feedback coming from multiple stakeholders and data sets, and without a clear guide for how to do outcome-focused roadmapping, product teams can easily find themselves stuck in the “build trap”- building features without having visibility into their impact on the company goals.

Traditional feature-based roadmaps are built around a backlog of ways to improve products based on customer feedback and market insights, which is not a bad thing. The problem with this roadmapping model, however, is that the prioritization method is linear. When so many factors and dimensions play into decision-making, such as business, customer, and market needs and timelines, an approach with more depth and perspective is required.

Today, product teams are switching from feature-based roadmaps to outcome-focused roadmaps to deliver products customers love while also driving business outcomes

In a previous post, we covered the factors that lead teams to make the switch from feature-based roadmapping to OKR/outcome-focused roadmapping. In this post, I’ll cover the key elements and provide a step-by-step guide of how to do outcome-focused roadmapping with Dragonboat’s Responsive Product Portfolio Management tool.

The Dimensions Of Outcome-Based Roadmapping

Feature-based roadmapping typically focuses on one type of outcome—for example, more products to market (business outcome), higher feature adoption (customer outcome), or higher revenues (portfolio outcome). A product manager has a backlog of product requests and must choose which features to prioritize based on a selected outcome.

With an outcome-focused approach (and the right product portfolio tool), product teams can build outcome-based roadmaps to achieve multiple outcomes, manage multiple teams, and provide a framework for the outcome-driven product workflow.

Check out this episode of the Product Experience where I discussed escaping feature factories, the three signs of a truly outcome-focused product org, and more:

Outcome-focused product teams start by first defining their desired goals and outcomes and then deciding which actions are needed to achieve them. Using a purpose-built tool like Dragonboat allows you to consider all the dimensions of your business, customer, and portfolio, as well as time horizons to ensure success in both the near and long term.

Leveraging a tool like Dragonboat eliminates the need for planning across multiple spreadsheets, product backlogs, and feature requests and syncs all your deliverables, product teams, and timelines to visualize a clear path forward across your entire organization. Dragonboat also captures all your outcomes, achieved or not, to inform your next planning phase.

“You need to understand how you contribute to the strategy and that’s what Dragonboat helps you do. It gives you the understanding of how all the things you’re working on ladder up into the bigger company goals and how that looks across the portfolio. Even if you’re not making those strategic decisions about what to start and stop, you need to understand how you fit into the picture.”
–Melissa Perri, CEO of ProduxLabs at ProductCon

Now that we’ve looked at the “why,” let’s take a look at the ‘how.”

Here’s a step-by-step guide to ditching the feature factory and adopting Dragonboat’s outcome-driven approach:

How To Do Outcome-Focused Roadmapping In Dragonboat

Step 1: Set Goals And Key Strategies

Objectives and Key Results (OKRs) are set at the executive level and during strategic planning sessions, teams brainstorm various strategies to turn those business goals (objectives) into strategic goals (key results) to measure how they are achieving this objective.

These strategies turn into product initiatives that often include one or more product features that collectively carry out the strategy. This is why outcome-focused teams need to create OKRs before product initiatives.

In Dragonboat, you can connect OKRs to product initiatives to align and allocate towards goals to give you the context and alignment needed to prioritize and build, and measure results with confidence.

how to do outcome focused roadmapping — **Create your goal hierarchy to tie work to outcomes.*

Step 2: Define Metrics To Measure Goals

Once you’ve set goals and key strategies, you’ll need to define what metrics to use to measure effectiveness and impact.

In Dragonboat, you can set both company and team-level goals as well as set key metrics and strategic themes so you can have visibility into how your initiatives are impacting the goal.

how to do outcome focused roadmapping in Dragonboat — *Set key metrics to measure goals

Step 3: Prioritize The Most Impactful Features And Initiatives

Once your ideas, requests, and initiatives have been centralized, you can group categories, align them to the respective goals they will impact, and prioritize them against each other as it relates to their potential contribution towards that goal.

For more on Dragonboat’s approach to prioritization, read “Rock, Pebble, and Sand Product and Portfolio Management.”

Prioritizing with purpose is an essential element of building an outcome-focused roadmap. To avoid getting caught in the build-trap, focus on the most important items to solve first. Prioritize backlog items based on those answers as well as available resources in the upcoming timeframe.

Leveraging the Metrics over Available Resources (MoAR) prioritization framework allows you to incorporate a direct measure against goals into your roadmap planning/ dynamic alignment process. This enables better product decisions, easily visualized product portfolio metrics, and improved overall outcomes. RICE is another commonly used prioritization framework (illustrated below).

outcome focused roadmapping — **Dragonboat’s portfolio list view shows your goals and ideas displayed together and in priority order.*

Step 4: Plan Roadmap-Account For Dependencies And Allocation

To achieve the best portfolio outcomes, you need to allocate resources towards short-term and long-term goals to ensure your company is not only achieving current goals but also growing and innovating towards long-term success.

Each goal you define should have planned allocation to build the most effective outcome-driven roadmap. For example, you can choose to allocate 50% of resources to new revenue and 50% towards innovation. In Dragonboat, you can easily see your planned vs actual resources to understand if your roadmap can be executed effectively and make adjustments where needed.

outcome focused roadmapping in Dragonboat — **View your resource allocation easily in Dragonboat.*

Just as important as the proper resource allocation for successful roadmap delivery is to manage dependencies. If left unchecked, roadmap dependencies can hinder your progress and delay outcomes. Dragonboat helps you effectively plan, visualize, and auto-track dependencies to ensure successful product delivery.

*Manage portfolio dependencies in Dragonboat

Step 5: Monitor Delivery Progress

Once you’ve planned goals, strategic themes, prioritization, and resourcing within Dragonboat, push to execution tools (like Jira) for delivery, and roll back up to Dragonboat for visibility and insights.

Within Dragonboat you’ll be able to see the progress of your roadmap in real-time and be automatically alerted to any delays or delivery risks.

“What I love about Dragonboat is that it’s much more than just a product portfolio management software. It enables a framework for how to run a successful product company. It’s insightful and intuitive. Every outcome-focused product organization should use it.”
-Eston Taylor, Bushel

Step 6. Monitor Outcome Progress And Adjust Roadmap Based On Results

Not only is it important to track the progress of product roadmap items (initiatives), you should also track the progress of your OKRs (outcomes) to understand what worked and what didn’t work, and inform future product planning to achieve goals. You can monitor the outcome progress and return to step 4 to adjust the roadmap iteratively.

Having a Responsive PPM tool like Dragonboat allows you to easily view and update status and health, so that you can measure results and responsively re-allocate based on performance.

Create Winning Roadmaps With Dragonboat’s Outcome-Focused Portfolio Management

Great product managers exist at both market leading and market losing companies. So, what sets the two apart? Focusing on business, customer, and portfolio outcomes. By following the above steps and integrating all of these dimensions with time horizons, you’ll move from feature factory to outcome-based roadmapping.

Using Dragonboat, whether your product portfolio management approach includes metrics like revenue, new market penetration velocity, platform uptime, or NPS scores, prioritization and resource allocation is simple and can be adjusted periodically in response to the market and business needs.

“With Dragonboat, our Product Team can not only plan, evaluate and sequence work, but they are able to tie all their ideas directly to the target Company and Product Objectives, connect them to Jira, and get seamless and dynamic health and predicted end dates, all in one place. They can also easily manage up using the dashboard and allocation reporting features.”
-Jackie Orlando, Director of Product Operations, Tealium

As you can see, moving from feature-based to outcome-focused roadmapping can be done in a few simple steps. The right purpose-built tool will make the process even easier.

Good Product Ops, Bad Product Ops

Posted on March 25, 2022April 13, 2023 by Kalei White

Product operations (product ops) is a key function of a product organization; and a good product organization is essential to the success of any company. But the Product Ops role seems fuzzy, how do you evaluate good product ops vs bad product ops? In this post, we’ll cover the 6 key factors that differentiate good product ops from bad product ops.

Customer – Who is the customer for product ops?
Focus – Where should a product ops focus?
Approach How should a product ops approach their role?
Process – What and how processes are managed?
Tooling – What tool stack should be adopted?
Growth – How should a product ops team grow?

Before we start, let’s take a look at how important it is to have good product ops vs an ok product ops. For some people, Ops roles are usually considered a peripheral role. But this view is very dangerous.

Product Ops orchestrates the entire product organization connecting top, down, and across teams and functions. This makes them one of the most leveraged roles in a company.

When product ops make even a small change, it can lead to a big impact.

So, how can you be sure that what you focus on and the changes you make create the greatest impact? What should you do in order to be successful and get promoted in your role as a product ops manager? Let’s dive into these 6 key characteristics of good product ops and what you can do to accelerate your growth – both personally and professionally.

1. Good Product Ops Serve The Entire Product Organization as Customers, Bad Product Ops Serve Only Their Immediate Teams

A commonly held belief is that product ops work to serve product managers. While this is true, it’s only half the story. A great product ops manager understands that her customer is not only the company’s product managers.

“A great product ops manager will view the entire product organization and their customers (stakeholders) as the customer they are serving.”
– Becky Flint, CEO and Founder of Dragonboat

A good product ops makes the entire product organization successful. A bad product ops pleases the product managers they are grouped with.
Serving more than just one customer is an important approach for any ops role to take, not only product ops. For example, if we consider the role of sales ops, they work to serve the entire sales org, driving revenue and accelerating growth for the whole company.

2. Good Product Ops Focus On Enabling Business Outcomes, Bad Product Ops Only Facilitate Data Collection

New product ops managers often fall into the trap of focusing too much on facilitating customer insights. They may tackle this initially since it’s relatively low-risk and simple to understand and get buy-in.

However, focusing only on facilitating data collection, triaging customer feedbacks leads them to bad product ops practice, potentially missing the big picture with an overly-simplified believe what’s needed to succeed in product.

A product organization is multi-faceted and many factors drive success. The most successful product ops pros orchestrate how decisions are made, how data is gathered, and help determine how to adapt to the evolving needs of the customer, stakeholders, and the business.

This means Good product ops focus on enabling customer outcomes and achieving business results for the product organization.

Good product ops also triage the needs of the current and future market, drive near-term and long-term results, and balance these needs as the product org and company evolve as they navigate through the world they’re operating in.

3. Good Product Ops Connects Strategy and Operations, Bad Product Ops Behave like On Demand Helpers

Don’t be fooled – product operations has ops in the title, but it’s a highly strategic role. A successful product ops manager takes the opportunity to initiate critical strategic discussions and facilitate alignment between product teams and their stakeholders.

They also design and orchestrate the product and portfolio rhythm from annual/ semi-annual strategic planning, to quarterly alignment, and bi-weekly or weekly ops reviews and stakeholder engagement. Additionally, they ensure alignment on goals, access to data, prioritize holistically, and adjust all aspects of running a product organization.

“Product Operations — the art of removing obstacles from evidence-based decision making. Done right, it fuels a virtuous cycle of benefits that’ll empower everyone from the executive team all the way to each individual contributor responsible for building the products — whether Engineers, Designers or Product Managers.”
– Melissa Perri, CEO of ProduxLabs

4. Good Product Ops Manage Process as a Product, Bad Product Ops Enforce Processes No Matter What

Some call product ops the “process people,” instead of viewing them as creators. But process is not a bad thing when done right. A Process is a product that orchestrates all the moving parts related to this process to function in a cohesive way. This is why “Processor” is a core part of every computer.

Each “Process Product” is built to solve a problem and this process product needs to be managed and updated continuously along with the rest of the organization. If someone build out a large, set-in-stone, and inflexible process and they forget about the “why” behind it in the first place. What are the “jobs to be done” for that process?

To avoid this misstep, manage and iterate the “product” of process. Adapt it continuously for ever-changing needs rather than blindly following a set process. Thinking in design systems, product ops should work as an API between teams and functions, rather than being hardcoded or like a bandaid solution.

5. Good Product Ops Promote Integrated Tooling For Team and Portfolio Needs, Bad Product Ops Tolerate Siloed Tool Choices

A common challenge for product ops is to reconcile the different tools and spreadsheets used across different product teams. In response, some product ops managers will allow tooling to be decentralized so that each person/team can do what they want, where they want. This takes the form of stitching things together, creating time-intensive slide decks in PowerPoint, massive spreadsheets, and even data warehouses.

However, it is more beneficial to implement end-to-end tooling to create a central source of truth for portfolio decisions, visibility and outcomes. This is when a responsive product portfolio management tool is needed. Successful product ops find the right tool that will allow them to focus on the strategic side of the role and operating the strategy.

“We needed to have a single source of truth for idea management, a way to enable smarter outcome-based decisions, visibility for senior leadership into investments being made, and general visibility with the roadmap, because there was a lot of feeling like things would go into a “black box”, and no one would know what was coming out the other side and when.”
– Jackie Orlando, Dir of Product Ops at Tealium, on creating a single source of truth a Responsive PPM tool

Learn more about how Jackie Orlando built and scaled product operations at Tealium.

6. Good Product Ops Are Force-Multiplier, Bad Product Ops Keep Doing the Same Without Scaling

Perhaps you’ve reached the point when you’ve already figured out a strategy to make your customers successful and it’s working! So, you start wondering, where to go from here?

A common misconception about product ops is that the function grows linearly based on the number of PMs a company has. For every 10 PMs, you need 1 product ops. However, this isn’t the optimal way for product ops to grow.

As mentioned before, product ops is a highly leveraged role. A good product ops professional manages themself out of the job so they become a force multiplier. Product ops’ growth should be multiplied and evolve based on how well you serve the customer.

“I like to think of this Force Multiplier Model as having a Product Ops function at the same level as Product Management and Product Design. Product Ops is there to serve as a force multiplier to product managers, product designers and for certain activities, the product marketing managers.”
– Marty Cagan on the Force Multiplier Model of Product Ops

Become a Strategic, Outcome-Focused Product Ops Leader

Like any role, there is always a spectrum of good and bad with practices that go hand in hand with each. Contrary to the title, product ops can’t just be focused on ops. For good product ops, the goal is to think about your position as a strategic role where your mission is to lead and orchestrate the product org to achieve the best outcomes.

Here are some of the biggest do’s and don’ts that product ops managers should know:

If you’re just starting out as a product operations manager, keep in mind that your job is not just about improving efficiency, your ultimate objective is to accelerate product portfolio outcomes, just like a sales ops manager’s purpose is to ultimately accelerate revenue growth.

You can rejoice in knowing that the whole company is your customer – you can have a huge impact. As the chief enabler of your product organization, you help the company to balance the right outcomes at the right time – short vs long term customer and business needs.

So, to answer the question, “How can I get promoted as a product ops manager?” Follow these six tips and you’ll be in a much better position to be promoted, for example, to be the Director of Product Ops. Then you should be able to expand the team to increase product ops’ value exponentially!

Setting Product OKRs – 5 Mistakes That Might Be Holding Your Team Back

Posted on November 12, 2021September 20, 2023 by Kalei White

When it comes to setting product OKRs (objectives and key results), there are several rules of thumb that most who are familiar with this goal framework already follow. For example, objectives should be aspirational enough to motivate team members, and key results shouldn’t be easy targets. When used correctly, a product-led company can use goal-setting frameworks like OKRs to accelerate outcomes by enabling top-down alignment, bottom-up innovation, and cross-functional collaboration.

Let’s dive into some mistakes that go beyond the obvious dos and don’ts of setting product OKRs that even the most well-intentioned organizations make when rolling them out.

1. Are Your OKRs Connected to Product Initiatives?

It’s typical for companies to implement OKRs by starting from the top and breaking big goals into smaller pieces for each level of the organization to own, which creates a waterfall effect or “cascading OKRs.” Each step of the way down, the scope gets smaller and the underlying assumption is that each of the smaller scopes stacked together will achieve the higher goal.

While that sounds nice and cut-and-dry, in reality, things are not as straightforward. Here are some of the main reasons why cascading OKRs are impractical:

Most companies have teams that work cross-functionally on multiple initiatives (more on that later in this post)
When teams focus on their own goals, they become siloed and disincentivized to help others achieve their goals
Through a top-down command and control management style, they stifle bottom-up innovation and promote micromanagement

To overcome these challenges, rather than breaking down goals into the different hierarchy levels and assigning them to specific people or teams, break down goals based on various initiatives that can help support the outcome.

Let’s look at an example. For a company-wide OKR, such as “double revenue,” the initiatives should be cross-functional, allowing multiple teams to work towards the same goal. For instance, an initiative at an ed-tech company could be “Launch teacher taskforce” for which marketing could focus on new messaging & leads for teachers, sales on increasing conversion, and product on getting teachers to value faster to boost retention.

Learn more about how product teams can connect OKRs with product initiatives to empower teams and how to switch from feature roadmapping to OKR roadmaps.

2. How Do Your Initiatives Impact Other Teams?

It’s important to remember that everything’s balanced in business and while setting product OKRs, the law of cause and effect still applies! Say the marketing team wants to increase conversions, for example. It can do so by running different experiments that will impact other teams in different ways. This might include lowering the price, extending the free trial period, or reducing friction on the demo sign-up page.

While this might improve conversions, it could cause problems for other teams. For example, by eliminating some of the fields in the demo request form, the conversion rate will improve, but at the same time, it will generate more work for the sales team. Now, they have to spend more of their precious time qualifying leads.

Remember to respect the balance and the importance of other teams’ goals and initiatives. Make sure you’re setting product OKRs that would not negatively impact others if you were to achieve them.

To make sure you set product OKRs that are not in competition with other areas, it’s imperative to have easy visibility and cross-team collaboration. For managers, this means being able to effectively create alignment by collaborating up, down, and sideways.

3. Are Your Goals Cross-Functional?

Since teams don’t live in a vacuum, it will always be true that multiple teams must come together to achieve different goals, which means roadmap dependencies will inevitably occur. It’s important to spot them, plan ahead, and keep track of them with a responsive product portfolio management platform.

So, to ensure cross-functional success, keep in mind these three things about setting product OKRs:

1. Prioritize amongst your different goals.

2. Allocate your resources to these goals.

3. Identify & plan dependencies across teams.

If you manage to do these three steps, everyone across the organization can agree on what should be the main focus at a given time and with what resources.

4. Do You Have Visibility Into Goal Progress?

One of the biggest telltale signs that your OKRs aren’t working is when individual contributors and managers don’t look at them as time goes by. Instead of a “set it and forget it” artifact, OKRs and any progress made towards them should be reviewed consistently and frequently using a responsive product portfolio management tool. Thus, the team can work in a way that is responsive to the business goals and changes in the market.

Similarly, it’s a mistake to only look at OKRs during performance reviews, relegating them to an HR activity. Team progress should be tracked in real-time so that if there needs to be strategy adjustment and re-allocation, it can be done before it’s too late. Outcome-focused product means multiple teams are contributing initiatives to achieve the objective. The allocation should therefore ebb and flow based on insights of what’s working and what’s not.

5. How Are You Balancing Short-Term Wins with Long-Term Focus?

Product teams must avoid the potentially fatal mistake of not thinking far ahead enough into the future. Striking the right balance between making progress on short-term and long-term goals (aka big bets) is what keeps companies competitive despite shifts in the market landscape and customer tastes. Remember what happened to Blockbuster when Netflix arrived on the scene? This is where strategic planning plays a critical role so that nothing important falls through the cracks.

One effective way to prioritize is the rock, pebble, and sand technique. Responsive product portfolio management follows this approach, but with its own adaptation. It incorporates multiple jars of varying sizes, recognizing that at any given time, product needs to support many goals, compete for the same resources, and allocate them accordingly.

That wraps up some of the most common mistakes teams make when setting product OKRs. Can you think of some others? Let us know!

Build Outcome Driven Product Webinar CTA

OKR Product Management: Aligning Product OKRs to Outcome-Focused Roadmaps

Posted on June 17, 2021August 21, 2023 by Becky Flint

Product management goes beyond addressing customer needs. It is about balancing customer requests, product initiatives, and your company’s strategic vision. If your organization uses OKRs as a goal-setting framework, aligning product OKRs and initiatives is key to determining which features to prioritize. In this blog, we will show you how to use product OKRs to create outcome-focused roadmaps and build customer-loved products that drive business success.

What is an OKR?

OKR stands for “Objectives and Key Results” – a framework for companies to set and track measurable goals. Objectives outline what you want to achieve, while Key Results help you measure progress.

Here are some key terms in the OKR product management framework:

Goals: The high-level mission or vision of an organization.
- Example: Become the top digital banking service in the country.
Objectives: Specific, measurable steps to achieve your goals.
- Example: Increase the number of users on our mobile banking app by 15% within the next year by adding new features and expanding marketing efforts.
Initiatives: Specific projects that help you achieve your objectives.
- Example: Create and launch an in-app international money transfer feature.
Key Results: Measurable outcomes showing progress towards objectives. These should be specific, quantifiable, and time-bound.
- Example: Reach a 15% increase in monthly active users of the app within six months of launching the new international transfer feature.

Companies use OKRs at the organizational, team, and individual levels. So, product OKRs are simply your product team’s OKRs (objectives and key results). Setting OKRs for product managers helps to align efforts toward achieving product-related objectives, such as increasing product adoption, that support the company’s strategic goals.

Product management OKRs are essential in driving product innovation and enabling data-driven prioritization decisions because they highlight the impact of each initiative on business outcomes. Then, once you establish product OKRs, you can maintain them throughout product roadmap planning, resource allocation, and progress tracking.

How Do Companies Use OKRs?

Companies apply OKRs to establish clear goals with measurable results and align teams around shared objectives. OKRs are used throughout an organization to promote transparency, accountability, and a focus on achieving impactful outcomes.

An Example of Multi-Level OKRs

To illustrate, let’s look at an example of how companies can use the OKR process to translate high-level business goals into specific team OKRs.

Management Objective: Grow our business. Key Result: Increase annual revenue by 20%

Marketing Objective: Optimize customer acquisition. Key Result: Reduce Customer Acquisition Costs (CAC) by 20% in Q3

This marketing OKR aims to optimize customer acquisition by reducing Customer Acquisition Costs. By lowering CAC, the marketing team can effectively acquire more customers with the same budget, ultimately contributing to the management OKR of growing the business. As a result, the company can allocate saved resources to other growth opportunities, further supporting the overall business expansion.

Product Objective: Improve the quality of our products. Key Result: Resolve customer-reported bugs within two weeks

This product OKR example aims to increase product quality. By quickly addressing and fixing these issues, the company can enhance customer satisfaction and the user experience. As a result, this can lead to increased customer retention, positive word-of-mouth, and potential new customers, all of which contribute to the management OKR of growing the business.

Customer Success Objective: Enhance enterprise customer satisfaction. Key Result: Increase satisfaction rate from 4.2 to 4.8

This customer success OKR aims to enhance enterprise customer satisfaction. By improving customer satisfaction, the company can foster stronger relationships with its enterprise clients, leading to increased loyalty, higher retention rates, and potential upselling opportunities. These factors directly contribute to the management OKR of growing the business.

Each team OKR is specific, measurable, and aligned with the overall strategic objective to increase annual revenue. So, the beauty of the OKR approach is that it allows you to measure progress at every level to ensure results.

How to Use Product OKRs in Your Outcome-Focused Roadmaps

Define your product OKRs
Prioritize product initiatives within OKRs
Estimate the investment, then allocate resources
Track progress in a product OKR dashboard
Report results to stakeholders

So, let’s bring it back to product. An OKR Product Management approach improves outcomes by reducing the number of irrelevant roadmap features, streamlining release processes, and enabling better product-market fit.

Product teams use various tools for product management ranging from humble spreadsheets to complex software solutions. But when adopting an OKR product management approach, we recommend using a purpose-built tool like Dragonboat to connect product OKRs to outcome-focused product roadmaps seamlessly. Below we will show you how step-by-step:

1. Define Product OKRs

To create focus and alignment with your product OKRs, consider these three tips:

Set quantifiable key results to measure progress while being mindful of prior OKRs for continuity.
Confirm that your product OKRs align with strategic company goals
Allocate appropriate resources to ensure achievable outcomes.

Using Dragonboat makes setting and managing objectives easy. You can add new OKRs, including product team OKRs, from any portfolio page and manage them from the goal-setting page or outcome module. The screenshot below shows you how this looks.

When defining OKRs, you can also allocate resources by percentage or absolute number, enabling you to track and monitor progress to keep teams and product roadmaps aligned. Once you define your product OKRs, they become the baseline for your entire product strategy.

Shreenshot of setting product OKRs using Dragonboat.

When using a tool, you should be able to easily manage your objectives. In Dragonboat, you can Add, Edit, Merge, Archive, or Delete Objectives on the Feature Board page. From there, you can add subgoals to your OKRs to clearly map out your goal setting.

You can also add allocation, either by percentage or by an absolute number, for each OKR. So your target can later be matched with your plan to keep your teams and roadmap aligned.

You now have your OKRs clearly defined in your tool. Take your time with this step, as it will serve as the baseline for the rest of your product strategy.

RETURN TO NAVIGATION

2. Prioritize Product Initiatives Within OKRs

An outcome-driven organization prioritizes initiatives for the relevant OKRs based on how much they contribute to each objective vs. the effort required to deliver the benefit. The metric to measure this is called MoAR, or Metric Over Available Resources.

When using a product management tool such as Dragonboat, you can add features or initiatives and map them to OKRs, as shown below.

Screenshot of mapping OKRs to initiatives in Dragonboat.

If you also use MoAR to evaluate and prioritize your features quantitatively, you can add your benefit score to the Feature List page, as illustrated.

RETURN TO NAVIGATION

3. Estimate the Investment, Then Allocate Resources

Although estimating the investment required to reach each objective and prioritizing initiatives is important, you must also allocate resources across all OKRs. So, Dragonboat provides a high-level view of resource needs and current allocations (shown below). Reviewing your allocations from this perspective allows you to re-balance to maximize the impact of your product efforts and achieve target outcomes.

Screenshot of a report in Dragonboat showing resource allocations across objectives.

RETURN TO NAVIGATION

4. Track Progress in a Product OKR Dashboard

To stay on track, monitoring the progress of your OKRs (outcomes) and product roadmaps (initiatives) is crucial. Dragonboat simplifies progress tracking by allowing you to easily view and update the status and health of your objectives and initiatives without any additional configurations.

Screenshot of a product OKR dashboard in Dragonboat.

The snapshot page above provides a convenient way for product teams and executives to view outcome and roadmap progress side-by-side, with all metrics displayed in a single pane.

For additional insight, integrations with tools like Jira, Github, or Asana provide real-time trend data, making progress tracking and roll-up reporting seamless.

RETURN TO NAVIGATION

5. Report Results to Stakeholders

You have spent a lot of time defining how your product OKRs can benefit your company, managing initiatives, and guiding your team’s work. Your progress is integral to your company’s success, important toward driving organizational alignment, and helps you focus on achieving outcomes rather than just delivering outputs.

A good tool will make sharing results with key stakeholders, executives, and team members easy. Below is a simple example of a report using Dragonboat.

Screenshot of a stakeholder report in Dragonboat.

Key Takeaways

Outcome-focused organizations often use the OKR framework to guide decisions and expect their product teams to do the same. When this is the case, aligning product OKRS to your product roadmaps can help you prioritize initiatives that will most impact business outcomes. That will enable you to make data-driven decisions and create transparency and accountability at all levels.

A purpose-built tool like Dragonboat can help you do this by guiding you through defining OKRs, prioritizing initiatives, allocating resources, and tracking and reporting results. Schedule a demo today or sign up for a free trial to see it yourself.

RETURN TO NAVIGATION

Rock, Pebble, and Sand Product and Portfolio Management

Posted on June 17, 2021September 20, 2023 by Becky Flint

Prioritization is the most challenging and impactful part of product management. The Rock, Pebble, and Sand Product Management approach is an effective way to prioritize across products and portfolios.

The Rock, Pebble, and Sand approach is a product management framework originally popularized by PayPal product leaders. Product management is a juggling act with a constant influx of product ideas coupled with unplanned production issues and Rock, Pebble, and Sand helps teams prioritize. As part of the Responsive Product Portfolio Management framework, the approach connects OKRs with Agile and is often carried out in quarterly product planning.

Here’s how this technique can help your teams align the company and achieve your product OKRs effectively.

Rock, Pebble, and Sand Explained

Imagine you are filling a jar with rocks, pebbles, and sand. Each piece represents the potential benefits and extent of effort required to pursue a product idea. The jar represents the available engineering capacity in a given time, e.g. a quarter.

The rocks represent the biggest potential impact and effort. For that reason, the rocks need to be prioritized first and added to the jar before anything else.

Next, add the pebbles; these have less strategic impact, but the impact can accumulate significantly.

The sand comes last and represents small effort tasks or bug fixes.

Building a mobile app is a good example of a rock. As it follows, pebbles would be UX improvements and sand would be any production bugs reported by a customer.

While stakeholders primarily focus on the rocks, all these elements are important to engineering teams who will prioritize protecting the shipping time for big rocks over those for pebbles or sand.

Placing the most important product in the jar first allows teams to prioritize and fit more pieces into a fixed capacity jar.

The Evolution of Rock, Pebble, and Sand

David Sacks, the first COO of PayPal, founder of Yammer, and now founder of Craft Venture, wrote a Medium post on the Rock, Pebble, and Sand method practiced at PayPal since its early days. We have been fine-tuning this approach when it comes to product operations for over a decade both within PayPal and at small to mid-sized companies like Shutterfly, Bigcommerce, and Feedzai.

We expanded the approach further with the concept of product portfolio management to incorporate a “variable-sized” jar when prioritizing product initiatives and allocating engineering resources across teams.

Why Allocate Resources Using a Rocks, Pebbles, and Sand Portfolio Approach?

With the Rocks, Pebbles, and Sand approach, product leaders have a framework to categorize requests according to the business outcome and request’s contribution.

The variable jar approach recognizes that at any given time, product needs to support many goals competing for the same resources. For example, user acquisition, platform scalability, and new market expansion.

Prioritizing big rocks for these varied goals results in an apples to oranges comparison. Instead, “virtual jars” of various sizes represent the amount of resource allocation applicable to the product team’s goals. The rocks fit as acquisition goals in the acquisition jar, and platform rocks in the platform jar, and so on.

Why are separate jars better? Because this enforces a level of accountability at the leadership level. Leaders define goals. Leaders must decide what resources should be applied to these goals. These decisions give their teams what they need to be innovative and create products with the essential resources.

Goals shift according to market and business conditions, and so should the number and the size of jars. For example, in Q1, there might be a 20% allocation to tech debt and 50% in acquisitions. Whereas, in Q3, there may be a 40% investment in tech and 20% in user acquisition because the user growth has strained the platform.

Transform With A Proven Practice

At PayPal, we proposed, evaluated, and prioritized rocks and used this information to create engineering budgets and headcounts annually. As the pace of change accelerated, we increased our product planning to a quarterly practice during our agile transformation. Ultimately, we rolled out the product portfolio management framework, connecting annual vision and goals with quarterly milestones and adjusting the portfolio allocation responsively. This practice allowed rapid product innovation while ensuring the continued improvements of existing product experience and growth.

Quarterly Planning for Product Manager CTA

We Need A Portfolio Program Manager Not Just Scrum Masters

Posted on August 19, 2020November 18, 2022 by Becky Flint

A dedicated scrum master is essential for new Agile teams. They are the glue that holds everyone together, ensuring that members adhere to best practices and agreed processes. Much like glue, it will take some time to set. Once everyone understands the makings of a good scrum – from planning to tracking – they are on their way to becoming a well-oiled, self-organizing team.

At this point, the scrum master will no longer require a full-time role because everything works for the most part. So now what? Now, is the time for an up-leveling because

Enabling an Agile engineering team is just the start of an Agile company.

Agile execution via scrum helps build quickly and iteratively. However, it does not automatically enable higher-level alignment of our strategies towards our goals (OKRs). Additionally, it does not enable cross-team cross roadmap collaboration to build synergies or iron out dependencies.

To unlock greater agility, companies need to also practice responsive portfolio program management. Responsive PPM dynamically connects objectives, initiatives, and resources with Agile execution. It also calls for people with the right skills to help move the organization forward.

The Responsive Version of Program and Portfolio Management

Traditional program management focuses on large, cross-functional, and complex programs with many projects. Moreover, the traditional portfolio management focuses on planning, budgeting, and tracking a suite of programs. Both are mostly practiced in large organizations with complex structures.

In small to mid-sized companies, your entire product roadmap is a portfolio.

Many fast-moving companies today may have only a few, if any, large programs. However, they usually have many smaller moving pieces carried out by one or more agile teams. As the agile teams are continuously iterating on product enhancements, there is a missing “glue” to connect them together. This is a recipe for chaos. Promised features go undelivered, support teams are left in the dark, and everyone is sending urgent feature requests filling up the roadmap pipeline.

Solving this takes portfolio management skills.

What Portfolio Program Managers Do

In a nutshell, portfolio program managers ensure the best-desired outcome for an organization over a relevant time period, within the constraints of resources. Scrum master leads scrum cadences while portfolio program managers lead quarterly (or month/ bi-monthly) portfolio roadmap cadence. Their duties can be summed into three key areas:

Quarterly Strategic Planning for Portfolio Allocation
Roadmap Delivery and Trade-Off
Progress Communication

A portfolio program manager works with key stakeholders to create a clear and holistic process for defining priorities responsive to the time-frame. They also lead trade-off discussions between the product areas or teams using portfolio principles to allocate the right resources towards various objectives and initiatives.

Lastly, after deciding the product features and initiatives to undertake, they transition delivery to the agile teams knowing the key-elements of the plan are in place for the team to execute.

Then they track the progress and outcomes, and keep the stakeholders informed.

When changes inevitably happen – for example, when a new high priority feature request comes to the team – portfolio program managers lead roadmap trade-off discussions to minimize the impact on in-flight features while still accommodating new requests in a way that best achieves the company’s desired goals.

In Responsive PPM, We Believe All Factors Are Dynamic

This is precisely where a portfolio program manager comes in to connect the moving pieces in a holistic and dynamic way.

This transition from being a scrum master to a portfolio program manager represents both professional growth for the individual and also a strategically impactful role to every organization.

A Step-By-Step Guide to Quarterly Product Planning

Posted on April 12, 2019September 11, 2023 by Becky Flint

Quarterly product planning, or quarterly alignment, is an integral part of a responsive organization to connect OKRs with execution. Quarterly planning has become even more critical in today’s distributed environment to align teams to row in the same direction, as highlighted in the Medium post, “The Cadence,” by David Sacks, PayPal’s first COO and the founder of Yammer and Craft Ventures.

The key driver for quarterly alignment (or bi/monthly for fast-moving companies) is the evolving product focus responsive to business needs. Goals such as conversion, retention, or market expansion are almost always present for every company but vary in importance at different times. Therefore outcome-driven product operations need to adjust prioritization frameworks and associated resource plans.

Effective quarterly product planning starts with strategizing based on goals and then allocating responsively. This is critical in enabling the rest of the teams to make their prioritization decisions with this big picture context.

During quarterly product planning, product leaders and their teams align on the next phase of focus within product functions and their engineering, business, and other key stakeholders.

How Do You Perform Quarterly Product Planning/ Roadmap Alignment?

To perform quarterly product planning well, follow these 4 (+2) iterative steps:

Define key goals (you could try setting product OKRs) for the upcoming quarter and their respective resource allocation.
Brainstorm and prioritize product ideas against these goals.
Create high-level estimates / T-shirt sizes to identify resourcing needs or bottlenecks.
Break the pod to work or bring work to the pod.

Steps 2 and 3 may happen iteratively (back and forth continuously).

Then, make sure to follow these ongoing steps:

Communicate.
Check-in and adjust.

Let’s look at these steps in more detail below.

Step-by-Step Quarterly Product Planning

1. Define Your Key Goals and Metrics (OKRs) for the Coming Quarter

Smart companies change their focus from one bottleneck area to another due to the diminishing return on investment in previous areas. For example, in one quarter, you may be focusing on growing new accounts, and a few quarters later, the focus needs to move to retention because churn has started to affect overall growth. Using data from your business review is a good starting point in identifying goals for the coming quarter.

Here are the common questions to ask when setting goals:

What are the most pressing needs for the upcoming period? How should we balance the needs of new customers (sales) and existing ones (customer success)?
Which long-term goals should we not forget to start?
What are the must-have goals vs stretch goals?
How much are we willing to invest in each goal, e.g. 50%, 30%, 20%? A goal without resource allocation will not succeed.

Setting OKRs without associated allocation creates gaps between executive wishes and the team’s ability to deliver.

Once your product goals are defined, it’s time to prioritize.

2. Brainstorm, Align, and Prioritize Ideas to Goals

This is the time to pull your ideas out from “backlog storage” to planning. Prioritizing ideas can be done through multiple views and should always include the dimension of goals.

Other dimensions include product themes and investment categories. Adopting quantitive prioritization is a bespoke way for product decisions so everyone can have the context of why a certain initiative or feature is ranked higher than others. Some common product prioritization frameworks include RICE, ROI, the Eisenhower Matrix (Urgent vs. Important), and MoAR — metric over available resources, a more tangible proxy for ROI.

When prioritizing ideas, evaluate constraints such as commitments to clients to hit revenue/ reduce churn. Although it’s not generally the best practice to commit features by date, it’s a fact of life we often face. Having these ideas “out of place” in prioritization is a good learning tool for future behavior changes.

Brainstorm, Align, and Prioritize Ideas to Goals — Brainstorm, align, and prioritize ideas to goals in Dragonboat

3. Collect a High-Level Estimate to Identify Resourcing Needs or Bottlenecks

There are two sets of estimation – top-down (aka t-shirt size) and bottom-up (aka breaking down epics into stories and estimating each story and adding them up).

Bottom-up estimation is a waste of time at this stage because you will likely only move forward with a small subset of initiatives, if the planning is done right.

However, high-level estimation, in the unit of sprints or weeks is very important. Here are some key benefits:

Prevent major misalignment/ understanding between product and engineering.
Help identify resource needs (or bottlenecks) from within your team, other teams (including other scrum teams), UX teams, and marketing teams to secure support.
Allow your team to come up with a different solution to achieve the goal if it costs too many resources, takes too long, etc.

Having only part of the feature completed does not deliver value. If there is not enough support from all teams required to bring the idea to market, consider switching to a different idea that does not require bottleneck resources. Alternatively, change your product approach or find a way to complete it without engineering effort.

Use the MoAR method to further prioritize ideas competing for the same resources.

Providing estimates allows you to check your plan against your goal allocation. This is critical, but how often do we actually do it when using spreadsheets?

4. Create a High-Level Portfolio Roadmap Plan

Once you have the priority and estimate, you can put together a high-level product roadmap. It can be a good idea to create a few roadmap scenarios to compare side by side or share with stakeholders for alignment.

What if there is a resource shortage or imbalance? Then one pod (scrum team) may end up with more work and another pod will have fewer roadmap items.

Normally, business demands fluctuate for each engineering pod (one or a few scrum teams supporting a product roadmap area).

There are 3 potential solutions in this case:

Each pod prioritizes work within their area — but this does not create the best value at the portfolio level due to local optimization.
Break up the pods to meet the fluctuating demand — this works in theory but usually negatively impacts team dynamics and velocity.
Quoting a VPE friend — “Don’t break the pod to work, bring work to the pod.” The same pod may work on different areas periodically based on needs, which is a compromise between the 2 options above.

If the planning is slightly long-term, e.g 6 months or more, a high-level plan also helps prioritize hiring or tap into on-demand resource partners if appropriate.

Now you’ve completed the first 4 steps of quarterly product planning and alignment – the next 2 steps are essential to continue the portfolio cadence to monitor outcomes and adjust to changes.

The Product Portfolio Cadence – Post Quarterly Planning

Confirm and share your plan with your team so they have the context and big picture for their decision-making.

Have product operations connect your quarterly roadmap with your team execution tools, e.g. Jira, Shortcut, Asana, or Github Issues, to gain real-time visibility of progress and forecast potential issues or risks that may warrant a revision of the current plan.

While you may build intricate spreadsheets for planning, and manually pull out data for reporting, a better option is to adopt an integrated product portfolio platform like Dragonboat. It offers CPOs, product operations, and teams the context and continuity from goals and strategies to execution, to enable effective decisions for all involved in designing, building, shipping, marketing, selling, and servicing products.

quarterly product planning in dragonboat — Portfolio Summary Report in Dragonboat

Check-in monthly (or bi-weekly) to evaluate progress, urgent requests, changes in the state of execution (delay or scope increase), or losing resources for one reason or another. The adjustment often results in a new alignment/ plan following steps 2 to 4 with “what-if scenarios” in step 3, to re-align and update your roadmap, team, and stakeholders.

Quarterly Alignment is Replacing Quarterly Planning

Posted on March 18, 2019September 11, 2023 by Becky Flint

Is quarterly planning still relevant in today’s dynamic, fast-changing environment? The answer is a definitive yes, but with a twist. Quarterly planning should not occur only once a quarter, and its deliverable shouldn’t just be a list of projects. Instead, it should be an exercise of continuous alignment on a quarterly horizon.

Some may ask – why do you need a quarterly cadence? With Agile, couldn’t we just continue iterating on the product in sprints? This takes us back to the need for the three separate time horizons of strategy and execution within an organization.

Every organization needs a longer-term, mid-term, and near-term time horizon with their own goals and respective strategies. Quarterly planning focuses on connecting the longer-term vision (e.g. annual) with the mid-term focus (e.g. quarterly), which provides strategic guidance for the next level of iteration (e.g. bi-weekly). Quarterly alignment is for agile leaders to provide context for agile teams.

company quarterly alignment across three time horizons

Here are some of the common challenges for product teams lacking responsive quarterly alignment:

Disconnect – Let’s say a product or feature launched from the previous period and hit the market. The resulting business impact may or may not have been anticipated. So, the company must adjust goals and strategies subsequently. However, these strategic changes often won’t reach the team in time or with enough context, resulting in the team continuing to execute strategies from 1-2 quarters ago.
Poor allocation – Many companies adopt stable teams or a full-stack team model (think pods or tribes) without adjustment. However, as the business needs change, the previous allocation by team may not support current needs. Some teams end up under water with too many mission critical features while others may not have the same level of delivery pressure, leading them to focus on their locally optimized roadmap.
Incongruent UX – Without frequent alignment across teams and functions, silo’d decisions and prioritization happens. Dependencies are exposed. To avoid lengthy delays, teams have to create work arounds. This creates a suboptimal user experience and “products with an org structure”.

Quarterly Planning vs Quarterly Alignment

Traditional quarterly planning aims to address these challenges, but it focuses on the output of a committed list of projects. While there are merits to this deliverable, it does not fit into the fast-changing environment where the list of projects will change through the quarter.

This is why quarterly alignment emerges.

Quarterly alignment is the process of connecting the longer-term vision with sprints and activities responsively via collaboration between executives and leaders and across teams on what we want to achieve and the strategies to achieve them. The outcome is a set of initiatives (aka programs) with defined goals that empower further innovation without misalignment.

How Do You Perform Quarterly Alignment?

Here is a time-tested framework:

Define the top 2-5 goals and target metrics for the upcoming quarter. An OKR framework (Objective and Key Result) is a good way to start.
Brainstorm and prioritize product features, marketing and/or other initiatives to achieve these goals.
Identify gaps and dependencies in achievability and/ or resources (check out how to use MoAR to prioritize).
Iterate between 2 and 3 until a good enough game plan (a list of initiatives enabling your OKR’s) is in place. Learn more about the rock, pebble, and sand method.
Track both work progress and OKR progress to responsively adjust your team’s focus.

Quarterly alignment is not a “build it once and rest forever” exercise. Frequently review (on a bi-weekly or monthly basis) the current trajectory against the desired outcome, and adjust the detailed activities responsively.

Clarity and alignment are critical to the success of any company. Quarterly alignment is a valuable cadence to enable it, giving your company the opportunity to align teams and products against the goals at the OVERALL company level (see the MoAR Method). This way, your teams can innovate and move fast in the same direction.