Planning Is More Than a Budget Exercise

The best plans make the assumptions behind strategic planning explicit, establish how you'll know whether they're working, and define when new evidence should cause executives to reconsider.

Most planning processes eventually become conversations about money and resources. How many CSMs do we need? How much Engineering capacity should go toward the roadmap versus quality and stability? Should we hire Professional Services consultants or invest in partner capacity? Does Marketing have enough investment to generate the pipeline required to support the growth target? With those questions, strategic planning could easily become an exercise in resource allocation.

The more important question is: What do we believe will create the greatest impact for the business, and what evidence will tell us whether we were right?

Every meaningful resource decision is based on a hypothesis about what will happen next. If we invest here, we believe it will change something, which should ultimately help us achieve the outcome we're trying to create.

Good planning makes those hypotheses explicit.

Do the cross-functional work before the planning meeting

Imagine a SaaS company heading into planning with retention under pressure and continued growth expected. The Customer Success leader's capacity model says she needs 12 additional CSMs. Books of business have grown, the team is increasingly reactive, and too much CSM time is being spent managing escalations instead of helping customers get value.

A strong CCO should know much more than that before asking the company to fund 12 people. She should understand what's driving churn, what work is consuming CSM capacity, whether the problems are concentrated in particular customer segments or products, and what assumptions about growth are creating the future capacity requirement.

If escalations are a meaningful part of the problem, that analysis needs to extend beyond Customer Success. Perhaps Support is seeing increasing case volume and the data suggests recurring product quality and stability issues are contributing to both Support demand and CS escalations.

That's when the cross-functional planning work begins, not when the executive team gets together to review the plan.

The CCO should already be talking with Support, Product and Engineering. She can bring what she's seeing from customers and her own data, compare it with what they're seeing, test her conclusions against their expertise, and understand the tradeoffs involved in addressing the problem.

The purpose isn't to get everyone to support the CS plan. It's to develop a better point of view about what the business needs.

She may come out of those conversations even more convinced that the company needs 12 CSMs. Or she may conclude that the better recommendation is some additional CS capacity combined with investment elsewhere. There may also be genuine disagreement that needs to be resolved by the executive team.

What shouldn't happen is for the planning review to be the first time Engineering learns that another function's plan assumes Engineering will improve product stability, or Marketing discovers that the growth plan depends on pipeline it hasn't committed to delivering.

Finance, RevOps or a dedicated planning team can help orchestrate this work, create common assumptions and model scenarios. But they can't substitute for the expertise and cross-functional work of the leaders who will ultimately be accountable for delivering the plan.

The process can support executive judgment. It can't replace it.

Decide where the investment will have the greatest impact

Now suppose the cross-functional work has surfaced a more complete picture.

Customer Success does need more capacity. At the same time, recurring product quality and stability issues are creating Support volume, generating escalations, consuming CSM time and affecting customers' confidence in the product. Engineering believes it can address some of those issues, but doing so requires resources that would otherwise go toward roadmap commitments. Marketing also has a legitimate concern that pipeline coverage won't support the company's growth expectations without additional investment.

Every leader has a reasonable case. The company can't fund all of them.

Planning can easily become a negotiation at this point. CS asks for 12 CSMs and gets six. Engineering gets some additional capacity. Support gets a few people. Marketing gets most of what it requested. Everyone gives something up and Finance gets the budget to balance.

That may ultimately be the right allocation, but the fact that everyone compromised doesn't make it a good plan.

The leadership team needs to understand what it believes is constraining the business and where additional investment is most likely to change the outcome.

If product quality is a significant contributor to customer escalations and churn, adding CSM capacity may make the symptoms easier to manage without addressing enough of the underlying problem. Adding Support capacity could keep more cases away from CSMs, but customers would still experience the quality issues. Moving resources toward Engineering could address an earlier cause, but at the expense of something else the company planned to build.

There isn't a universally correct answer. There should, however, be a deliberate one.

Make the hypothesis behind the decision explicit

Suppose the company ultimately decides to add some CSM capacity but shifts a meaningful portion of the available investment toward improving product quality and stability.

The hypothesis behind that decision might be that improving product quality and stability will reduce customer-impacting issues. That should reduce Support demand and escalations, return capacity to CSMs to focus on helping customers get value, improve the customer experience and ultimately contribute to stronger retention.

