Stop Building Features. Start Defining the Job

One of the most expensive sentences in business is this: "We should build a platform for that."

I’ve heard versions of it for years, and the pattern is always the same. In accounting departments. In ERP projects. In operations meetings. In software conversations. Somebody identifies friction, someone else jumps straight to a solution, and before long the room is debating features, integrations, dashboards, architecture, AI, permissions, rollout timing, and whether it should live in the cloud.

The room gets more sophisticated by the minute, but the thinking often gets worse. Because nobody has stopped to ask the only question that actually matters first: What is the job this thing is supposed to do?

The Mistake Smart People Make

Smart people are especially vulnerable to this because we like solving things.

If you're technical, you want to build. If you're operational, you want to optimize. If you're in finance, you want to control the risk and define the process.

All of those instincts are useful. None of them matter if you're solving the wrong problem.

This is the insight behind the jobs-to-be-done framework, and it's one of the best things I've pulled from my Berkeley CTO coursework so far. The framework itself is simple: instead of asking what product to build, ask what progress the relevant stakeholder is actually trying to make.

Not what they asked for. Not what feature sounds good. Not what would be cool in a demo.

What job are they hiring this thing to do?

That distinction is massive.

People Rarely Mean the First Thing They Ask For

An executive says they want a dashboard.

Maybe they do. But maybe what they actually want is to stop getting embarrassed in Monday meetings because the numbers arrive too late to be useful.

A manager says they want automation.

Maybe they do. But maybe what they actually want is fewer errors showing up at month-end.

A founder says they need an AI assistant for small businesses.

Maybe. But maybe the real job is: help me avoid paying three outside firms to answer basic startup questions while I’m trying to get off the ground.

Those are not the same thing.

The first version leads to scope creep. The second version leads to strategy.

I’ve Seen This in Accounting for 30 Years

My career has been full of examples where companies chased the visible request instead of the actual job.

Someone says they need a spreadsheet. So they get a spreadsheet.

Now they have six versions of it, nobody knows which one is right, and one person has to stay late every month to manually override half the formulas.

What was the real job?

It wasn’t make a spreadsheet.

• create visibility into a process nobody trusts
• reduce the number of manual corrections
• reconcile two systems that were never designed to talk to each other
• give a manager enough confidence to make a decision without asking three people for the same numbers

If you define the job correctly, the spreadsheet might be the wrong answer. Or it might be the right answer for now. But at least now you know what you're evaluating it against.

The Right Problem Usually Hides Under the First Problem

This is what I mean when I say a lot of business problems are really systems problems.

At the surface level, someone says: "We need a better report."

You dig one layer down and find: "The report is late because the data load is stale."

One layer deeper: "The data load is stale because the live system only exports snapshots overnight."

One layer deeper: "The real job is not reporting. The real job is reducing the lag between operational reality and financial visibility."

Now we’re actually talking about something real.

That’s not a reporting problem. That’s a decision-speed problem. That’s a leadership problem. That’s a technology strategy problem.

And if you don’t define it that way, you’ll spend six months polishing the wrong output.

Why This Matters for CTO Thinking

The reason I keep coming back to this framework is that it cuts across the broader shift I’m interested in between finance, systems, and technology leadership.

Controllers are trained to ask: what happened, what changed, and what can we prove?

Good CTOs ask: what should be built, why does it matter, and what behavior will it change?

Jobs to be done sits right in the middle.

It forces a more disciplined version of product and operating thinking. It also forces humility. Because the moment you use it honestly, you realize how often your favorite solution is just a guess with better branding.

I’ve built enough systems to know this now: Technical feasibility is not the same as strategic correctness.

You can elegantly build something no one actually needed. Companies do it every day.

A Better Set of Questions

Before you build anything, ask:

• What progress is the stakeholder actually trying to make?
• What are they doing today instead?
• What does failure look like in their current process?
• What are they really optimizing for: speed, certainty, reduced effort, reduced embarrassment, reduced risk?
• What would have to be true six months from now for us to say this was worth doing?
• How would we know if we solved the right problem?

That last question matters more than most people think. Because if you can’t state how success would be recognized, you probably haven’t defined the job clearly enough.

This Is Not Anti-Building

To be clear: this is not an argument against building.

I like building. I’m wired to build. If anything, I have to actively stop myself from sprinting into implementation too early.

This framework doesn’t suppress that instinct. It disciplines it.

It says: build, but only after you’ve earned the right to build. Only after you can state the job. Only after you understand the value. Only after you know what better actually means.

That’s not bureaucracy. That’s respect for time, capital, and human effort.

What I’m Trying to Practice

One of the hidden benefits of executive education is that it gives you language for patterns you were already living.

I’ve been doing jobs-to-be-done work for years without naming it that way.

Every time I looked at a broken ERP workflow and asked what the people involved were actually trying to accomplish.

Every time I challenged a reporting request because the report itself wasn’t the real problem.

Every time I pushed past the feature request and asked what decision someone was actually trying to make.

That was the work.

Now I just have cleaner language for it. And cleaner language matters, because it lets you teach it, scale it, defend it, and use it outside the one room where you first figured it out.

The Rule

If I had to reduce the whole thing to one rule, it would be this: Don’t let the team fall in love with the solution before it can name the job.

That one discipline will save more time than most project-management software ever will.

It will save money. It will save morale. It will save companies from beautifully executed mistakes.

And if you work in the space between systems, finance, technology, and operations the way I do, it may be one of the most valuable habits you can build.

Because once the job is clear, a lot of bad ideas die quickly.

That is not a loss. That is the beginning of strategy.