This exercise is great for aligning teams and quantifying outcomes, but it often misses a critical step: measuring the efficacy of initiatives themselves and using that data as a feedback loop for subsequent decision making.

A standard operating model might look something like this: Leadership sets annual thematic goals. Each quarter, departments align with these themes to set target metrics and define the key initiatives that will influence each metric. For example, if an annual theme is growth, a sales team may set out to close a $10M bookings target, establishing 3 key strategies they believe will help achieve this goal. At the end of the quarter, the organization reviews the outcomes to understand how they performed. If the sales team closed $8M in bookings, they achieved 80% of their goal.

Visually, this looks something like this:

This is precisely where many organizations stop, choosing a new set of initiatives without completing the feedback loop. Disciplined teams may discuss the impact of each initiative at a high level, but rarely in a quantifiable way. Failing to look closely at the underlying drivers of each outcome presents two main issues:

1. All initiatives, no matter how they performed, are measured against a single target metric. If our sales team achieved 80% of its target, which initiatives actually drove positive results and which were detractors? Of this distribution, what was the ROI for each?

2. Without a quantifiable understanding of each initiative, the quarterly cycle restarts and the feedback loop is lost. Yes, an outcome was achieved, but we failed to internalize the most valuable data: the key drivers of each initiative that lead to the outcome.

Without comprehensive measurement, an operating model is limited to serving as a lagging indicator. It does an excellent job at telling us how we performed and a terrible job at telling us how to perform better in the future. At a human level, this sort of deep retrospection doesn’t always come naturally.

The human lens: Why do we have a blind spot for learning how to do better next time?

It’s a double whammy, actually. Most of us (unless we’ve had MUCH therapy) avoid the truth that we are imperfect. We all have an inherent bias to view ourselves as “great” because anything less feels like a threat to our status and belonging. Our brains are wired to solve for status and belonging, and one of our default strategies is self-deception.

If that weren’t enough, the vast majority of us were raised in fixed mindset systems – systems that rewarded us for having the right answer (of which there was only one). High performers who got straight As were trained to solve for the outcome, not the learning.

The challenge is that the world has changed much faster than our systems and our evolutionary biology. In a world of endless information, constant change, and vast uncertainty, we need to completely reorient our mindset. We must embrace curiosity to accept that there may be many “right” answers. It’s our job to discern which one is best for our context and take action with skeptical curiosity. We need to be focused on GETTING it right, even if that takes multiple iterations, rather than BEING right. It requires that we view ourselves as “continuous learners” as opposed to “subject-matter experts.” And that can feel like a hit to both our power and our status.

What can technology teach us about goal-oriented feedback systems?

Deep Learning is a subset of Machine Learning and AI that uses artificial neural networks to learn hierarchical representations of data — and it does this in a fascinating way.

These models use a concept called backpropagation. During training, the model makes a prediction, and this prediction is compared to a ground truth – an answer key of sorts. Given the accuracy of each prediction, the model traverses back through its layers, using backpropagation to isolate the error contribution of each layer. An optimizer then adjusts the model’s weights and biases in an effort to be “less wrong” in the future. This process is repeated millions of times until its loss score (the mathematical measure of how far predictions deviate from actual target values) reaches an acceptable minimum.

In other words, the model has a goal, it makes a prediction, and then it doesn’t simply report its performance. Instead, it methodically examines how each individual component contributed to the positive or negative outcome and adjusts its “behavior” accordingly. Each of these micro-experiments compound quickly, pushing the model towards incrementally better outcomes.

This isn’t a new concept for humans; we perform the same type of calculations on a daily basis to adjust our own behavior patterns, though often unconsciously. In Psycho-Cybernetics, published over 60 years ago, the author Dr. Maltz describes this same self-learning feedback mechanism for humans:

What does it mean to be “less wrong” from a human perspective?

What if we borrowed the goal of being incrementally “less wrong” from deep learning? If we started from the premise that there is no way to get it “right” the first time? With that framing, hitting 80% of our goal is just a data point – the metric we need to trigger the question, ‘What would we have had to do differently to get to 100%?’ (focus on learning) vs. ‘I fell short of my goal by 80% so I’ve failed - I’d better get my defenses ready as to why 80% is still good enough’ (focus on status).

