If You Can't Measure the Value, You Don't Have a Strategy Yet

There are ideas that sound intelligent in a meeting and then collapse the second you ask one follow-up question.

The question is usually some version of this: What gets better, by how much, for whom?

That question sounds simple. It is not.

It has a way of exposing whether the team has found something real or whether everyone is just enjoying the feeling of momentum.

I’ve spent most of my career in environments where value eventually has to show up somewhere concrete. In accounting, operations, and systems work, that usually means dollars, time, accuracy, risk, throughput, or decision quality. You can get creative with the language for a while, but eventually the business has to feel the improvement.

That instinct turns out to matter just as much in technology strategy. Maybe more.

Lately, it has become one of the ideas I come back to most often. Not because it sounds sophisticated. Because it prevents expensive vagueness.

Vague Value Is Usually a Warning Sign

I’ve seen plenty of initiatives get funded on some foggy combination of enthusiasm, pressure, trend-chasing, and executive impatience.

The language is familiar:

• this will streamline the process
• this will create visibility
• this will improve collaboration
• this will help us leverage AI

Maybe it will.

But if no one can explain what improvement means in concrete terms, the idea is not mature yet. It might still become a good idea later. But right now it is closer to optimism than strategy.

That does not make it worthless. It makes it unfinished.

That distinction matters because vague value creates downstream confusion everywhere: teams prioritize badly, stakeholders hear different promises, pilots cannot be evaluated honestly, and projects linger because nobody defined what success looked like in the first place.

When measurement is weak, politics fills the gap. And once politics fills the gap, teams start defending motion instead of testing value.

Finance Taught Me to Distrust Fuzzy Wins

One reason this framework lands so cleanly for me is that finance trains you to ask grounded questions.

Not whether something feels promising.

Whether it changes the numbers, reduces the noise, or improves the decision.

If someone tells me a system improvement matters, I instinctively want to know:

• Does it reduce manual hours?
• Does it lower the error rate?
• Does it speed up close, reporting, or reconciliation?
• Does it reduce dependence on a heroic employee who holds the whole thing together by memory?
• Does it help management decide faster or with more confidence?

In operating terms, I usually mean something even plainer:

• Does this remove handoffs?
• Does this reduce rework?
• Does this eliminate a daily annoyance people quietly waste time compensating for?
• Does this shorten the lag between what happened and what leadership can see?
• Does this help people make a better call without chasing five versions of the truth?

Those are not anti-innovation questions. They are how you protect innovation from becoming theater.

They are also how you keep a strategy discussion from turning into a software shopping spree.

The Most Dangerous Projects Are the Ones Everyone Likes

Bad projects are not always unpopular. In fact, some of the worst ones are the easiest to rally around because they sound modern.

AI is the obvious example right now.

A team says it wants an AI assistant. Fine. For what?

To reduce support tickets?
To help a founder avoid paying outside counsel for basic startup questions?
To shorten onboarding time?
To improve proposal quality?
To reduce research time by 40 percent?

Those are real value claims.

"We should add AI" is not.

The same thing happened before AI with dashboards, mobile apps, business intelligence, workflow tools, and custom portals. Sometimes the technology was useful. Sometimes it was just a fashionable container for unresolved thinking.

Technology does not rescue a weak value proposition. It usually hides it until the invoice arrives.

The same problem shows up in less fashionable forms too: dashboards, workflow tools, custom portals, and automation projects people want because the old process is annoying, but no one has defined whether the goal is fewer errors, fewer touches, faster response time, or less dependence on tribal knowledge.

If the pain is real but the value is still vague, the work is not ready yet.

What Measurable Value Actually Does

Defining measurable value does not mean pretending everything can be reduced to a spreadsheet on day one.

It means the team can answer a few adult questions before it starts spending real time and money.

• What exactly gets better?
• Whose behavior changes if this works?
• What baseline are we improving from?
• What evidence would make us believe this was worth doing?
• If this succeeds, what result would the customer, operator, or business actually notice?

Sometimes the answer is financial. Sometimes it is operational. Sometimes it is behavioral. But it should be specific enough that another adult could disagree with it.

That is the standard.

That kind of discipline does three useful things at once.

First, it improves prioritization.

Second, it makes stakeholder conversations more honest.

Third, it gives the team a way to kill weak ideas before they become expensive commitments.

That last one is underrated.

People talk about innovation as if every good organization should say yes more often. In practice, good organizations usually get better by saying no earlier and for better reasons.

Measurable value is one of the best reasons.

This Is One of the Best Places My Background Transfers

The older I get, the less interested I am in pretending my finance background is separate from technology leadership.

It is part of the advantage.

A lot of technologists can explain what a system does. Fewer can explain why it matters in terms that survive contact with budgeting, prioritization, and executive scrutiny.

This is one of the strongest bridges in my Controller-to-CTO path.

I understand systems. But I also want to know what the system changes economically, operationally, and behaviorally.

Berkeley has helped make that translation more explicit. It has given me cleaner language for something I was already trying to do instinctively: connect technical action to business consequence.

That is measurable value.

And in a lot of organizations, it is the missing layer between interesting ideas and responsible strategy.

It is also one of the cleanest ways to earn credibility. When you can translate a technical proposal into reduced waste, better timing, lower risk, or better decisions, the conversation changes.

It stops sounding like preference. It starts sounding like leadership.

The Rule

If you cannot state the value concretely enough for someone else to evaluate it, challenge it, and recognize it later, you probably do not have a strategy yet.

You have a possibility.

Possibilities matter. But they should not be mistaken for decisions.

That distinction will save a lot of time. It will save money. It will reduce performative projects. And it will force better leadership conversations before the team gets attached to the work.

In my experience, that is usually where the real advantage starts.

Not when the room gets excited.

When the value gets specific.