How Passing the Buck sets a Product Team up to Fail
One of the most painful reasons why a product team fails in their aims often has nothing to do with their performance. It’s because they’ve been set up to fail.
We’re all familiar with the term, ‘passing the buck’ and how people evade or reassign responsibility to somewhere or someone else. Senior execs do it to product teams all the time.
I’ve seen it happen to many product people in different ways over the years. Perhaps you can spot some of the patterns below in your own organization and take action before they have an impact on your work.
Product management always takes the hit
You see it in companies where the bosses set expectations like unrealistic deadlines and then pressure the product team to stick to them. The team then has to struggle to get things out on time, even though it wasn’t their call in the first place.
Product teams could pass the buck to the development team – after all, they’re the ones who build and come up with the estimates that always seem to slip. But PMs always seem to take the hit for everyone else – and I think proudly so – I wouldn’t want to be advocating for a role that was known for throwing its teammates under the bus. Rather, PMs are known for defending the time of their developers (and designers), helping to get them breathing room and much-needed air cover.
On the flip side, however, product managers often don’t get the same consideration from the rest of their organization, with the most notable offenders being sales teams and the executive team.
Sales teams may well ask for features to be built, rather than selling what they have. Saying they can’t sell the product until X feature is delivered puts all the pressure on the product team – but the sales team should take responsibility and learn to sell or reposition what they have. It’s easier for salespeople to expect the product team to add what they feel is missing. (And don’t get me started on the salespeople who sell things that don’t exist and dictate the roadmap!)
Executives with a badly formed business plan or model put the product team in a difficult position. A classic example is the agency trap, where the company (usually for short-term cash gains) accepts custom project/client work, while also expecting the product to develop at speed. But the product team only has so much time, and can’t do client project work and product discovery and development work at the same time, especially if the client work leads to a stream of deadlines to hit. And it’s not the product team’s decision or fault that they’ve ended up in a delivery-focused way of working. It’s been foisted on them by poor decisions at the executive level.
Unreasonable reliance on the product team
To be clear, the management team is responsible for creating a viable business and workable company strategy. But sometimes they over-rely on the product team to create something that doesn’t yet exist, in timeframes that they can’t know are reasonable (let’s be real: you and the dev team are still working out the scope of this thing, never mind how long it will be before you’re able to deliver). By doing this, management absolves itself of the responsibility of creating and maintaining a viable business, brushing it off as the product team’s problem with no consideration of whether it’s achievable. I’ve seen some teams given ridiculously tall orders.
A company strategy should encompass a realistic product strategy (plus realistic marketing strategies, tech strategies, and so on). It’s not a good strategy if it relies on miracle workers to make it happen or if it’s dogged by insurmountable problems. The execs shouldn’t just ‘pass the buck’ on their bad decisions or bad planning to their product team and hope that the team figures it out.
How do you stop it?
The product team must call out this passing the buck when they see it. To be able to do this product people must understand the wider company strategy and where the product strategy fits in it – it’s one of the most valuable things a product person can do.
They should also understand who’s had a say in product strategy and where some of its assumptions came from. Was the strategy handed to the product team, or did they play an active role in defining how they could help the company reach its goals?
If there’s a sense that others are ‘passing the buck’ to the product team, then call it out and set boundaries. If you don’t, then the product team risks having more work pushed at them, setting them up for failure further down the line. For example, if you keep agreeing to custom client work, to the detriment of discovery work, you set a precedent that you will always accept project work… and the core product will never progress and the company won’t move towards its ultimate goals.
Calling it out helps management and other team members to see the broken parts, like missing resources or misdirected efforts, so that they can help to correct them.