If we can admit that setting an OKR is just an educated guess, then our work is just to become “less wrong” each quarter when we review key results. At its core, that’s how the OKR framework was created: ”stretch” goals were explicit guesses.

The rub comes when we tie performance reviews and compensation to results. If my bonus or raise is based on achieving a number, it’s almost impossible for my status and power-focused ego to leave any room for learning; I’m just hyper-focused on the outcome that affects me directly. While decoupling performance evaluation and goal-setting is beyond the scope of this article, I’d offer these two questions for discussion in your own organization or context: (1) Which mindsets and behaviors is our current system incentivizing? (2) How might we align our incentive system to support the shift to a learning mindset?

The Learning-Oriented Operating Model

Of course, an organization can’t be expected to trace every incremental action that leads to an outcome. Nor do we want to introduce a mountain of unnecessary administrative work. However, it can and should measure the efficacy of each initiative in detail.

Objective

Our operating model shouldn’t simply measure outcomes. It should have a deep understanding of what influenced each outcome, such that we can adjust behavior in a systematic effort to improve future outcomes.

Prerequisites

Moving from static outcomes to an operating model with a quantifiable feedback loop depends on three key prerequisites:

1. Adjusting the operating model to adopt a hierarchical structure in which each target metric has 3-5 initiatives and each initiative has 3-5 key drivers.

2. Ensuring the metrics attached to each layer are quantifiable and can be normalized to a relative percentage score.

3. Implementing systemized “lab logs” that ensure every important action or decision can be recorded and attributed back to a driver and its initiative. To reduce administrative burden, it’s recommended to rely on a combination of existing action logs (like actions taken in a CRM) and AI tools where teams can “brain dump” their decisions and findings along the way.

Since every organization is nuanced, it’s encouraged to adopt these concepts in a way that best fits your team’s structure and desired operating model.

Definitions

Our new operating model should have three key components:

1. Target Metric: A high-level goal the organization or department is trying to achieve. For example, achieving a bookings target of $10M, the deployment of a product roadmap, or improving customer retention by 10%.

2. Initiatives: The high-level, tactical activities that will move the target metric in the right direction. For example, in order to achieve a bookings target of $10M, we may need to increase our average deal size by 35% while improving lead velocity by 10%.

3. Drivers: The specific experiments we will conduct, levers we will pull, or variables we will try to influence. If our initiative is to increase the average deal size by 35%, collectively, what measurable experiments do we hypothosize will drive our desired outcomes?

While both initiatives and drivers receive a quantifiable metric, its important to distinguish that initiatives are measurable results while drivers are simply the result of our experimentation. For example, if a driver hits 133% of its target but the parent initiative fails, our conclusion should not be that our experiment succeeded but rather, that our hypothesis was wrong. The driver didn’t influence the initiative’s metric.

Let’s return to our sales team who had a $10M target and three planned initiatives. Their new quarterly hypothesis might look something like the example below. Note, we are not sales leaders and the examples below are purely illustrative.

Illustrative Quarterly Plan

Organization Theme

Growth

Target Metric

$10M Booked ARR

Initiatives

Initiative 1: Up-Market Migration → Moving from mid-market deals to larger enterprise accounts to increase average deal size by 35%.

• Driver 1A → Time to Enterprise Readiness: Implement a multi-stage certification program (shadowing, pitch certifications, and deal-desk sign-offs) to measure the average days required for an AE to independently pitch, manage, and close $100k+ ARR deals without executive shadowing, moving from 45 days to 20 days.

• Driver 1B → Multithreaded Stakeholder Rate: Require reps to map and log executive contacts during discovery, tracking the percentage of open qualified pipeline deals with at least 4 verified decision-makers/economic buyers actively logged in the CRM.

• Driver 1C → Custom PoC Conversion Rate: “PoC Evaluation Criteria” sign-off between Sales Engineering and the prospect before building, measuring the percentage of completed technical proofs-of-concept that successfully convert to formal commercial proposals.

Initiative 2: Improve Inbound Lead Velocity → Maximizing revenue output from incoming marketing-generated pipeline by 10% without increasing headcount.

• Driver 2A → Speed-to-First-Touch: Deploy automated round-robin lead routing and Slack/SMS rep notifications to measure the median time (in minutes) from an inbound form submission to a rep’s initial manual outreach or completed meeting booking. Target 20 minutes.

