Hammer and the Most Dangerous Question in Product Management
What product managers can learn from Michael Hammer, business process reengineering, and the danger of automating bad processes.
How Do We Automate the Current Process?
In 1990, management thinker Michael Hammer published an article in Harvard Business Review with a title that would become one of the most influential ideas in modern business:
Reengineering Work: Don’t Automate, Obliterate
More than thirty years later, I think it remains one of the most important lessons product managers can learn, particularly in the age of artificial intelligence. Hammer’s argument was both simple and uncomfortable: organisations were spending millions of pounds using technology to improve existing processes, but many of those processes should never have existed in the first place.
Technology was making bad processes faster rather than better or simpler. Hammer believed organisations were asking entirely the wrong question, because they were treating inherited processes as things to optimise rather than things to challenge.
The Wrong Question
Most technology projects begin with a familiar challenge: how do we improve the current process? The conversation usually focuses on efficiency, with teams asking whether they can reduce clicks, automate approvals, speed up data entry, generate reports automatically or remove manual effort.
These are sensible questions, but they are often the wrong questions. Hammer argued that organisations should start somewhere else. Instead of asking how to improve the process, they should ask why the process exists at all.
The distinction sounds subtle, but it is not. One question leads to optimisation, while the other leads to transformation. Optimisation accepts the existing world as a given; transformation asks whether that world still makes sense.
Paving Cow Paths
A phrase often associated with Hammer’s work is paving the cow path. The image is simple: a cow path is inefficient because it twists, turns and follows historical accidents rather than deliberate design. Yet many organisations take these inherited routes and simply pave them, which means the route remains unchanged even though movement along it becomes faster.
Business processes often evolve in exactly the same way. Someone creates a spreadsheet, a workaround appears, a manual check is added, a report is introduced, an approval stage emerges and then another approval stage follows. Years later, nobody remembers why any of it exists, but the organisation treats the accumulated mess as if it were deliberate design.
The next step is usually to spend money building software around the process. The cow path gets paved, but the complexity remains. The organisation becomes more efficient at doing something it may no longer need to do.
The Lessons for Product Managers
This is where Hammer becomes particularly relevant to product management. Product managers frequently receive requests that sound entirely reasonable: additional controls, extra validation, new approval workflows, more reporting, more configuration and more process steps.
The temptation is to ask how the team should build the request. Hammer would push us to ask why the request exists in the first place. That question can be surprisingly powerful because it forces the conversation away from implementation and back towards purpose.
Sometimes the answer reveals a genuine requirement. Sometimes it reveals an outdated assumption. Sometimes it uncovers a process designed to compensate for a problem that no longer exists. Occasionally, it reveals something even more interesting: the customer does not need a better process; they need a different process.
The Transport Industry Example
Working in transport technology, this idea appears regularly. Consider proof of delivery. Historically, many organisations relied on paper documents that had to be printed, signed, collected, returned, scanned, stored and retrieved.
Eventually, software vendors digitised parts of the process. The paper became a PDF, but the workflow often remained largely unchanged. Hammer would argue that this is only partial progress because the deeper question has not been answered.
The more interesting question is why we are reproducing a paper-based process at all. If location data, timestamps, photographs, telematics and customer systems are available, perhaps the entire workflow should be reconsidered rather than digitised step by step.
That distinction matters. One approach creates efficiency, while the other creates competitive advantage. Digitisation makes the old process move faster; redesign asks whether the old process is still necessary.
Artificial Intelligence and Hammer’s Revenge
Michael Hammer passed away in 2008, yet his ideas feel remarkably relevant to today’s AI discussions. Many organisations are currently asking how AI can write specifications faster, summarise meetings, generate reports and automate documentation.
These are all automation questions, and they may be useful. Hammer’s perspective would be more provocative because he would ask why those artefacts are being created in the first place.
Consider software specifications. Historically, specifications emerged because knowledge transfer was expensive. Business users understood the problem, analysts documented it, developers interpreted it and testers verified it. Documentation acted as a bridge between groups.
AI changes the economics of knowledge transfer, which means the question changes too. The issue may not be whether we need a better specification; it may be whether we need an entirely different approach to organisational knowledge.
That is a Hammer question, and it leads to fundamentally different solutions.
The Difference Between Improvement and Reinvention
Most organisations are comfortable with improvement because improvement feels safe, predictable and manageable. Reinvention is different because it challenges assumptions, creates uncertainty and threatens existing structures.
Yet history suggests that the largest gains often come from reinvention rather than optimisation. The companies that transformed retail did not simply create better catalogues. The companies that transformed entertainment did not simply improve DVD rental. The companies that transformed communication did not simply build better fax machines.
They redefined the problem. Hammer’s contribution was recognising that technology’s greatest value often lies in enabling entirely new approaches rather than improving old ones.
Why Product Managers Need Both Modes
This does not mean optimisation is unimportant. Sometimes customers genuinely need a process to become faster, sometimes reducing effort creates significant value, and sometimes a small improvement matters enormously. The mistake is assuming every problem should be solved this way.
Product managers need two modes of thinking.
Mode One: Optimisation
Optimisation asks how we can improve what already exists. This is useful when the underlying process is valid and the main problem is friction, waste, delay or inconsistency.
Mode Two: Reimagination
Reimagination asks whether we would design the process this way if we were starting from scratch today. This is useful when the existing process is an inherited workaround, a historical accident or a control mechanism designed for a problem that no longer exists.
Most organisations spend too much time in the first mode. Hammer spent his career arguing for more time in the second.
The AI Opportunity
The current wave of AI investment presents a rare opportunity because many industries are being forced to reconsider assumptions that have existed for decades. The winners may not be the organisations that automate the most tasks; they may be the organisations that ask the most uncomfortable questions.
Those questions include why a workflow exists, why an approval is required, why information is stored in a particular place, why a document is created, why teams interact in a certain way and why a particular artefact is treated as essential.
These are not primarily technology questions. They are design questions, and they are exactly the questions Hammer encouraged organisations to ask.
What This Means for Product Managers
Hammer’s thinking creates a useful discipline for product discovery. Before accepting a requirement, ask what problem the process is trying to solve. Before automating a workflow, ask whether the workflow would be designed this way if the organisation were starting today. Before adding another approval, ask what risk is being controlled and whether this is the best way to control it.
The same discipline applies to reporting and configuration. Before adding another report, ask who uses the information, what decision it supports and what would happen if the report disappeared. Before adding another configurable option, ask whether the team is empowering users or preserving unnecessary complexity.
This is not about saying no to customers. It is about understanding the real problem before building around the visible request. That is the difference between product management and order taking.
Final Thoughts
Michael Hammer’s most famous phrase remains remarkably relevant:
Don’t automate, obliterate.
The point is not that every process should disappear. The point is that every process deserves to justify its existence. Technology has always been most powerful when it allows us to rethink assumptions rather than merely speed up inherited behaviour.
The printing press did not make scribes faster, the internet did not make catalogues cheaper, and streaming did not improve video rental stores. The most significant innovations rarely optimise the old world; they create a new one.
For product managers, that may be Hammer’s most important lesson. Before asking how to build something better, first ask whether it should exist at all. Sometimes the biggest opportunity is not improving the process. It is escaping it.