I’ve been working in, with and around product organizations for more than 20 years now. Over time, as with all things, patterns reveal themselves in the work. Sadly, and despite the relentless efforts of those of us out there promoting continuous improvement, agility, learning and deep customer empathy, a set of patterns continue to manifest in nearly every organization I’ve come across in spite of their externalized efforts to be “customer obsessed.” It was hard distilling this list into only 10 of these anti-patterns (in fact, I failed, there are actually 12 in this article) but I feel that these are the most prevalent and the ones that, if improved, would make the most difference to organizations competing in today’s uncertain, rapidly changing world and business environment. Without further ado, the 10 most common challenges to building a customer-obsessed organization.
Misaligned incentives
Your teams will optimize for what gets them paid, promoted and celebrated. The overwhelming majority of organizations incentivize shipping product above all else. This is regardless of any proven need, customer insight nor validation of the validity and value of the proposed solution. Teams aren’t incentivized to understand the customer so they don’t do it. Instead teams build and ship blindly hoping what they put into the market will work.
Learning is not a priority
If incentives drive building and shipping, any work that isn’t that gets deprioritized. Eventually learning and discovery activities are deprioritized enough that they cease to be discussed. What’s the point? Teams continue to build on based on unproven, risky assumptions about their customers’ needs, motivations and measures of success.
No cross-functional collaboration
Discipline specific silos constrain information flow from engineers to product managers to designers. Each discipline has its own motivations and incentives creating a lack of alignment around the most important part of the work – the customer. Even if one discipline gets some insight about customer needs it will likely conflict with another discipline’s priorities typically relegating it to the rubbish bin.
Underuse of in-house research team
If you do work in a company that is lucky enough to have an internal research team you should find yourself with a leg up on those that don’t. However, all too often these research are underused either to determine pixel-level solution approaches (something other folks on your team can likely do just fine) or they’re sent down months-long research engagements whose findings arrive too late to be implemented, if their findings are even considered at all.
Lack of humility
While many leaders don’t put their humility on display, this is most often a condition of companies who have seen some success. A lack of humility in the way leadership teams approach their work ensures a decreased interest in the current needs of the customer in favor of prescriptive solutions based on historical information and success tactics that worked in the past. Humility isn’t the abdication of leadership. Instead, it’s a realization that the world we’re working and living in is in a state of constant change. What worked in the past isn’t likely to have the same impact today as it did the last time we deployed it. The sooner we can figure out how the world has changed since our last success, especially with our customers, the sooner we can solve the problems those customers have today, not the ones they had months or years ago.
Too much Theory X, not enough Theory Y
McGregor’s management theory of Theory X management vs Theory Y management is prevalent today, despite being authored more than 60 years ago. Theory X states that managers should prescribe solutions to teams, have no need to trust their teams and should punish them for any mistakes they make. This leads to teams doing exactly what they’re told without any critical analysis and consideration for the facts on the ground or what they’re hearing from customers. Theory Y promotes team autonomy, trust and job satisfaction. It assumes that you hired smart people and that you’ll let them do their job without the fear of punishment. Teams managed with Theory Y seek information to make their products better, including the needs of the customer.
Agile and process theater
Every organization these days, when asked, says they’re “an agile organization.” These new ways of working (Agile, Scrum, SAFe, OKRs, product discovery, design thinking, Lean Startup, et al) are brought in and lauded by the company’s leadership team. However they are only ever implemented and taught at the individual contributor and team levels. Management teams then continue to make the same demands they’ve always made on their teams along with the same incentives (see the first challenge) sabotaging any positive, customer-focused outcomes these processes promise.
Fixed, annual planning cycles
The world moves faster than 1 year cycles. Change happened daily, hourly. Trying to nail down a year’s worth of work, risk and ROI in advance is an exercise in futility and, frankly, fabrication. Everyone knows this but no one seems motivated enough to change it because it’s the “way we’ve always done it.” Fixed plans naturally repel curiosity about the customer because, inevitably, deeply understanding the changing needs of customers will conflict with the plan. There was a large investment to get it locked in and approved. Anything that risks the plan is somehow a greater risk than not meeting current customer needs.
Lack of psychological safety
The teams building the products are closest to the work and the customer. They regularly learn how well their solutions are performing today and how they’ll do in the future. This insight often conflicts with the plans those teams have committed to. If these teams don’t feel safe sharing what they’ve learned and the impact it will have on The Plan they’ll continue to build solutions they know are no longer relevant to the customer. This is a waste of everyone’s time and ensures that our products will be less successful and our teams less motivated to do great work.
Teams don’t understand their business model
All too often teams are building products without understanding the customer’s role in the org’s business model. Without that understanding teams end up building whatever is handed down from executives without a sense of how that work will impact customer satisfaction or retention. It’s these outcomes, like retention, that keep the company in business. This is particularly prevalent in content, social media and B2B2C companies who mistake the users of their products for their customers.
If you’ve made it this far, thank you. Just for you I’ve added two bonus challenges that I see regularly.
Bonus 1: No access to customers
When they try to reach out to customers, product teams find nothing but organizational obstacles. Whether it’s the sales team worried about “too many touches of the customer” or the legal department concerned about what you’ll say or commit to inadvertently, hurdles are everywhere especially in large organizations. You can’t be customer obsessed and now allow your teams to have customer contact.
Bonus 2: Teams don’t know how to do product discovery
Even if they are allowed to talk to customers, many teams don’t know how to conduct interviews, write surveys, run lightweight experiments or synthesize their findings into clear next steps. The data they do end up collecting becomes less valuable leading to similarly risky decisions about product improvements. (Coincidentally, or perhaps not, I teach product discovery to teams.)
These anti-patterns are consistent. I’ve been seeing them for two decades and continue to see them today. That doesn’t mean they’re insurmountable. There’s been a mountain of work done to prove out better ways of working. The first step to improvement is recognizing these patterns in your own organization. The next best step is to take them on, one at a time, and see how your teams’ behaviors change over time. The next improvement should be with your products and eventually with your customers.
(Next week, I’ll write a post that provides at least one tactic to help alleviate each of these solutions. Stay tuned here or sign up for my newsletter to get it in your inbox. It’s free.)
Hey Jeff! Enjoyed the article – well articulated pointers which I faced myself. Thanks.
The last line on the Bonus 1 appears to have a typo:
[… “now” allow your teams to have customer contact]
Seems like you meant “Not”.