• Driver 2B → MQL-to-SQL Acceptance Rate: Enforce a 24-hour SLA and mandatory disposition logging in the CRM for reps to either accept or formally reject marketing-qualified leads with a structured drop-down reason, tracking the percentage of MQLs accepted into active sales sequences.

• Driver 2C → Discovery-to-Pipeline Conversion: Implement a standardized BANT/MEDDPICC qualification checklist in discovery calls to track the percentage of completed first meetings that successfully convert into formal pipeline opportunities with an agreed-upon target close date.

Initiative 3: Expanded Cross-Selling → Expanding existing customer revenue by an average of 5% through upsells, add-on modules, or seats.

• Driver 3A → Early Account Health Score: Execute a 90-day structured customer onboarding playbook (kickoff call, core integration, and initial team training) to measure the percentage of newly signed accounts reaching “Green” health status across usage, support ticket, and sentiment metrics before day 90.

• Driver 3B → Executive Touchpoint Frequency: Establish a recurring quarterly executive sponsorship program that pairs internal leadership with client counterparts, tracking the average number of completed executive-level strategic alignment syncs per account each quarter.

• Driver 3C → Product Adoption Depth: Automate targeted product-nudging campaigns and Customer Success check-ins triggered by inactivity, tracking the ratio of licensed seats active weekly (WAU/MAU) and the adoption rate of core high-value features.

The key drivers that previously sat below the surface (with low visibility but high impact) have now become the foundational anchor of our operating model. Visually, this transformation looks something like this:

As the quarter kicks off, each team executes against their initiatives, performing a series of rapid, iterative experimentation to influence each driver. By the end of the quarter, we’ll know how each metric, initiative, and driver performed – and we’ll have a detailed history of why by way of our lab logs.

The Art of Attribution

Before we can ever say with confidence which initiatives and drivers impacted our target metrics, we must first define the degree of the relationship or independence between each. This requires us to consider whether our target metric is a composite of its underlying initiatives and drivers or if each should be measured as an independent diagnostic.

The ambiguity of art and science that exists in attribution is a reason many organizations abandon (or fail to even start) this practice. It’s not always a simple, neat construct. But, working towards grounded attribution can unlock an entirely new world of understanding and operational rigor.

Composite Attribution

In composite attribution, drivers are defined such that their metrics “roll up” (via sum, weighted average, or some explicit formula) to produce their parent initiative and target metric. The target metric still receives a target or goal, but the outcome is a derivative of its underlying components rather than an external measurement (like dollars booked in sales).

This approach is particularly useful in two scenarios:

1. When initiatives and drivers are the only mechanics capable of moving the target metric. For example, in a Product & Engineering organization, if our target metric represents the delivery of a quarterly roadmap, the initiatives themselves directly roll up to achieving this target metric.

2. When our objective is to incrementally improve a target metric through experimentation. For example, if a customer enablement team is working to improve a days-to-launch metric, seeing the target metric influenced directly from ground-floor drivers can have an immediate, positive impact.

In composite attribution, organizations can also get creative with different types of weighted calculations. For example, if 2 of the product roadmap deliverables have an outsized impact on a core business metric, these can be weighted when producing the final target metric, ensuring teams were properly allocated towards the highest ROI activities.

Diagnostic Attribution

Diagnostic attribution, on the other hand, is ideal when our target metric is a grounded, core business objective with little ambiguity. For example, momentarily remove all initiatives and drivers: our target metric for sales bookings was $10M and we achieved $8M; thus, an 80% outcome. Now, our job is to evaluate the diagnostic signals of each initiative and driver to understand how each may have impacted our target metric.

In diagnostic attribution, each initiative and driver is measured on its own, against its own definition of success. Since every level is independently measured, driver metrics don’t sum to their parent initiative’s metric, and initiative percentages don’t sum to the target metric. They’re not supposed to. Drivers and initiatives in this case are diagnostic. They explain the outcome, they don’t mathematically produce it.

Since driver and initiative metrics serve as hypotheses rather than mathematical components, leaders must treat them as diagnostic signals rather than absolute proof.

These signals must be paired with qualitative evidence from lab logs, leadership experience, and other factors. During post-quarter reviews, leaders shouldn’t just look at whether a driver hit its percentage goal; they should cross-reference performance with the team’s lab logs to ask: Can we trace specific outcomes directly back to the actions taken here, or did an external tailwind do the heavy lifting?

