Stop Adding Features. Your B2B Product Is Dying Because of It.

Your ERP system just went live. The client smiles, nods, and says, \”Great, we’ll start using it Monday.\” Three weeks later, you discover the truth: the warehouse is still chaos, the inventory counts are still wrong, and the only thing your software has done is give everyone a better excuse for being late.

Sound familiar? If you’ve ever shipped a B2B product, you’ve felt this gut-punch. You did everything right — gathered requirements, built features, ran sprints, delivered on time. And still, the system is a digital monument to your team’s busywork. We’ve mastered the art of building features, but we’ve forgotten the purpose of building software: to solve a problem that hurts.

I’ve been there. I’ve delivered a project that made the client shrug. And then I read Toyota Production System by Taiichi Ohno — a book written for car factories in the 1950s — and realized it’s the most brutal, honest product management manual ever published.

Here’s what it taught me: Most B2B products aren’t failing because they lack features. They’re failing because they have too many. And the fix is not to build more. It’s to build less, but build it with surgical precision.

Let me walk you through the five principles that will cure your \”pseudo-launch\” — and save your career from the graveyard of irrelevant enterprise software.

Principle 1: Don’t Build What Users Want. Build What Hurts.

Toyota’s rule: The downstream process pulls exactly what it needs from the upstream. No kanban card? No production. No actual demand? No feature.

Yet in B2B, we do the opposite. A warehouse manager says, \”I want a PDA scanner for putaway.\” You nod, write the PRD, your devs spend weeks on a barcode-scanning interface. Then it fails because the real problem wasn’t scanning — it was that manual data entry meant items got placed in wrong bins, so pickers couldn’t find anything, and orders shipped late.

The user’s \”want\” is a solution, not a problem. The moment you treat it as a requirement, you’re building on sand. Instead, force yourself to ask three questions before any feature makes it into your backlog:

• What business outcome does this affect? (Revenue, cost, risk, time?)
• What happens if we don’t build it? (Will the pain actually escalate?)
• What is the cheapest possible way to test this solution?

In that warehouse case, the real pain was \”orders ship late because pickers can’t find items.\” The solution wasn’t a scanner — it was a system that automatically suggests the correct bin when receiving. That’s a different feature. That’s a feature that saves money.

Stop asking users what they want. Ask them what they’re losing sleep over.

Principle 2: Ask \”Why\” Five Times. Then Build.

Ohno’s famous 5Why: When a machine stops, don’t ask \”how to fix it.\” Ask why it stopped, again and again, until you reach a root cause that leads to a system change — not a quick patch.

In B2B, we take the first answer and run. A production supervisor says, \”We need a digital SOP viewer at each workstation.\” Sounds reasonable, right? But ask why:

• Why do you need it? Because workers keep making errors on assembly steps.
• Why do they make errors? Because new hires can’t remember the steps.
• Why can’t they remember? Because SOPs change frequently, and training can’t keep up.
• Why do SOPs change? Because engineering updates the BOM, but SOPs aren’t synced.
• Why aren’t they synced? Because your ERP and MES have disconnected BOM data, so SOPs require manual updates.

Now you see the real problem. A digital SOP viewer is a band-aid on a broken data pipeline. The actual solution is to integrate your ERP and MES so SOPs auto-update when the BOM changes. If you don’t ask the fifth why, you’ll fix the wrong thing — and call it progress.

Principle 3: Make Anomalies Scream in Real Time, Not in a Monthly Report.

Toyota’s Andon system: Every line worker can pull a cord to stop the entire assembly line when something’s off. The board lights up red. The problem is addressed immediately, on the spot. Ohno said, \”A production line that never stops isn’t perfect — it’s hiding its problems.\”

Your B2B product is probably a master of hiding problems. Data gets entered wrong — nobody knows. A workflow gets stuck — nobody notices. A critical feature hasn’t been used in three days — the system is silently decaying. You rely on weekly or monthly dashboards to spot issues, but by then the damage is done: inventory is wrong, orders are late, customers are angry.

Your product should be designed to expose anomalies the moment they happen — not to hide them until someone runs a report. If you’re building a workflow tool, add a visual board that shows every stuck item. If you’re building a data pipeline, alert on schema changes. Make the invisible visible.

A system that goes silent is a system that’s dying — and nobody’s there to hear it.

Principle 4: Say \”No\” to 80% of Feature Requests.

Toyota’s biggest enemy is overproduction — making more than the customer demands. Ohno called it the root of all waste, because it creates storage, transport, and management costs for something nobody needs.

In B2B, overproduction looks like this:

• \”Let’s add this config option — it might be useful later.\” (Later never comes.)
• \”Let’s include this report — someone might want it.\” (Nobody ever opens it.)
• \”Let’s build a mobile version — everyone wants mobile.\” (Your users are on desktops, 9–5.)

Every feature you add is a promise you’re breaking to the ones that already exist. It’s code to maintain, tests to run, docs to update, and UI to confuse users. Feature creep is a silent killer of user adoption.

Adopt a \”not-to-do list.\” Before any new request, ask: Does this solve a problem we’ve proven exists? Is it essential for the next 90 days? Or is it a \”nice to have\” that will drain our resources? If it’s not essential, it goes on the backlog — not the sprint.

Here’s a real example: A client demanded an OEE (Overall Equipment Effectiveness) dashboard as a P0. But when we dug in, we discovered they didn’t even have reliable machine data. We convinced them to make \”reliable machine data collection\” the P0 and froze the dashboard. Three months later, with clean data, we built the dashboard in a week — and it was actually used. The difference? We built what was needed, not what was wanted.

Principle 5: Fix the Process Before You Touch the Code.

Toyota’s rule: \”Improve the process first, then improve the machine. If you improve the machine first, you only increase costs.\”

B2B teams love to blame the system. \”The process is a mess — let’s implement an ERP and it’ll straighten itself out.\” Nonsense. Software can’t fix a broken process. It can only amplify the mess. If your workflow has unclear handoffs, a system will make those handoffs even more confusing. If your roles are ambiguous, permissions will be chaos.

Before you write a single line of code, map the current process. Use a flowchart. Walk the floor. Talk to the people who actually do the work. Identify bottlenecks, manual steps, and decision points. Then, and only then, decide where software helps — and where it just adds overhead.

At one factory, the client wanted a system to track work orders. But we discovered that the real bottleneck was the morning meeting where supervisors argued about priorities. We redesigned the meeting process first — gave them a simple whiteboard. Then we built the system to support that. The result? The whiteboard became the single source of truth, and the system simply digitized it. The project succeeded because we fixed the human process before we automated it.

The Toyota Self-Check for Your Next Launch

Before you celebrate your next B2B \”go-live,\” run through this checklist. If you can’t answer yes to every question, you haven’t built a product — you’ve built a prototype.

• Did we solve a real business problem, or just fulfill a feature request?
• Did we trace the root cause with at least 5 whys?
• Are anomalies visible in real time, not in a monthly report?
• Did we say no to any non-essential features?
• Did we map and optimize the process before we automated it?

If you’re like me, you’ll discover you’ve been building a lot of features for problems that don’t exist. And that’s okay — because now you know better.

Ohno said, \”It is not that the manufacturing industry of Japan is strong. It is that we have been working on eliminating waste.\”

As B2B product managers, our job is not to produce more functionality. It’s to eliminate waste — the waste of unused features, wrong assumptions, and hidden failures. The next time a user asks for a feature, don’t ask \”how long will it take?\” Ask why. Then ask four more times. That’s the difference between a product that gets used and a monument to your team’s busywork.

Do less. But do it with ruthless precision. That’s the only way your product will ever be truly used.