The Moscow Method

I’ve never seen an empty backlog. Every product team is overflowing with ideas and possibilities, and it’s up to the product manager to determine which is worthy of a pull request. Prioritization is essential for selecting what activities will be best for the product, customers, and the business.

Yet, prioritization can be crippling if performed haphazardly. Methodical thinking ensures that prioritization is objective, transparent, and rational, and thankfully, several frameworks exist to support this process.

The Moscow Method

A simple framework is the Moscow Method—stylized MoSCoW—a four-tier categorization that’s easy to understand, mitigates risk, and can swiftly align stakeholders. While more sophisticated frameworks can better serve specific use cases, MoSCoW is the most versatile starting point.

The funky name is a glorified acronym for its four prioritization tiers: Must, Could, Should, and Would.

Moscow’s simplicity is both its biggest strength and greatest setback. While flexible and intuitive, it can generate too many high priorities and harbor bias if mismanaged. That said, Moscow’s benefits far outweigh its issues when understood for what it is. Moscow is an axe, not a scalpel.

When confronted with a disordered backlog or meandering list of requirements, you’d do right with Moscow. On the epic level, you can use Moscow to prioritize a list of projects, high-level product capabilities, and primary features. On the story level, Moscow can help you order a list of specific requirements and acceptance criteria.

Step 1: Define

To make Moscow effective, your team and stakeholders must get translucently clear on definitions.

Must = If not done, the product is a failure

These are mandatory and non-negotiable. Common examples include core product capabilities, such as mitigating security vulnerabilities. To determine if something is a Must, ask: Will the product work without this? You might get different answers from different stakeholders, so here’s a follow-up question: Is there a simpler way to accomplish this?

Should = Important but less urgent

The feature may have a stop-gap solution, although its completion would add significant value. Common examples include performance improvements, minor bug fixes, and new functionality. Every Should ought to have a clear metric attached so the value is objective. Ask: What quantified value does this create?

Could = Desirable but not necessary

The feature may have a slight negative impact if not done, but won’t leave much value on the table either. Only include these if time and resources permit. Common examples include user experience improvements and features that improve customer satisfaction, like dashboarding. Ask: Does this impact the core offering?

Would = not a priority

You would do it if you had unlimited time and resources, but since that’s never the case, you won’t be doing these features. Avoiding Woulds prevents scope creep. Ask: Could we justify doing this in the next six months?

Document these definitions where all your stakeholders can refer to them. Use simple terms relevant to your product. i.e., Must = XYZ cannot function without it.

Step 2: Triangulate

With your terms articulated, approach various stakeholders with your backlog. I recommend doing smaller reviews with each functional team separately to keep the discussions focused and the context consistent. At a minimum, meet with three groups:

1. Technical: The scientists and engineers who will research and develop.
2. Market-Facing: The salespeople and client success managers who will sell and support.
3. Business: The other product managers and leaders who will assess other product initiatives and the company’s broader strategy.

Walk each group through the backlog and rate each item. Then, triangulate ratings across the groups to create a unified rating. Triangulation is difficult because you must balance operational items, short-term business needs, and long-term strategic moves. Engineering may want to clear a tech debt that reduces pager noise. Sales may wish for a specific feature to close an upcoming deal. Product may want a capability that will strategically drive the adoption of a new offering.

Weigh these needs against each other to arrive at a unified list. There are many philosophies on how to weigh competing needs, but use your judgment for the first pass. Again, think axe, not scalpel.

Step 3: Stack

Once you have a rated list, refine it to craft the appropriate distribution of each category. Ideally, stack your list into a pyramid structure.

In a list of twenty items:

• 1-2 can be Must
• 3-5 can be Should
• 5-10 can be Could
• Any remaining items can be Would

The team cannot understand what’s most critical for success if there are more than 1 or 2 items marked “Must.” If you have more than three, get recursive and rank the first-round Musts using Moscow. Which is the most Must of the Musts?

From here, the pyramid can build itself.

Once you stacked your pyramid, socialize the backlog with your stakeholders to set expectations for upcoming deliverables. Even if folks aren’t happy with the result, they’ll appreciate the clarity you created.