Using diagnostic drivers in this way gives leaders directional accountability without falling into the trap of false mathematical precision. It allows teams to refine their operational hypotheses quarter after quarter, getting progressively “more right” about which levers actually move the needle.

Initial Results

Let’s look briefly at an example of what we are actually trying to extract from this exercise before diving too deeply into the calculations. Despite our attribution method, each target metric, initiative, and driver has a quantifiable outcome — whether a composite or independently measured variable. For our sales example, we’ll use diagnostic attribution.

• Target Metric: 80% ($8M of $10M Booked)

  • Initiative 1 → 115%

    • Driver 1A → 133%

    • Driver 1B → 121%

    • Driver 1C → 90%

  • Initiative 2 → 60%

    • Driver 2A → 33%

    • Driver 2B → 70%

    • Driver 2C → 95%

  • Initiative 3 → 85%

    • Driver 3A → 50%

    • Driver 3B → 90%

    • Driver 3C → 100%

The metric for our first initiative was to increase deal size by 35% and we’ve hit just over 39% – surpassing our target. Initiative 2, on the other hand, performed poorly and initial diagnostic signals point Driver 2A.

We can now begin to evaluate our bookings miss at a deep level, pinpointing what worked and what didn’t. Just as importantly, we can now put these outcomes in context. For example, we might note:

• Driver 1A performed really well, but it actually wasn’t until the latter half of the quarter that we saw the needle move. What experimentation catalyzed this shift?

• Initiative 2 was our poorest performer, dragged down primarily by Driver 2A. We’ve seen some performance issues on this team and their lab logs suggest they need retraining in a particular area of the business.

• Initiative 3 performed OK, but Driver 3A missed the mark. The lab logs are comprehensive, but we can see that the team was hung up on a particular strategy that clearly wasn’t performing well and they failed to evolve that strategy over the quarter.

Running the Numbers

Importantly, whether we use composite or diagnostic attribution, the calculations are the same. In a composite model, these calculations compute exact structural contribution. In a diagnostic model, this math serves as a normalized sensitivity score — a way to rank-order operational drag so leaders know where to best allocate diagnostic time.

There are three steps to go from statically measured outcomes to a weighted attribution of each metric, initiative, and driver. In this example calculation, we’ll speak in terms of drag (detracting from the target metric) and lift (contributing to the target metric).

First, we want to measure the positive (lift) or negative (drag) movement of each individual driver: Achieved % - 100%. For example:

• Driver 1A: 133% - 100% = +33 → Lift

• Driver 1B: 121% - 100% = +21 → Lift

• Driver 1C: 90% - 100% = -10 → Drag

Do this for each driver across all initiatives. Then, calculate the gross lift and gross drag by summing the absolute values for lift and drag separately. This gross calculation can be done per initiative or across the entire department.

• Gross Lift: 33 + 21 = 54

• Gross Drag: |-10| = 10

These gross values provide the denominator needed to calculate relative contribution at the initiative level:

• Driver 1A: 33/54 → Contributed 61% of the lift for Initiative 1.

• Driver 1B: 21/54 → Contributed 39% of the lift for Initiative 1.

• Driver 1C: 10/10 → Contributed 100% of the drag within Initiative 1.

If we apply this same concept across all initiatives in the department where Total Lift = 54 and Total Drag 172, we can evaluate cross-departmental impact. We can see that Driver 1C appears to have contributed to 5.8% of the drag across all initiatives. Or, that Driver 3A may have been responsible for 29% of drag across all initiatives, even though its parent Initiative 3 performed 85% to target.

Without this perspective, we may have simply assumed that 85% was a reasonable outcome for a stretch goal without realizing the negative impact of one individual driver may have had. Instead, we can now double-click on this driver to either better understand its direct impact (in the case of composite attribution) or use these signals to perform diagnostic attribution.

Troubleshooting

• In diagnostic attribution, variables do not necessarily have a linear influence. It’s important that leaders apply their understanding of the operational model to weigh influence accordingly.

• Do not allow lab logs to become an operational burden. Lab logs are conceptual; they represent capturing the decision making processes surrounding drivers and initiatives — they are not a prescriptive, administrative requirement.

Conclusion

