A Financial Model Is a Strategy Test, Not Just a Forecast

I was reading a book about organizational culture when I unexpectedly found one of the clearest frameworks I have seen for evaluating a financial model.

In Chapter 11 of Tribal Leadership, Dave Logan, John King, and Halee Fischer-Wright describe a strategy through five connected components: Values. Noble cause. Outcomes. Assets. Behaviors.

The chapter then asks three simple yes-or-no questions: do we have enough assets to achieve the outcomes, do we have enough assets to perform the proposed behaviors, and will those behaviors actually produce the outcomes?

The framework was written for leaders building organizational strategy. But while reading it, I kept thinking that financial analysts should carry these questions into every model, project evaluation, and executive presentation.

Because a financial model is not only a forecast. It is also a test of whether resources, actions, and expected results are logically connected.

Three different conversations

One of the most useful ideas in the chapter is that outcomes, assets, and behaviors should be discussed separately. The outcome conversation asks what do we want. The asset conversation asks what do we currently have. The behavior conversation asks what will we do.

This separation may sound obvious, but many planning processes mix all three. A discussion may begin with a revenue target, jump immediately to hiring, move to budget limitations, return to product ideas, and end with a list of tasks. Everyone leaves with notes, but the actual strategy remains unclear.

Financial models can make the same mistake. We can become so focused on formulas, assumptions, and scenarios that we fail to distinguish among the result the business wants, the resources it possesses, and the actions management plans to take. The spreadsheet may be technically correct while the strategy underneath it remains incomplete.

A practical example

Imagine that a SaaS company wants to generate $3 million in annual recurring revenue from a new product within two years. That is the intended outcome.

The company's assets might include:

• An existing customer base
• A recognized brand
• Product-development capacity
• Historical customer data
• Available cash
• A sales team
• Relationships with channel partners

The proposed behaviors might include:

• Building the product
• Hiring two additional salespeople
• Launching a marketing campaign
• Offering the product to existing customers
• Improving onboarding
• Creating a partner-sales program

At this point, the three questions become extremely useful.

1. Do we have enough assets to achieve the outcome?

The company may have a loyal customer base and a strong brand, but does it have enough product capacity, distribution reach, time, and capital to support a $3 million target? This question tests whether the intended result is realistic relative to the company's current position.

It also expands the meaning of an asset. Assets are not limited to cash, equipment, or headcount. They can include data quality, employee knowledge, customer trust, organizational credibility, internal relationships, and access to decision-makers. A project may be affordable and still lack the operational knowledge or stakeholder support needed to succeed.

2. Do we have enough assets to perform the proposed behaviors?

This is a different question. A company might possess enough market potential to make the outcome possible but still lack the capacity to execute the plan. Can the product team build the product within the required timeline? Can the sales organization absorb two new hires? Is the customer data reliable enough to identify likely buyers? Does the company have enough implementation capacity if demand arrives?

The first question tests whether the destination is possible. The second tests whether the proposed journey is executable.

3. Will the behaviors actually produce the outcome?

This may be the most important question of all. Hiring salespeople is an activity. Increasing marketing spend is an activity. Launching a new product is an activity. None of those automatically produces revenue.

Businesses often model activities as though they were outcomes. A financial analyst should test the causal bridge between them:

Activity → Operational change → Customer response → Financial result

For the SaaS example, the model should show how the planned activities translate into qualified leads, conversion rates, pricing, customer counts, retention, expansion, and ultimately recurring revenue.

The first two questions test capacity. The third tests causality.

When the answer is no

Another idea I appreciated in the chapter is that a "no" does not automatically mean abandoning the strategy. It may mean that the organization needs an interim outcome.

Suppose the company cannot build a reliable customer-lifetime-value model because billing, product usage, and churn data are not connected. The analyst should not manufacture a precise-looking model from unreliable inputs. The interim outcome should be to build the missing data infrastructure. Once that asset exists, the team can return to the original analytical objective.

This sounds simple, but many weak models exist because someone refused to accept an honest "no" at the asset stage. Instead of identifying what was missing, the organization moved forward with false precision.

The question finance must add

The yes-or-no structure creates clarity, but financial analysis needs one additional layer: how confident are we that the answer is yes?

A strategy may pass all three tests and still depend on fragile assumptions. That is where sensitivity analysis, downside scenarios, timing, and leading indicators become essential.

• What must be true for the model to work?
• Which assumption has the greatest effect on the result?
• What could break the relationship between the planned behavior and the expected outcome?
• How quickly will we know whether the strategy is working?

Strategy may want a yes-or-no answer. Finance must also measure how fragile that yes is.

From reporting numbers to testing strategy

A financial analyst's role is often described as forecasting, budgeting, reporting, or explaining variance. All of those matter.

But the deeper value of the role is the ability to examine whether the business story behind the numbers is coherent. Do the available resources support the expected outcome? Can the organization actually perform the actions assumed in the model? Will those actions create the customer and operational responses required to produce the financial result?

I used to think the central questions in a model were whether the formulas were correct and whether the assumptions were reasonable. I still believe both matter. But now I think there is a question before them: does the logic connecting resources, actions, and results actually hold?

A spreadsheet can calculate an outcome. A good analyst has to test the strategy behind it.