When confronted with workplace dysfunction, missed connections, or poor communication, we frequently assume that we need to address a process issue. If we only had the right tools and the right systems, we could untangle things. So we tweak and retweak processes, arrange meetings, and try to get (or buy) systems that promise to link together all of the information team members need and make it all work. But, does it ever really work?

What if process isn’t the problem?

We tend to identify problems as process problems when, in fact, they are focus problems.

A great example is the question of how to handle customer feature requests. On the surface it appears as if this is a process problem. How do you track those requests, regularly update customers, and figure out how to prioritize those requests in the product backlog? The temptation is to purchase a bunch of tools and systems and implement a feature request tracking system. But, take a step back. How awesome would it be if your team was always cranking out valuable features? If, rather than fill the pipeline with requests to be managed, you solved a focused problem and had customers lining up due to word of mouth? How could you focus to make that happen?

From a broader organizational perspective, consider something like performance reviews. In truth, we know that intrinsic motivation is what works, and yet we create complex processes and systems of incentives to keep the ship on the rails and to have a paper trail of accountability. But what if none of that was a problem? What would it look like if everyone was held accountable by their own passion for the work?

Process itself isn’t a problem. But when we’re working on process in product development we should consider whether we’re really treating symptoms of a lack of focus. Is that tracking system only needed because we’re trying to do too many things at once? Do we think we need to massively customize a CRM when really we’re just trying to handle too many customers at once? In start-ups it is easy to mistake a problem as one of scaling or “growing pains,” when, in fact, your problem is that you’re trying to cram in as much work as possible rather than do a few things well.

We need to differentiate between process that enables innovation, and process that is applied from above to band-aid symptoms of a deeper problem. Ideal process can be a dynamic, iterative working agreement among motivated people. But process for its own sake or process that is used to exert control can be poisonous. This is the reason so many management consultants and “change initiatives” fail to achieve their goals.