Many organizations fall victim to performative measurement where the outcome is clear, but the true underlying drivers remain hidden below the surface. When measurement stops at outcomes, we are actively discarding valuable data: what led to those outcomes and how to be “less wrong” with each subsequent experiment.

Leaders can instead embrace a Learning-Oriented Operating Model to establish target metrics, initiatives, and underlying drivers – each with clear, measurable outcomes. Depending on the team and what we’re measuring, these components can provide either composite or diagnostic level attribution. Throughout the quarter, teams experiment and iterate on ways to positively impact each driver. When the quarter is over, a quick series of calculations provides leaders with a comprehensive understanding of their organization’s performance. This granular data, lab logs, and an LLM then becomes a powerful tool for leaders looking to affect change across departments.

Subscribe now

About the Authors

Erik Smith

Erik Smith is an entrepreneur, investor and builder. He serves as 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.

If you’re interested in the intersection of business, technology and operations, follow Approachable X on Substack. Erik is working with Dr. David Cochran, Dean for AI and Emerging Technologies at Newman University, on their new book, Approachable AI for Business Leaders.

Connect on LinkedIn

Jess Felts

Jess is Managing Partner at Team Level Partners, a boutique consulting firm focused on equipping leaders and teams with the human skills necessary to thrive in the era of AI. A connector at her core, Jess brings together her background as a strategy consultant, coach, and start-up leader to take an integrated approach to leadership and team effectiveness. She spent her early career in investment banking before attending the UC Berkeley Haas School of Business where she earned her MBA. She then went on to work at McKinsey, focusing on strategy and organizational consulting before shifting into the People space in the tech industry.

Often, the hardest problems in an organization aren’t technical, they’re relational: Trust that erodes under pressure. Conversations that avoid the real issue. Cross-functional friction that stalls execution. As AI reshapes how work gets done, the real differentiator is human skill: how people listen, build trust, adapt, and make high-stakes decisions together.

We’re expert facilitators, former operating leaders, and coaches with interdisciplinary backgrounds who work at the heart of how teams relate, decide, and move forward, especially when things get hard. If you’re interested in learning more about how to build the interpersonal muscles required for effective teaming and true organizational momentum, reach out to us at info@teamlevelpartners.com.

Connect on LinkedIn

The second you find product-market fit, the conversation immediately shifts to scalability. It spawns conversations of unit economics, gross margins, automations, team structures, and repeatable processes.

In the early stages of a company, it’s easy to confuse scalability with growth. Of course, growth is the objective, but it’s inextricably tethered to scalability. Growth is what we want; scalability is how we achieve it in a sustainable way.

The Complexity of Scale

To scale successfully, we need sub-linear growth across our business dimensions.

As a simple example, imagine today it takes 5 customer support representatives to manage 1,000 customers. Linear scale would mean that when we reach 2,000 customers, 10 support representatives are required.

Our goal is to decouple the ratio — to get more from less.

On paper, the objective is straightforward. Optimize inputs (x₁, x₂, x₃) to maximize the output (y). In reality, each input is dynamic and connected to dozens of other hidden inputs. On the other side of the equation, the output (y) is barely stable. It’s influenced by a range of external factors: competition, regulations, market dynamics, unit economics, etc. Some of these we can control and some we can’t; most, we can only influence to some degree.

Then, enter people: personalities, strengths, weaknesses, egos, motivations, etc. Any math we could rely on is quickly suffocated by the unpredictability of human behavior. Good and bad.

Scale is complex and difficult.

How then, do we approach such a chaotic system? By looking closely at what permeates every component of the system: knowledge.

Choosing Knowledge

Why should our journey towards scalability start with knowledge management? First, knowledge is unique in that it serves as the “connective tissue” between every component of the organization; it’s ubiquitous. Second, knowledge is emergent, fairly unstable, and constantly changing.

This is not to say that there aren’t dozens of other important aspects of scale. Rather, it’s to emphasize how knowledge can serve as a common, grounded mechanism for facilitating all other aspects of scale.

Let’s think about these dependencies in context:

1. We have a system we want to scale; in our case, an organization.

2. This system is made up of many components (departments, functions, roles, processes, etc) — each with a purpose.

3. Its purpose is achieved by having the knowledge necessary to meet its objectives.

4. The knowledge it relies on is de facto missing, aimless, stale, wrong, or otherwise difficult to control.

