Following the herd in leadership produces exactly what chasing benchmarks produces in product: average results, because you are optimizing for what others have already done rather than for what your specific situation requires. The leaders who build something durable make decisions based on honest analysis of their own situation - not on what they observe someone else doing in a different situation with different constraints.
When the herd ran toward the same wall
When the dotcom bubble burst in 2001, most digital agencies did the same thing. They cut costs, pitched whatever clients were still spending, and tried to ride out the downturn doing what they had always done. That was the herd answer. At Embarc, I bought out the executive team and took a different path.
The pivot was not contrarian for its own sake. It came from looking honestly at two things: what we were actually good at, and where demand was moving despite the downturn. Boston's biotech and pharma sector was insulated from the dotcom collapse in a way that most tech clients were not. Healthcare companies were still building, still needed digital infrastructure, and were underserved by agencies that had spent the previous five years chasing dot-com clients. We repositioned Embarc entirely into that sector. It worked well enough that we eventually sold to a firm in Philadelphia looking to expand their reach.
The decision required turning down work we knew how to do and pursuing clients we had no track record with. That is never comfortable. But the herd in that moment was running toward a wall - fighting for a shrinking pool of tech clients with shrinking budgets. Getting out of the way of that was not a bold strategic bet. It was just an honest read of the situation.
The imitation trap in product
At EditMe, my co-founder Matt Wiseley and I had a version of this disagreement. The SaaS wiki market was consolidating around a few dominant players - PBwiki was the one everyone watched. The conventional wisdom was to follow the feature roadmap of whoever was winning. Match their capabilities, then find ways to differentiate on price or positioning.
I kept pushing us in a different direction. Our actual customer data showed we were winning in a specific segment - nonprofits and small businesses - where PBwiki was not particularly focused. These customers had different needs, different budgets, and different reasons for choosing a wiki tool. Chasing PBwiki's roadmap would have meant abandoning the only ground where we had a genuine advantage. It would have made us a worse version of a product that already existed, rather than the best version of a product that served a real underserved segment.
We went narrow. PC Magazine gave us an Editor's Choice. We grew to about 5,000 customers at $5 a month before eventually being acquired. None of that happens if we spend the year building features to match a competitor serving a different customer.
Imitation feels like learning. Sometimes it is. More often it is a way of avoiding the harder work of figuring out what is actually true in your specific situation.
Benchmarking as a substitute for thinking
One of the more consistent patterns I see in fractional engagements is benchmarking used as a substitute for decision-making. A head of product will come to a session having surveyed five peers at similar companies about how they structure their planning cycles, what their roadmap tools look like, how they handle engineering relationships. The data is genuinely useful context. But the instinct behind the research is often avoidance - gathering external validation rather than making a hard call about what is actually true in their own organization.
I was working with a head of product at Capsule - a fintech CRM - who was doing a version of this. She was spending real energy tracking what other fintech product leaders were doing: org structures, prioritization frameworks, how they managed the relationship with engineering leadership. Some of it was relevant. Most of it was noise that kept her from addressing the actual tension in her own situation: a CTO who was making architectural decisions without her input and a CEO who had not drawn clear ownership lines between product and engineering.
No benchmark was going to solve that. The problem was specific to her company, her leadership team, and the particular ambiguity in how decision rights had been left undefined. She had to name the problem and decide what to do about it. That required independent judgment, not additional data about what other fintech PMs were doing.
Independent judgment is not comfortable
Independent leadership judgment requires breaking out of the local maxima at the personal level - being willing to give up a comfortable position or a conventional approach when the evidence points elsewhere. That willingness is the underlying trait. The specific decisions are just expressions of it.
Repositioning Embarc into pharma, going narrow with EditMe, helping a fintech PM name a conflict she had been avoiding for six months - none of these were confident, obvious decisions at the time. They were bets made on genuine analysis of specific situations, not on what the surrounding market was doing.
The question is not what other people in your role are doing. The question is what your team, your customers, and your situation actually require. Those are almost never the same answer. The leaders who build something durable steal ideas aggressively. They do not steal strategies wholesale. Strategic thinking is the capacity to make that distinction under pressure, when the herd answer is right there and available and feels safe.
The leaders I have watched build something durable share one characteristic: they make decisions based on what they actually know about their situation, not on what they observe someone else doing in a different situation with different constraints.
