Why Every Company Needs a Value Architecture

Why Every Company Needs a Value Architecture

Many companies face a value gap, which occurs when employees don't clearly understand how their actions drive the company's value. As a result, teams struggle to connect their efforts to business outcomes, leading to missed opportunities and inefficiencies.

There are a few consequences of the value gap:

  • Employees don't understand how to translate data into action. For example, imagine a room full of executives staring at a dashboard of lagging business KPIs without any idea of how they can influence them. They think, "Revenue is flat, but what can I do about that?"
  • Employees can’t connect their work to their company's business model or long-term strategy. For example, a UX designer may optimize a customer journey without understanding why it matters to their business.
  • Employees don't understand how their customers’ businesses function. For example, a salesperson may deliver a pitch and attempt a solution without first understanding the prospect's objectives.

The value gap cripples companies: GTM teams don’t effectively position their product, product teams don’t prioritize the highest leverage features, and executives struggle to make the right investment decisions. The value gap hurts on a personal level - when we can't see why our work matters, morale suffers.

Value architecture is the way to bridge the gap (shout out to Marchelle Varamini for this language!).

The Value Architecture for a company is a model (or set of models) that connects actions to value.

While value architecture can be approached from a variety of angles, I've concluded that the three sub-models ensure a comprehensive value architecture:

  1. Value delivery: A model of the company's customer success drivers.
  2. Value capture: A model that describes how the company converts customer value to monetary value for the business; i.e., their business model.
  3. Long-term competitive advantage: A model that describes the multiplying power of the company's flywheel or moat.

Let's make this concrete with a real example.

Sachin Agarwal invited me to present at Google Cloud's internal PLG summit. For my presentation, I created an outside-in value architecture for Firebase, Google Cloud's app development product. The value architecture was created using DoubleLoop's AI business mapping tools based only on publicly available information.

Value capture model

Creating a business KPI tree that describes the company’s business model is the perfect first foothold in developing a value architecture.

It might sound counter-intuitive that I start by creating the value capture model before the value delivery model. The reason why is that the way an established company currently makes money is mathematical and objective. While there are some interesting choices in building out the branches of the value capture model, the process feels like visualizing a set of facts about the business. In comparison, value delivery models can be fuzzier, subjective, and aspirational.

Here's the outside-in value capture model I generated for Firebase in the form of a KPI tree:

View the KPI tree in DoubleLoop (populated with dummy data)

The model is an algebraic KPI tree where each node is a metric that can be quantified with time series data. The tree is "algebraic" because you can derive each parent from its children with an algebraic equation. For example, the root metric "Total revenue contribution from Firebase" can be derived from multiplying its children, "Paying Firebase Developers" and "Revenue per Paid Firebase Developer."

Each KPI gets more granular and actionable as you move down the tree. While the total number of Paying Firebase Developers may be difficult for any one team to influence, its component KPI, "% of No-Cost Firebase Developers who Hit Free Tier Limits" is more controllable.

The beauty of an algebraic KPI tree is that the team can feel confident in metric relationships. When one variable moves, revenue will move with it if all other variables stay constant.

For those of you who want to roll up your sleeves, here is the full business KPI tree I developed for Firebase, complete with equations (click to expand):

Detailed Firebase KPI tree with equations

Total Revenue Contribution from Firebase (Total Revenue Contribution = Paying Firebase Developers x Revenue per Paid Firebase Developer)

  • Paying Firebase Developers (Paying Firebase Developers = New Paying Firebase Developers + Returning Paying Firebase Developers)
    • New Paying Firebase Developers (No-Cost Firebase Users x Conversion Rate from No-Cost to Paying Firebase Developer)
      • No-Cost Firebase Users
      • Conversion Rate from No-Cost to Paying Firebase Developer (Conversion Rate = % of No-Cost Firebase Developers who Built First Project x % of No-Cost Firebase Developers who Hit Free Tier Limits x % of Firebase Developers who Upgrade After Hitting Free Tier Limits)
        • % of No-Cost Firebase Developers who Built First Project
        • % of No-Cost Firebase Developers who Hit Free Tier Limits
        • % of Firebase Developers who Upgrade After Hitting Free Tier Limits
    • Returning Paying Firebase Developers
      • Retention Rate for Paying Firebase Developers (Retention Rate = Returning Paying Firebase Developers / Total Paying Firebase Developers)
  • Revenue per Paid Firebase Developer (Revenue per Paid Firebase Developer = Direct Firebase Revenue per Developer + Indirect GCP Revenue per Firebase Developer)
    • Direct Firebase Revenue per Developer (Direct Firebase Revenue per Developer = Firebase Services Revenue per Developer + Real-time Database Usage Revenue per Developer)
      • Firebase Services Revenue per Developer (Firebase Services Revenue per Developer = Firestore Revenue per Developer + App Hosting Revenue per Developer + Cloud Functions Revenue per Developer + Other Firebase Services Revenue per Developer)
        • Firestore Revenue per Developer
        • App Hosting Revenue per Developer
        • Cloud Functions Revenue per Developer
        • Other Firebase Services Revenue per Developer
      • Real-time Database Usage Revenue per Developer (Real-time Database Usage Revenue per Developer = Real-time Database Usage Revenue per Developer (Initial) + Real-time Database Usage Revenue per Developer (Expanded))
        • Real-time Database Usage Revenue per Developer (Initial)
        • Real-time Database Usage Revenue per Developer (Expanded)
    • Indirect GCP Revenue per Firebase Developer (Indirect GCP Revenue per Firebase Developer = GCP Services Revenue per Developer + GCP Infrastructure Revenue per Developer)
      • GCP Services Revenue per Developer (GCP Services Revenue per Developer = GCP Services Revenue per Developer (Initial) + GCP Services Revenue per Developer (Expanded))
        • GCP Services Revenue per Developer (Initial)
        • GCP Services Revenue per Developer (Expanded)
      • GCP Infrastructure Revenue per Developer (GCP Infrastructure Revenue per Developer = GCP Infrastructure Revenue per Developer (Initial) + GCP Infrastructure Revenue per Developer (Expanded))
        • GCP Infrastructure Revenue per Developer (Initial)
        • GCP Infrastructure Revenue per Developer (Expanded)