We start with knowledge because of its sheer influence over the system and its tendency to be unreliable when left unchecked. Our challenge becomes:

How do we give knowledge both structure and purpose, such that it can reliably serve as the connective tissue across our system, allowing us to meet our objectives?

Giving Knowledge Purpose & Structure

If knowledge is emergent, our first goal should be to direct it towards a stable structure; a place for it to reliably live, evolve, and thrive. The diagram in Figure 1 demonstrates how we might think about knowledge progressing through a set of defined structures, each with a purpose.

As we walk through each of these structures, consider their purpose from two contexts:

1. Micro: A single piece of knowledge entering the organization and how it progresses through the system.

2. Macro: The organization’s own holistic journey towards knowledge maturity and its ability to actually implement and act on these structures.

1. Fragmentation

Despite the operational maturity of an organization, when knowledge is conceived, it’s typically in a state of fragmentation.

The immediate goal is to capture that knowledge as documentation. Otherwise, we risk it being tied indefinitely to the individual(s) from which it originated, who inevitably forget things, change roles, or leave the organization.

But, this is easier said than done. In fact, it’s perhaps the most difficult step. When we begin to ask questions about incoming knowledge, the magnitude of the problem becomes clear:

• Is the knowledge relevant?

• Do we have data to back up its claims?

• Can we replicate it?

• Did it originate from a subject-matter expert?

• Does it relate to an existing process or procedure?

• Does it impact upstream or downstream processes?

• Does it conflict with existing knowledge?

• Will it remain true over time or is it tethered to mutable variables?

Rather than attempting to plan every contingency, our knowledge framework should focus on training people and enabling systems to capture, triage, and evaluate knowledge as it emerges.

In the early stages of an organization, this process can be extraordinarily simple. The process of triaging and evaluating knowledge can be distilled down to a simple question of prioritization:

• P0: What cannot go wrong?

• P1: What shouldn’t go wrong, but won’t kill us in the short term?

• P2: What can we generally ignore for now?

Insist on P0; aim for P1, and backlog P2.

In later stages and as standardization is introduced (see phase 3), the process of capturing, triaging, and evaluating emergent knowledge can become more nuanced to match the appropriate level of rigor of the organization.

2. Documentation

Right around ~20 employees, most organizations start to realize the necessity of documentation. This is largely driven by the need to repeat processes consistently, independent of the person or system actually completing the work; a key tenet of scalability.

In our previous step, we captured, triaged, and evaluated emergent knowledge. Now, our job is to ensure the knowledge is documented with a structural foundation. This is key for three reasons:

1. Most importantly, it makes the knowledge useful and that’s our primary objective.

2. Secondly, it creates a stable dependency loop for future emergent knowledge. If knowledge is well organized, we can reliably ask questions like: Does this conflict with existing knowledge? Does it affect upstream or downstream processes?

3. Finally, it prepares knowledge for standardization, which is a non-negotiable prerequisite for productization and automation.

What does this look like in practice? It can be as simple as:

A. Establish a System of Record

Find a tool and make it your home for Standard Operating Procedures (SOP). The system should be flexible, support access controls, maintain a history or audit trail, and be easily accessible by team members.

B. Enforce Basic Structures

Establish two dimensions of categorization: organizational structure and knowledge categorization. For example:

• Knowledge will be categorized based on our organizational structure which includes Departments → Functions → Processes.

• Knowledge itself will be categorized as either an Operating Procedure, Guidance, or Governance Policy.

These types of basic structures are simple, but extraordinarily powerful. Now, when capturing emergent knowledge, it’s final “home” is clear. Just as importantly, when knowledge needs to be retrieved, humans and systems have an index to reference.

For example:

• How does the Customer Success department think about customer Segmentation?

• How does the Security function enforce multi-factor authentication?

3. Standardization

So far, we’re capturing and documenting knowledge into structures that can be easily navigated. If we stopped here, we’d be in pretty good shape. But, as the organization scales, we risk the ability to maintain these structures long-term. Why? The sheer number of inputs, leadership preferences, competing priorities, and knowledge entropy.

The third phase of standardization is about unifying knowledge across all components of the business to create reliability and consistency.

It’s important not to overthink this.

Our goal should simply be that any one person or system, despite their role, can navigate our knowledge with a high degree of certainty and understanding.

