A client once told us they wanted to implement "industry best practices" across their operations. When we asked what that meant, they said: "Whatever the top performers in our space are doing."
This sounds reasonable. If the leaders are doing something, it must work. Why not copy it?
Because best practices are context-dependent. What works for a $500M business with 800 employees doesn't work for a $20M business with 60 employees. What works in a high-velocity transactional business doesn't work in a complex enterprise sale. What works when you have market dominance doesn't work when you're fighting for share.
We see this most often with process adoption. A company reads that Amazon uses a particular planning framework, so they try to implement it. Or they hear that a successful competitor restructured their sales org a certain way, so they copy the model.
Then it doesn't work. Not because the practice is bad, but because it was designed for different constraints, different capabilities, and different goals.
Here's an example: A mid-market software company wanted to implement account-based marketing because they'd read it was a best practice for enterprise sales. They hired a consultant, bought the technology, and launched the program.
Six months later, pipeline hadn't improved. When we looked at it, the problem was obvious: they didn't have enough target accounts to justify the overhead. ABM works when you're focused on 50-100 high-value accounts. They were trying to do it with 800 accounts, which meant the "personalization" was just mail merge with a fancier tool. They would have been better off with a simpler, higher-volume approach.
The best practice wasn't wrong. It was wrong for them.
The same thing happens with organizational structure. Companies see that a competitor reorganized around product lines instead of geography, so they do the same. What they miss is that the competitor made that change because their products had become differentiated enough to require dedicated go-to-market strategies. If your products share the same customers and sales process, reorganizing by product just adds complexity without benefit.
Best practices are useful as hypotheses, not mandates. They tell you what's worked for others in similar situations. But similar isn't the same. You need to understand why a practice works, whether those conditions apply to you, and what you'd need to change to make it work in your context.
Here's a better approach:
Understand the problem the practice solves. Why did the other company adopt it? What were they trying to fix? Is that your problem too?
Assess whether you have the prerequisites. Does the practice require capabilities, resources, or scale you don't have? If so, can you build them, or do you need a different approach?
Test before you commit. Pilot it with one team, one region, one product line. See if it works in your environment before rolling it out everywhere.
Most companies skip these steps. They see the practice, assume it will work, and implement it at scale. Then they're surprised when it fails or produces mediocre results.
The goal isn't to do what others do. It's to solve your specific problems with approaches that fit your specific context. Sometimes that means adopting a best practice. Sometimes it means ignoring it entirely and building something custom.
Strategy isn't about copying. It's about choosing what works for you.
