1. How many end-users or customers will be reached?

2. What tangible impact will it have on the business?

3. How confident are we in our ability to achieve the objective — including our confidence in reach and impact?

4. How much effort (time, cost, resources, etc) will be required?

Standard Calculation

Collectively, reach and impact tell us the candidate’s “magnitude”, reduced appropriately by a confidence score. The product of these three values is then divided by the effort. The higher the score, the higher the priority.

• Reach is simply the actual number of users or customers impacted; for example, 2,000 users.

• Impact is calculated as Minimal Impact (0.25), Low Impact (0.5), Medium Impact (1), High Impact (2), and Massive Impact (3).

• Confidence is calculated as Low (0.5), Medium (0.8), and High (1).

• Effort is calculated as A Few Weeks (0.5), One Month (1), Two Months (2)

These variables can be tweaked to match how you already measure priorities. For example, converting effort-based “t-shirt sizes” to numerical values that can be applied to the formula.

Example

Imagine you’re planning a product roadmap that introduces a new paid feature to a subset of customers. It has the potential for a high business impact (like increased ARR), our confidence is mid-tier, and the effort is one month of engineering time.

The final priority score for this candidate looks like this:

Even though the output isn’t neatly confined to something like a percentage score, since every candidate in the decision pool shares the same context, the value merely serves as means for comparison.

Weighted Calculation

But, prioritization isn’t always this straight-forward. Often, we need to give more credence to particular factors based on more nuanced business dynamics. For example, if we have a surplus of engineering availability and are concerned with hitting a quarterly revenue goal, we may choose to give less weight to effort and more to impact. In this case, we’re saying: it’s fine if the effort is outsized as long as we can meet the expected impact.

Skipping the Math

The steps below get into the details of calculating weighted priorities. If you prefer to skip directly to the output, we’ve prepared a Google Sheet template.

Open Google Sheet Template

Normalization

To do this, we must first normalize the values across the entirety of our roadmap candidates. This ensures that a variable like reach (an absolute number of users) can be fairly compared against a variable like confidence, which sits between 0 and 1.

We can accomplish this using a strategy like max-ratio normalization:

For example:

For each factor, divide by the maximum value in your candidate pool (or the top of your defined scale, whichever you standardize on). This process is completed across all values for all candidates until we have a neat pile of normalized values.

The values from our example might look like this:

• R → 0.40

• I → 0.66

• C → 1.00

• E → 0.50

Establish & Apply Weights

Now that all of the variables are “speaking the same language”, we can devise an alternative RICE formula that will consider the importance of these four factors independently.

We scale weights by 4 in the exponents so that equal weights (0.25 each) recover the standard RICE formula exactly.

For example, let’s imagine we assign the following weights:

• W_R → 0.4

• W_I → 0.4

• W_C → 0.1

• W_E → 0.1

Example

Of course, this is just a single candidate. Running each candidate through the same set of weights will provide us with a clear picture of our priorities against the wider lens of the organization’s needs.

Pick one weight scheme, score every candidate, and rank them. Don't compare absolute scores across different weight vectors.

In our current weight schema, we assigned outsized importance to reach and impact, with less emphasis on confidence and effort. We’re out to make a big impact; we’re risk-on and ready to use resources to achieve it.

Candidate A

• Reach: 2,000 → 0.40

• Impact: 2 → 0.66

• Confidence: 0.8 → 1.00

• Effort: 1 → 0.50

Candidate B

• Reach: 5,000 → 1.00

• Impact: 0.25 → 0.08

• Confidence: 0.8 → 1.00

• Effort: 0.5 → 0.25

Candidate C

• Reach: 2,500 → 0.50

• Impact: 0.5 → 0.17

• Confidence: 0.5 → 0.63

• Effort: 2 → 1.00

Candidate D

• Reach: 500 → 0.10

• Impact: 3 → 1.00

• Confidence: 0.5 → 0.63

• Effort: 1 → 0.5

As a sanity check, we can return to the importance we’ve assigned reach and impact and for a moment and ignore everything else. This is purely illustrative; it shows the influence of our weight schema:

• Candidate A: Reach x Impact ≈ 0.26

• Candidate B: Reach x Impact ≈ 0.08

• Candidate C: Reach x Impact ≈ 0.09

• Candidate D: Reach x Impact ≈ 0.10

Conclusion

Prioritization isn’t one-dimensional. It should reflect your organization’s current goals, timelines, resources, and risk tolerance. RICE, considering reach, impact, confidence, and effort is a great way to quantify these variables into a single, comparable priority metric.

Try This: The next time you’re making trade-offs, consider what prioritization dimensions you care about the most and apply a RICE-like concept to ensure well-rounded, data-driven decisions.

Attribution