We can liken this to driving in the United States. Whatever state you’re in, there are consistent standards and rules for operating a vehicle. Speed limits will vary, sometimes you can turn right on red, etc. But, for the most part, you can make it from California to Florida without issue.

How an organization chooses to standardize their knowledge will vary greatly, but considering these 5 components is a great place to start:

• Structure: Have we implemented standard structures for organizing knowledge?

• Semantics: Have we established a unified vocabulary and glossary for core terminology?

• Governance: Does each piece of knowledge establish levels of ownership, responsibility, accountability, etc? Have we established the ways in which cross-functional teams and processes interface?

• Lifecycle: Have we established methods for continuous maintenance and scheduled audits of knowledge?

• Interoperability: How is our knowledge connected to other tools and systems?

4. Productization

Productization is the process of observing our knowledge and identifying what processes are good candidates for internal tooling. Largely, this is about enabling strong relationships between function stakeholders and product managers. Together, these teams can routinely propose process candidates that are stable and ready for productization.

Why is this important? It ensures that as knowledge and processes mature, the associated work (output) is filtered back to our objective of scalability. The process itself is likely still assigned to a particular role, but the operational steps have been greatly simplified. Our goal wasn’t to build a library of knowledge, but rather, to transform that knowledge into scalable operational machinery.

There’s a major risk to productization that is often overlooked. When knowledge is transferred from written form to logic/code, it risks being obfuscated for the larger organization. Suddenly, what was known by all is relegated to a small group of engineers. To avoid this trap, organizations must establish clear parity between knowledge and product documentation, ensuring the what is productized but the how remains clear.

5. Automation

The transition from productization to automation is subtle. It’s the process of further reducing the work associated with an already productized process. Let’s examine this in context.

Early on, a team member may have been responsible for collecting data, creating a report, and adjusting operational variables to reflect their findings.

When this process was productized, we eliminated the first two steps entirely. The data and final report were made available to the team member in real time, eliminating the majority of their manual work. Still, they were responsible for interpreting and adjusting the operational variables.

By automating this final step, we can further reduce the manual work. For example, we may implement machine learning to automatically adjust the operational variables. Or, at the very least, present the team member with the proposed adjustments and rationale behind each.

In Summary

Scaling an organization is extraordinarily difficult. There are infinite, dynamic, interacting inputs contributing to and detracting from our goal of scalability. The single thread between all of these inputs is knowledge. Giving knowledge purpose and structure is an excellent way to stabilize these inputs and guide them towards operational scalability.

About the Author

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.

Notice: This list was curated through discussions with AI models. It’s for reference purposes only.

General Strategy & Targeting

• Value Proposition: The core statement explaining exactly what problem your product solves, how it benefits the customer, and why you are better than the alternatives.

• Ideal Customer Profile (ICP): A detailed description of the perfect company that gets maximum value from your product and provides maximum value to your business.

• TAM / SAM / SOM: A framework measuring your total market size: everyone who could theoretically buy (TAM), the portion your business model can actually reach (SAM), and your realistic short-term target audience (SOM).

Marketing & Demand Generation

• Channels: The specific pathways, platforms, or networks (like Google Ads, LinkedIn, or events) you use to reach and communicate with your audience.

• Campaigns: Focused, time-bound marketing initiatives designed to drive a specific action or outcome from a targeted audience.

• Inbound Motion: A strategy focused on pulling customers in naturally by creating valuable content, SEO, and tools that draw them to your website.

• Outbound Motion: A strategy where you actively push outward to reach specific prospective customers via cold email, direct mail, or phone calls.

• Product-Led Growth (PLG) Motion: A go-to-market strategy where product usage—through self-serve onboarding, built-in viral loops, or collaboration—is the primary driver of customer acquisition, retention, and expansion.

• Campaign Feedback Loop: The process of analyzing marketing campaign performance data to optimize ad spend, messaging, and creative choices.

• ICP Feedback Loop: The continuous cycle of updating your ideal customer definition based on which types of buyers achieve ideal activation and other product-level metrics.

Sales Pipeline & Qualification

• Prospecting: The active process of searching for, identifying, and reaching out to potential new buyers to start a sales conversation.

• Qualified Prospects: Potential buyers who have been verified to match your basic ICP criteria and have a high likelihood of needing your solution.

• MQL (Marketing Qualified Lead): A prospect who has engaged with marketing content enough to indicate interest, signaling they are ready for sales outreach.

