3 common misconceptions of being customer-centric
Or things that your boss says that make you go, “WHAT!?!”
Ever since the advent of Apple and its customer-first approach, tech companies have strived to be customer-centric. The boardrooms of today are buzzing with words like customer-focused, customer-obsessed or customer advocacy. Unfortunately, the products these companies churn out, fail to meet customer expectations and needs.
In my 9 years of working with retail organizations and their leaderships, I’ve observed that there are 3 things they misconceive on their road to being truly customer-centric. They can be summarized into statements made by leadership, which will serve as the talking points for this article.
“I faced an issue — therefore every customer will face the same issue. Fix it now!”
This is a common refrain heard across product teams — especially from top leadership. The misconception here is that the customer is not one single person — they are made of multiple different personalities and behaviors that vary based on situations and needs. A stakeholder might exhibit the full extent of customer grievance or form only a small subset of this customer persona.
How do you fix it?
The solution is two folds:
- Building a product framework that works well for your organization
A product framework quantifies customer issues/feature requests and balances them with the business needs. It quantifies the impact of the issues and presents an unbiased view of the issues pitted against each other. Remember, you have finite development resources and time — optimally (getting a good mix of better customer experience and business benefit) using it for fixing issues and building features is in the best interest of both the customer and the business. - Educating the top brass on the framework
A framework is as good as the respect it gets from the stakeholders. If your framework prioritizes based on HIPPO (Highest paid person’s opinion), then the framework fails. Getting the leadership & the stakeholders to understand that they are not the customer is an important step in being customer-centric.
All customer-centric organizations exhibit such behavior — if Satya Nadella had an issue with his Outlook, it would still go through the product framework, prioritized and released as per the schedule!
Note: The framework has to have a communication arm: the status of every internal issue/feature request has to be communicated to the reporter, with priority, rationale, and potential release date. It will fail otherwise.
“We identified an issue and launched a feature to mitigate it. Let’s move to the next issue!”
Murphy’s law (for bug fixing) states that every bug fix leads to more bugs. How can you be sure that the feature you released to fix an issue is effective? Customers usually provide a problem. You provide a solution. How do you know that solved the customers’ problem? How do you know that fix didn’t lead to more problems?
Back when I was a product manager for Lenskart.com (eyewear company in India), we figured that entering the eyeglass prescription was difficult (since the customer did not know what the numbers meant!). We devised a simple ‘Understand your prescription’ option that would provide a handy guide to reading prescriptions. Had we left it at that and gone to the next problem, we would have never discovered that prescriptions are non-standard. Thankfully, our framework allowed us to provide a feedback loop to the customer — eventually discovering that there were other types of prescriptions we didn’t account for — and adding those as easy-to-understand prescription types.
How do you fix it?
The fix is simple — build a strong feedback framework. The feedback framework should be part of every feature/fix release and capture simple feedbacks from the customer. Think JIRA and their feedback mechanism — every time you use their new beta feature, you’ll see a tiny little pop-up to the right-hand bottom side asking you to rate your experience of using the feature.
“We cannot launch the website/app without feature X. It is what the customer wants”
In the day and age of MVP, this statement is a criminal offense! One common misconception is that MVP contains as many features as you can afford. MVP’s sole purpose is to create a launchable product, in the shortest amount of time, that delivers customer benefit. The lines are a little blurry, but we should know that quantifying needs and impacts is an important part of this process.
How do you fix it?
Two folds:
- Framework! Framework! Framework!
Every new product should be built with the framework at hand for quick prioritization — feature requests have to come out of the framework with priority values and business impact numbers. - Education! Education! Education!
As product managers, we have to instill within the team the need to quantify. If the statement could be modified to “…. it is what 80% of the customers want and will bring in a 40% increase in revenue”, it would be something to consider.
Note: The onus of proving the impact is on the reporter.
As we saw, the key here is a framework. Framework is not process. Framework isn’t a set of approvals that go up the chain and then down the chain. Framework removes the biases (personal/business/hearsay) and presents a clear picture of the next steps. Read on for prioritization frameworks.
Do you hear similar phrases in your organization? I’d love to know how you handle customer centricity! Thank you for reading.
