Are Your Business Processes Solving Problems That No Longer Exist?
Most business processes outlive the problems they were built to solve. The process becomes the problem, and optimizing it makes things worse.
6 min read
Most business processes outlive the problems they were built to solve. The process becomes the problem, and optimizing it makes things worse.
Processes are built to solve problems. When the problem disappears, the process stays, and teams start optimizing something that was never necessary.
Here is the pattern: a problem shows up, someone builds a process to fix it, the problem gets solved, and then the process takes on a life of its own. Teams form around it. Customers adapt to it. Managers optimize it. Nobody goes back and asks whether the original problem still exists.
Paul Veth ran into this directly when trying to switch his home from gas to induction cooking. The energy company had a strict sequence: plumber switches off gas first, then the power company schedules the induction switch, with no guarantee of when that second appointment would happen. Days or weeks without cooking, just because the process said so. The solution was not built around the customer's actual need, which was continuous access to a working kitchen. It was built around an internal workflow that nobody had questioned.
This is not an isolated quirk of utility companies. It shows up in startups, in mid-size businesses, in enterprise teams. The process becomes the product, and the customer becomes a variable that has to fit around it.
A whole division at Tesla was building a noise reduction solution that made no measurable difference. When they tested with and without it, the result was identical.
In Walter Isaacson's biography of Elon Musk, there is a story about a division that thought it was working on a noise reduction problem, while another division thought the same work was a fire safety thing. When both teams compared notes, neither problem actually required the solution being built. A simple A/B test confirmed it: the car was no different with or without the work the team had been doing.
The entire division, the budget, the engineering hours, even involvement from the battery team, all of it had been pointed at a solution that was not solving anything real.
Paul Veth uses this as a direct illustration of what happens inside companies at every scale. Isaacson's account shows how even organisations with strong technical discipline can end up in this loop. The problem is not incompetence. It is the natural pull that entrepreneurs and builders have toward solving things. Problem-solving feels productive. It creates momentum. But as Paul Veth puts it, if you try to solve a problem that was not actually a problem, you have now created a new one: you have to justify and optimize the solution.
Entrepreneurs are wired to find and fix problems. That instinct is valuable, but it also pushes them to invent problems that were never real in the first place.
Problem-solving is not just a skill for most founders. It is closer to an identity. The feeling of identifying a problem, building a fix, and watching it work is genuinely satisfying.
Paul Veth names this loop clearly: you need problems to solve, so you go looking for them. But most of the problems you find are not actually problems. And once you build a solution for a non-problem, you are stuck. Now you have to maintain it, explain it, staff it, and defend it in budget reviews.
The practical version of this looks like a CRM integration that nobody uses, a customer onboarding flow with seven steps when three would do, or an internal reporting process that was built for a compliance requirement that no longer applies. The process runs, people attend the meetings around it, and the original reason it existed has long since been forgotten.
Don't overcomplicate it. The DNA of your business is the one thing you are trying to do for the customer. Anything that does not connect back to that is a candidate for removal.
Start by asking two questions: does this process need to exist, and why? Then ask your customers if the problem you are solving is even a problem for them.
Paul Veth's framework here is deliberately simple. Before optimizing anything, ask whether the process should exist at all. Then ask why it exists. Those two questions, asked honestly, will surface most of the unnecessary work running inside a business.
The second step is to go to the customer directly. This sounds obvious, but most companies assume they know what their customers find difficult. They build solutions based on internal assumptions, launch them, and then optimize the delivery without ever checking whether the underlying problem is real.
When you ask customers what their actual problems are, the answers are frequently different from what the internal team expected. The customer does not have the problem you built a solution for. They have a different problem. Now your process is optimized for the wrong thing.
The recommendation is the same across contexts: validate the problem before building the solution. Sell first, then start creating it, as Paul Veth puts it.
The practical test is direct. Map the steps between the customer's need and the solution. Every step that does not directly serve the customer is a candidate to remove. In the induction cooking example, the gap between the plumber visit and the power company appointment was exactly that kind of unnecessary step. It existed because of internal scheduling logic, not because the customer needed it there.
Focus on the single outcome the customer needs. Eliminate everything between that outcome and the customer. The simplest path is almost always the right one.
Paul Veth uses Tesla's core objective as a reference point: bring people from A to B safely, without excessive noise. That is the anchor. Every solution the company builds should connect to that. The noise reduction team's job is not to eliminate noise as an end in itself. It is to ask why a specific part makes noise, and whether that part needs to exist at all.
This reframing changes the work from optimization to elimination. And elimination, done consistently, is more valuable than optimization of the wrong things.
For a smaller business, the same logic applies. Define the one problem you solve for the customer. Make that the filter for every process, every team, every tool. If something does not pass the filter, it does not belong in the system.
The uncomfortable version of this is that some processes, when examined honestly, will not pass the filter. Some roles will not pass the filter. That is a hard conversation, but it is the right one. Paul Veth is direct about this: the most simple way to solve customer problems is by eliminating almost all processes. Almost every part that stands between the solution and the customer is a candidate to remove.
This is not a one-time audit. It is a mindset that needs to run continuously inside a company, at every level. When every person in the organisation asks whether what they are working on is actually necessary, the answer will occasionally be no. That is progress.
Ask two questions: does this process need to exist, and why does it exist? Then trace it back to the customer problem it was originally built to solve. If that problem has been resolved another way, or was never a real problem, the process is a candidate for removal. Validate with customers before assuming.
Problem-solving is a core part of how most founders operate. The instinct to find and fix things is genuinely useful, but it also creates a pull toward inventing problems. If you build a solution for a non-problem, you are now obligated to maintain and justify that solution, which creates a new problem.
Optimizing makes an existing process run faster or cheaper. Eliminating asks whether the process should exist at all. Optimization is only worth doing after you have confirmed the process is necessary. Most businesses skip the second question and go straight to the first, which locks in waste at a higher speed.
A team at Tesla spent significant resources on noise reduction that a simple test proved made no measurable difference. The same dynamic appears at every scale: a team builds something, the work becomes routine, and nobody checks whether the output is necessary. The fix is a direct test against the actual customer need.
Ask them directly, without leading with your existing solution. Most companies assume they know what customers find difficult, and build accordingly. When you ask customers to describe their actual problems in their own words, the answers frequently differ from internal assumptions. The best feedback is when you start selling something and nobody buys it.
Most of us have at least one process in our business that everyone follows but nobody can explain why anymore. What is a process you recently realized was solving a problem that no longer exists, and what did you do about it?