• SQL (Sales Qualified Lead): A lead vetted by sales and confirmed to have a genuine business fit, an active need, and an interest in talking.

• SAL (Sales Accepted Lead): A prospective deal officially accepted into the sales pipeline after an initial conversation confirms budget, authority, need, and timeline.

• PQL (Product Qualified Lead): A user of a free trial or freemium product who performs key actions inside the software that signal they are ready to upgrade.

• Pipeline: The visual tracking system that shows exactly where every active sales deal sits in your sales process from discovery to close.

• Pipeline Coverage Ratio: The ratio of active pipeline value compared to your sales quota, showing how much safety buffer you have to hit your revenue targets.

• Sales Cycle Length: The average number of days it takes for a prospect to move from their first sales conversation to a finalized contract.

• Win Rate (Close Rate): The percentage of qualified sales opportunities that successfully convert into paying customers.

• Lead Velocity Rate (LVR): The month-over-month growth rate of qualified leads, serving as a leading indicator of future revenue growth.

Product & Customer Success

• Visitor-to-Signup Rate (VSR): The percentage of website visitors who convert into registered users or trial signups.

• Activation: The specific moment or milestone when a new user experiences the core value of your product for the first time.

• Activation Rate: The percentage of total signups who successfully complete the onboarding milestone required to reach activation.

• Time-to-Value (TTV): The amount of time it takes for a customer to move from signing a contract to realizing actual, measurable value from your software.

• Feature Adoption Rate: The percentage of active users engaging with a specific feature, measuring whether shipped code drives actual value.

• DAU/MAU Ratio (Stickiness): The proportion of monthly users who log in daily, indicating how essential the product is to daily routines.

• Free-to-Paid Conversion Rate: The percentage of freemium or trial users who transition to a paid subscription.

• Net New ARR: Additional recurring revenue generated from existing customers through feature upgrades, seat additions, or cross-sells.

• Churn Rate: The percentage of your customer base or revenue that cancels their subscriptions over a specific period.

Unit Economics & Unit Efficiency

• Customer Acquisition Cost (CAC): The total amount of sales and marketing spend required to acquire a single new paying customer.

• Average Revenue per User (ARPU): The average amount of revenue generated per customer over a specific month or year.

• Customer Lifetime Value (CLV): The total net profit or revenue a business expects to earn from a single customer relationship over its entire duration.

• CLV:CAC: An efficiency metric comparing a customer’s total value to the cost of acquiring them, used to gauge long-term marketing ROI.

• Payback Period: The number of months it takes for a customer to generate enough revenue to fully pay back their initial acquisition cost (CAC).

• Net Dollar Retention (NDR): The percentage of recurring revenue retained from existing customers over time, factoring in churn, downgrades, and expansion.

• SaaS Quick Ratio: A metric that measures a company’s growth efficiency by comparing new recurring revenue gains against recurring revenue lost to churn.

Bonus: Corporate Finance & Accounting

• ARR (Annual Recurring Revenue): Your predictable, recurring subscription revenue normalized to an annual basis, usually calculated from the trailing quarter.

• Gross Revenue (The “Top Line”): The total amount of money brought in from all sales before deducting any costs, discounts, or refunds.

• COGS (Cost of Goods Sold): The direct, variable costs required to host and deliver your software, such as cloud infrastructure and customer support.

• Gross Profit: Total Gross Revenue minus your direct COGS, showing what money is left to fund operations.

• Gross Margin: Gross Profit expressed as a percentage of revenue ($Gross\ Profit / Revenue$), tracking how much profit remains after delivering the software.

• OPEX (Operating Expenses): The day-to-day fixed costs of running the company, including payroll for R&D, sales and marketing, and administrative tools.

• Burn Rate & Runway: The net amount of cash a company spends monthly (burn rate) and the remaining months of operation before capital is exhausted (runway).

• EBITDA: Earnings before interest, taxes, depreciation, and amortization; it represents the raw cash profitability of your core business operations.

• Interest, Taxes, Depreciation & Amortization: Non-operating accounting expenses representing debt service, government taxes, and the asset devaluation of equipment over time.

• Net Profit (The “Bottom Line”): The ultimate remaining profit left for shareholders or reinvestment after absolutely all operating and non-operating expenses have been paid.

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