Numbers Matter, But Field Knowledge Matters More
As a textbook convention for business plans, you often see the sequence “improve operational efficiency” → “efficiency gains and headcount cost reduction” → “and therefore, here’s the market value.”
There’s nothing wrong with that at all, and plenty of people won’t even talk to you unless you frame it that way, so by all means get that part polished.
But here I want to talk about what comes after: the “small hidden side that everyone runs into.”
This isn’t some grand mystery I’m building up to. Anyone who takes even a step or two forward with a real business will run into it.
Let’s picture a BtoB business as an example.
Say you’re targeting some service industry and pitching, “We built a software tool that improves operational efficiency by this much!” (call it App A for now).
You quickly approach the person in charge of operations, or someone in a department with authority to decide on adopting outside tools (call him Manager B).
You build a network aiming to get in contact with the person who actually holds decision-making authority, and eventually you manage it. That person (call him Division Head C) really likes what you’ve got.
Division Head C tells you it’s been decided that this will go before the board of directors, and you wait eagerly for the outcome.
After a while, Manager B proposes a plan to first run a trial evaluation at some of their sites. This is the so-called PoC. Naturally, you get a one-time payment for it.
You’re overjoyed and immediately start preparing for deployment.
But be careful. At this stage, you’re still deeply in the red.
Division Head C’s request is this:
“Show me in numbers that operational efficiency improves the way you say it will. If you can do that, we’ll roll it out to all our sites.”
The success or failure of this PoC will determine the fate of your company. You charge enthusiastically into the field, and here you’re extremely likely to run into a few classic stumbling blocks.
- The field staff don’t even know about it
Division Head C tells Manager B “I’ll leave the rest to you,” and Manager B talks to Manager D (the person in charge of the facility or department) who actually controls the field.
Up to this point the message might get through to some degree, but at the very least, Manager D’s level of understanding looks like this:
Manager B > Division Head C >> Manager D
At best, Manager D has “heard” roughly why the PoC is happening, with no idea what goal Division Head C has set. Still, fulfilling his managerial duty, he informs field Leader E about a month before deployment.
Leader E may only vaguely remember the name of your company or the tool being tested for the PoC, if at all. The field is busy every single day.
A meeting on how to use the tool gets set up two or three weeks beforehand, and only then does Leader E finally get a proper grasp of who you actually are. But he still doesn’t understand the goal or point of the PoC.
You go all in explaining, in painstaking detail, how to use the tool, but the whole time Leader E has a puzzled look on his face: “What is this even for?”
So, will this PoC succeed? The answer is no.
- You run into pushback from the field
The field is busy, no matter what.
The team responsible for testing a new tool is, in most companies, more or less a fixed group. But they’re “not a team dedicated to this.” They have their normal work to do. On top of that, they’re forced to learn an unfamiliar tool, made to carefully read through documentation on top of their regular duties, and made to fill out surveys at the end of their shifts.
It would be strange if they didn’t push back.
To them, you are the enemy, plain and simple. Leader E might manage to tell his team something like “well, just bear with it, please,” but the outcome will still likely tilt in an unfavorable direction.
- It turns out the field doesn’t actually appreciate it
This is the biggest tragedy of all.
You end up even feeling contempt toward the field staff who are pushing back.
“We built such a convenient tool, why won’t you just use it comfortably!” “You’re just using it wrong!” “At least read the manual before touching it!” — that sort of thing.
But look closely and observe them carefully.
Take a case like this. Their job hardly involves sitting at a desk during the day; they barely look at a PC screen. And even that little bit of screen time is just clerical work — checking schedules, checking email, processing slips — a tiny fraction of their overall workload. Your tool might be very convenient and might shorten the time they spend at their desk even further, but
what’s the point of shortening something that’s already short?
Their real pain point was something else entirely: “please do something about the fact that we almost never get to sit down calmly at a desk and work.”
That was a fact you could have grasped instantly just by visiting the field and sitting there for half a day.
Only now do you finally understand that juggling numbers on paper means nothing.
Now, this simulation is somewhat abstract (that’s intentional), but as I said at the start, it’s the “small hidden side that everyone runs into.”
“The other side of a small partition” might be a more accurate way to put it.
So how do you avoid situations like this? It’s extremely simple.
- Bring onto your team someone who has actually worked in the target field
- Go to the target field, no matter what
That’s all it takes.
Even startups that ultimately achieved dazzling success very often tell stories like, “back then, we built a service the field genuinely didn’t need at all.”
Everyone does this once or twice, regrets it, and corrects course the next time.
Having read this, I’d really like you to reexamine your own situation before you even get to your first time.
There’s also a good keyword for systematically understanding this situation, and it’s this:
“Understand that stakeholders span multiple layers.”
The executive is satisfied by improved numbers.
The division head is satisfied as long as he can deliver numbers that make the executive comfortable.
The section manager is satisfied as long as results seem to align with his own mission.
The field manager just hopes, above all, that no complaints come up from below.
The leader says “if it’s an order from above, there’s nothing to be done about it,” while actually believing it’s unnecessary if it doesn’t benefit his own team.
The team members are, above all, busy, and are constantly pleading for someone to do something about that. The moment their workload increases even slightly, they show immediate rejection.
The recipient of the service (the client) wants to receive the best possible service for the lowest possible cost.
Each of them is thinking something completely different, and each has different values.
And yet, you have to satisfy every single one of them cleanly.
When putting together a business plan, there’s an unavoidable tendency to consider only the interests of people above a certain layer. That’s correct in a sense (going after the person with decision-making authority is the most basic of basics in any negotiation), but you need to know that this alone is far from sufficient.
Author Profile
 | Yuichiro “kuz” Kuzuryu Engineer / Executive Has fallen into all manner of valleys of death, from launching new businesses at major Japanese corporations to Silicon Valley startups. ClayTech Inc., CEO, Founder EYS-STYLE Inc., Director 144Lab Inc., Director Visiting Professor, Tohoku University Serves as technical advisor to several other companies https://twitter.com/qzuryu https://www.facebook.com/qzuryu https://www.linkedin.com/in/yuichiro-kuzuryu-kuz-27b92838/ |
Originally published in Japanese at https://clazytech.com/2019/10/265/. Translated with LLM assistance and reviewed before publication.