Long-term competitive advantage model

The primary limitation of the value capture model is that it emphasizes short-term revenue optimization over strategies for long-term growth. While the KPI tree addresses revenue today, the flywheel model illustrates how Firebase’s strategy compounds for future growth.

So the next model I generated for Firebase is a flywheel of how they can create a sustained, multiplying competitive advantage. The model leverages the principles of 7 Powers by Hamilton Helmer.

View the flywheel in DoubleLoop (populated with dummy data)

If a team were to rely solely on the algebraic business KPI tree from earlier, they would neglect to double down on what makes Firebase a unique asset for the long-term growth of Google Cloud. For example, based on the business KPI tree alone, the reason to grow the free developer base would be solely to fill out the funnel for conversion to paid users. In contrast, the flywheel model indicates how the ecosystem of free developers is not just for top-of-funnel: it yields third-party tools, community support, and tutorials, which build the value of the platform, making it easier for Google Cloud to attract new developers and retain existing ones.

Value Delivery Model

Together, the flywheel and KPI tree models are powerful. But they are both limited in that they are inward-looking. They describe how Firebase creates value for Google Cloud, not how Firebase creates value for their end users.

So, I generated a third model of customer success drivers:

View the customer success drivers in DoubleLoop

The value delivery model shows how Firebase drives KPIs that the customer cares about, like app speed and retention, while other other important KPIs like "New user acquisition" are a bit further outside the scope of influence.

A model of customer success drivers aligns GTM and product teams on (1) their customer's objectives and (2) how the product influences (or doesn't) various success drivers.

A company might need separate models for different customer profiles. For enterprise sales-driven companies, a custom model could be created for each customer or prospect. DoubleLooop's AI quickly customize models to specific customer needs or strategies.

While value delivery models are powerful for internal alignment, they can also be used as artifacts in the sales process to drive conversions. At DoubleLoop, we’re developing value models that B2B companies use in their sales motions. During the sales process, you can align with your prospect on the value architecture, an evolution of how business cases are developed.

Post-sale, your value architecture can become a customer success dashboard to demonstrate the value that your product has created for the customer.

Synthesizing all three sub-models with AI

In a pre-AI world, it would have been crazy to ask a team to consider three separate models when making strategic decisions based on the time and energy required. But with AI, we can quickly analyze the projected impact on key metrics of potential bets across all three models to create a holistic picture.

To illustrate, I ran Firebase's serverless web hosting launch through all three models in DoubleLoop to generate a hypothesis for the launch:

Hypothesis: The Firebase app hosting launch will contribute to Firebase’s success across three critical dimensions: its revenue model, its long-term competitive advantage, and the value it creates for customers.

  • Revenue Model: This launch is expected to increase revenue per developer, both through direct Firebase services like app hosting and indirectly via GCP infrastructure usage. By offering an integrated hosting solution, Firebase will capture additional revenue streams from developers who now rely on Firebase for an even greater part of their app stack. This includes both initial revenue from developers using the platform and expanded revenue as developers scale their usage of Firebase services over time.
  • Competitive Advantage: The launch strengthens Firebase’s long-term competitive position through a combination of network effects, switching costs, and brand leverage. As more developers adopt Firebase's app hosting, the platform becomes more valuable, attracting more third-party integrations and community support, thus enhancing network effects. The more deeply developers integrate Firebase into their apps, the harder it becomes to switch to competing platforms like AWS, raising switching costs. Finally, Google's brand trust boosts adoption by providing a powerful signal of reliability, security, and scalability, making Firebase a more compelling choice for developers.
  • Customer Value Creation: From a customer perspective, app hosting directly impacts developer productivity and cost efficiency. By reducing the need for developers to manage their hosting infrastructure, Firebase enables faster deployments, fewer errors, and reduced costs per app deployment. Developers can focus more on building their applications, leading to faster time-to-market and improved app performance. As developers experience these benefits, their usage of Firebase deepens, leading to higher satisfaction and continued engagement with the platform.

The combination of value architecture and AI up-levels the strategic analysis and communication abilities of all employees. While the top people at companies might already be strong in these areas, the value architecture codifies their knowledge so that it’s at everyone’s fingertips when ideating new bets, prioritizing, forming hypotheses, or assessing impact.

Putting the Value Architecture into action

While I’ve described an outside-in view on the strategic importance of Firebase's app hosting the launch, there’s a separate question of whether the launch was successful in meeting those objectives.

So at DoubleLoop, we help companies test their models with data and operationalize them in their regular planning cycles. Here's what the full process looks like:

When a value architecture is populated with data, teams uncover flawed assumptions and identify the highest-leverage input metrics to focus on. As you feed more data and insights into the value architecture, it gets smarter. The result is that your teams stay focused on projects that move the business forward and kill less impactful tracks of work.

With continual iteration, a company's value architecture becomes its most valuable asset. It is an organizational memory that outlives individual employees.


With DoubleLoop's AI business mapping tools, we can generate value architectures for companies more efficiently than typical consultants. To discuss generating a value architecture for your company, schedule a discovery session.