Numbers Matter, But Frontline Knowledge Matters More

As a textbook approach to writing business plans, the pattern of “operational efficiency improvement” → “efficiency gains and headcount reduction” → “and therefore market value is…” shows up constantly.

It’s not wrong at all, and plenty of people (a certain species of them) won’t even talk to you unless you frame things that way, so by all means get that part in order.

But here I want to talk about what comes after that — the small hidden backside everyone runs into.

This isn’t some grand, mysterious thing I’m building up to. You will run into it the moment you take one or two steps forward with any business.

Let’s imagine a B2B business as an example. Suppose you’re targeting a particular service industry and pitching, “We built a software tool that improves operational efficiency by this much!” (call it App A for now).

You’d immediately approach the person in charge of operations, or someone in a department with authority to decide on adopting outside tools (call them Section Chief B). You build connections aiming to reach the person with actual decision-making authority, and suppose you finally succeed. He (call him Division Head C) likes it a great deal.

Division Head C tells you it’s been decided that this will go before the board, and you wait eagerly for the result. After a while, Section Chief B proposes running a trial evaluation at some of their sites first. 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 us 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 determines whether the company sinks or swims. You head out to the field with great enthusiasm, but here you are extremely likely to run into a few classic pitfalls.

1. The field staff aren’t aware of it

Division Head C tells Section Chief B “handle the rest from here,” and Section Chief B talks to Manager D (the person responsible for the facility or department) who controls the field. Up to this point, the message may have gotten through to some degree, but at minimum, Manager D’s understanding of it is on the order of

Section Chief B > Division Head C >> Manager D

At best, they’ve “heard” roughly what the intent of the PoC is, but have no idea what goal Division Head C has actually set. Still, as part of their managerial duties, they inform field Leader E about a month before deployment. Leader E may barely remember the name of your company, or even the tool being trialed. 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 properly understand who you actually are. But they still don’t understand the goal or significance of the PoC. You carefully and patiently explain how to use the tool, but the whole time, Leader E’s face says: “What is this even for?”

So, will this PoC succeed? No.

2. You get pushback from the field

The field is busy, no matter what. The team responsible for testing new tool rollouts tends to be fixed in most companies. But they are not a team assembled for this purpose — they have their normal work. On top of that, you’re making them learn how to use an unfamiliar tool, read through documentation on top of their regular work, and fill out surveys at the end of it all. It would be strange if they didn’t push back. To them, you are the enemy itself. Leader E might manage to tell the team something like “well, just bear with it,” but the results will still tend to trend in an unfavorable direction.

3. It turns out the field doesn’t actually appreciate it

This is the biggest tragedy. You even start to feel contempt for the field staff 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!” But look carefully and observe them. Take a case like this. Their work rarely has them sitting at a desk during the day, and the time they spend looking at a PC screen is minimal. Even that is mostly desk work like checking schedules, checking email, or processing forms — a tiny fraction of their overall workload. Your tool may be very convenient and might shorten the time they spend at their desk even further, but

what’s the point of shortening a time that’s already short?

Their pain point was actually something else entirely: “please do something about the fact that we almost never get to sit down and work calmly at our desks.”

You could have understood this immediately just by visiting the field and sitting there for half a day. Only now do you finally realize that juggling numbers on a spreadsheet was meaningless.

A simulation like this may seem somewhat abstract (that’s intentional), but as I said at the start, it’s the small hidden backside everyone runs into. “The small space just behind the partition” might be a more accurate way to put it.

How do you avoid situations like this? It’s extremely simple.

• Put someone on your team who has actually worked in the target field
• Just go visit the target field first

That’s it. Even startups that eventually 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. If you’re reading this, I really want you to reexamine your own situation from square one.

There’s also a good keyword for understanding this situation systematically:

“Understand that stakeholders span many layers.”

The executive is satisfied by improvements in the numbers. The division head is satisfied if it looks like they can deliver numbers that will make the executive happy. The section chief is satisfied if results seem likely to align with their own mission. The field manager just hopes, above all, that no complaints come up from below. The leader thinks, “can’t be helped if it’s an order from above,” while actually believing it’s unnecessary if it doesn’t benefit their own team. The members are simply busy all the time, and are constantly pleading for someone to do something about that. If their workload increases even slightly, they show immediate resistance. The recipients of the service (the clients) want the best possible service for the lowest possible price.

Each of them is thinking about something completely different, and their values differ too. And yet, you need to satisfy all of them cleanly. When drawing up a business plan, there’s an inevitable tendency to consider only the interests of people above a certain layer. That’s correct in a sense — securing the person with decision-making authority is the most basic foundation of negotiation — but you need to know that this alone is severely insufficient.

Author Profile

Yuichiro “kuz” Kuzuryu Engineer / Executive Has fallen into every kind of valley of death, from launching new businesses inside large Japanese corporations to Silicon Valley startups. CEO, Founder, ClayTech Inc. Director, EYS-STYLE Inc. Director, 144Lab Inc. Visiting Professor, Tohoku University Serves as technical advisor and advisor for 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.