The RICE framework was created and popularized at Intercom by Product Manager Sean McBride.

Author

Erik Smith

Erik Smith is an entrepreneur, investor and builder. He serves as the Chief Technology Officer at Rx Redefined, a venture-backed Series B healthcare technology company. His work centers on supporting leaders and teams across Product, Engineering, Data, AI, Business Intelligence, Security & Compliance, and IT/Infrastructure functions. He has a passion for helping to bridge the “curiosity gap” between technology, business, and operations. Erik lives in Northern California with his wife and two bunnies, Poppy and Bubbles.

Connect on LinkedIn

1. Inefficient processes have a compounding, negative impact on downstream workflows.

2. Building small, internal tools leveraging the speed of AI-driven development is now extraordinarily efficient.

3. AI systems always magnify output – good or bad.

AI Magnifies Indiscriminately

Intuitively, leaders often consider broken processes as low-hanging fruit for AI adoption. In reality, this approach can compound the problem. When workflows are poorly understood, data sources are disconnected, or employees are not well trained, introducing AI merely exacerbates existing chaos. Instead, constructing simple, methodical software substrates around these processes ensure they have a strong foundation before AI automation is considered.

Share

Example: Disparate Data Modeling

Let’s imagine an organization with inconsistent modeling and forecasting practices – a common, big-picture problem. Generally, departments have agreed on a few key drivers, but ultimately each maintains their own series of manual spreadsheets populated by disparate sources of data. Finance forecasts revenue, Operations maps workflow capacities, and People performs headcount planning. Each of these modeling processes spawn dozens of inefficient secondary processes, catalyzed by inefficiencies of the first. This is our flywheel – but it’s moving in the wrong direction.

1. Stale Data: Each model’s key drivers (closed deals, average revenue per account, etc) are stale as soon as they’re imported into the model.

2. Misaligned Definitions: Each department defines model variables slightly differently, conflicting with other departments.

3. No Single Source of Truth: Models are isolated from each other and thus, unable to share a single source of truth.

Connecting these spreadsheets to an AI tool will only serve to magnify existing problems and further confuse teams. Instead, the business can first invest in standardizing these models into a structured software system – either building a solution in-house or procuring a solution like Looker or Power BI. This transition has an immediate and lasting impact — moving a neglected process to one that can stand on its own. Only then, can AI automations be considered a viable option.

Basic Framework

Conceptually, flywheel tooling looks something like this:

1. Discover: Identify broken or neglected processes throughout the organization.

2. Isolate the Root Cause: Drill down past the symptoms to isolate the real reason the process is broken or neglected.

3. Define the Objective: What are we trying to accomplish? Does it address the root cause? How will we measure success?

4. Build or Integrate: Where appropriate, build or integrate lightweight software solutions around the process and its data.

5. Refine & Evolve: Using this new foundation, evolve and refine workflows to meet quality expectations.

6. Automate: Only once these workflows have matured, consider it a candidate for AI automation.

Hidden Benefits

Implementing flywheel tooling has several key benefits outside of general process improvements:

1. It forces leaders to face neglected processes head-on. Understanding processes is important; understanding what processes are broken is imperative.

2. It channels the power and velocity of AI-driven software development towards meaningful, impactful solutions that align with the organization’s larger objectives. Without this, engineers can fall victim to the “building because we can” mentality.

3. It provides subject-matter experts, who may otherwise not have the opportunity, to contribute to new, innovative solutions. This can shift the morale from change fatigue to ownership and excitement.

4. These types of small, internal software structures can usually be built by pairing an engineer and a SME without distracting from bigger-picture product roadmaps.

Avoiding the “Build Because We Can” Mentality

While flywheel tooling can be a powerful concept, it also requires operational discipline. As the speed of development has increased, so has the “build because we can” mentality – from both technical and non-technical teams. Many organizations have handed out tools like Claude Code with little discretion, creating a massive backlog of software that is fragile, not well-understood, and riddled with security concerns. Without careful planning, this software is primed to be the “dusty corners” of tomorrow.

In Summary

• The “dusty corners” of your organization are not ready for AI automation. This approach will only magnify their weaknesses.

• Instead, work with your technology team to leverage the velocity of AI-driven development to help address these neglected processes, first getting them in working order.

• Only when the process is stable should it be considered a candidate for AI automation.

• Use this cycle of flywheel tooling to help align the velocity of AI-driven development to your organization’s core objectives. Foster innovation in the right direction.

We’ll discuss Flywheel Tooling at length in an upcoming title, APPROACHABLE AI FOR BUSINESS LEADERS.

Join the Conversation

• Subscribe and let us know what topics you’re interested in exploring.

• We love to collaborate directly with business leaders, helping readers bridge the gap between technology and the realities of daily operations.

Subscribe now