The company can't know in advance that every part of that will happen. Businesses aren't controlled experiments. But everyone should understand what the company expects to change because of the decision it just made.

That logic should also determine what the company measures.

Problems rarely respect organizational boundaries. Neither should the way we diagnose them.

Measure the assumptions behind the decision

I've led an organization where product quality and stability had become significant customer issues. Customers experienced defects and outages, Support handled the resulting cases, CSMs spent time managing escalations and rebuilding confidence, and some of those experiences contributed to customers leaving.

Going into planning, I didn't think our view of customer health could stop with metrics reported by Customer Success. If we believed product quality was contributing to the outcome, we needed customer-impacting measures around quality and stability as well.

That didn't mean Product owned retention. Different functions should remain accountable for what they can meaningfully influence. But the executive team needed to be able to trace what happened after the investment was made.

Did quality improve? Did customer-impacting incidents decline? Did Support volume and escalations change? Did CSMs actually get capacity back? Did customers have a better experience? And eventually, what happened to retention?

The relationship won't always be perfectly linear, nor does every point in the chain need to become a company KPI. The purpose is to have enough evidence to understand whether the assumptions behind the decision are holding.

Your metrics should tell you whether your hypothesis is playing out the way you expected.

The same logic can apply to a very different decision. A Professional Services organization forecasting significant implementation growth might conclude that it needs 20 additional consultants. The company might instead decide to invest in building partner capacity.

The hypothesis is that partners can create the necessary delivery capacity without sacrificing implementation quality, time to value or customer outcomes. If partner capacity doesn't materialize, or implementation performance deteriorates, the assumptions behind that decision deserve to be revisited.

Decide when you'll reconsider the plan

There's a reason I'm deliberately talking about planning or strategic planning, rather than annual planning.Twelve months is an increasingly long time for executives to assume that the conditions underneath a plan will remain true. Technology is changing how work gets done. Customer expectations and buying behavior shift. Competitive dynamics change. New products perform differently than expected. Hiring plans slip. Partner strategies take longer to develop than anticipated.

Some companies may move toward six-month planning horizons. Others may keep an annual financial plan while creating quarterly or standing mechanisms for reconsidering resource allocation.

The cadence matters less to me than having an agreed way to distinguish between a performance problem and evidence that the plan itself needs to change.

That's why I think plans need both targets and triggers.

TARGET	TRIGGER
Are we executing the plan?	Is the plan still right?
Compares results with our expectations.	Tests the assumptions behind the plan.
Helps us manage performance.	Helps us decide when to replan.

If the company decided to build partner capacity rather than hire 20 consultants, missing the first month's partner recruitment target probably isn't a reason to abandon the strategy. But if partner capacity reaches only half the expected level after six months, that may challenge an assumption fundamental to the decision.

Similarly, if the company invested in Engineering because it believed product quality was contributing to customer escalations, what happens if quality doesn't improve? Or what if quality improves significantly, but escalation volume and CSM capacity don't change?

The latter may be even more useful information. The investment worked as intended, but the original diagnosis of the broader problem may have been incomplete.

A replan trigger isn't permission to reopen the budget every time a function misses a target. That's why Finance needs to be part of establishing the mechanism. Leadership needs to distinguish between normal variance, an execution problem and evidence that one of the assumptions supporting a significant investment has materially changed.

Ideally, that agreement happens when the decision is made: What would we need to see, or not see, to conclude that our hypothesis needs to be revisited?

The board should understand the approach as well. A leadership team that can explain what it believes, what evidence supports that belief, what it expects to happen and what would cause it to reconsider isn't demonstrating less conviction. It's acknowledging that making a good decision with the information available today doesn't guarantee that the same decision will still be right six or twelve months from now.

Strategic planning is an executive capability

Planning quality depends on more than the financial model behind it. It also depends on the quality of the thinking and conversations that produced it.

Strong functional leaders understand their businesses deeply. They bring data, expertise and a clear point of view about what their organizations need. At executive levels, that isn't enough. Executives need to understand enough of the system around their function to recognize when the best answer for the company may be different from the best answer for their organization. They need to seek perspectives that challenge their own, make commitments across organizational boundaries, understand tradeoffs and change their recommendations when the evidence warrants it.

That's ultimately why I think planning needs to be more than a budget exercise. The budget tells you where you've decided to put your resources. A good plan should also make clear why you're putting them there, what you expect to change as a result, how you'll know whether it's working, and what would cause you to reconsider.