Do Product Owners Know Who Their Customers Are?
Unfortunately, many Product Owners confuse stakeholders with end-users. Without interacting with real customers, pointless products are…
Unfortunately, many Product Owners confuse stakeholders with end-users. Without interacting with real customers, pointless products are built.
Why do many Product Owners confuse stakeholders with customers?
This massive misconception shocks me. For over a decade working with Product Owners, I’ve observed that many Product Owners have never talked to a real end-user. Yet, they wouldn’t agree with me because they perceive the stakeholders as the end-users.
Until Product Owners understand who the end-users are, they will be no more than a requirement keeper.
Unless you work with an internal product, stakeholders are not your end-users. On the contrary, stakeholders are your partners.
Let me share with you some insights on how to avoid this trap.
Why Do Product Owners Confuse Stakeholders With The Customers?
Many times Product Owners are victims of the circumstances. Unfortunately, until now, several companies consider technology to be a support area to the business. This scenario leads to a service provider relationship between stakeholders and Scrum Teams. The business stakeholders decide what to do, and the Scrum Team executes.
Technology is not a means to an end anymore. Technology is the business. Numerous companies are disrupted because executives fail to use technology to innovate. To remain competitive, companies have to empower Scrum Teams.
“I discovered that there was a tremendous difference between how the best companies produced products, and how most companies produced them.”
― Marty Cagan, Inspired: How To Create Products Customers Love
As a Product Owner, you might not face a fruitful scenario waiting for you to innovate. Therefore, you have a choice to make: you either accept the status quo or do whatever it takes to build meaningful products.
In my opinion, if the rules are not in your favor to solve the customer’s real problems, you might need to break the rules. As a Product Owner, you have to be relentless if you want to succeed.
Stakeholders Are Not the Customers
How Product Owners perceive stakeholders is a crucial factor for their success. I’ve come across three misunderstandings that hold Scrum Teams back from succeeding:
Customers: business stakeholders are not the end-customers. However, many times these stakeholders pressure the Scrum Team to deliver on their wishes. They might insist they know what the customers want, yet they are not the customers.
Bosses: some stakeholders might be high-level executives, directors, managers, or someone with leadership responsibilities. Still, they are not the bosses of anyone from the Scrum Team. Scrum has no hierarchy.
Enemies: the relationship between stakeholders and Product Owners can be complicated. Stakeholders may take political actions if they don’t get what they want. Such behavior may create a heavy tension between the Product Owner and stakeholders. Yet, stakeholders and Product Owners should be partners instead of enemies.
But what is a stakeholder? A stakeholder is a party interested in a company and can either affect or be affected by the business.
Although business stakeholders might be knowledgeable in their domain, they are not the customers. Product Owners need to understand how to develop a sustainable relationship with stakeholders. Trust is the basis of everything. Without trust, a sustainable relationship is impossible.
“Trust is the function of two things: competence and character. Competence includes your capabilities, your skills, and your track record. Character includes your integrity, your motive and your intent with people. Both are vital,” — Stephen Covey
Instead of gathering requirements with business stakeholders, Product Owners should establish a strong partnership with them. I perceive stakeholders as enablers for Scrum Teams to succeed. Product Owners don’t know everything, for example, legal aspects, marketing, logistics, etc. A strong partnership with the stakeholders can enable a powerful solution for the end-user.
First Comes the Customer, Then the Problem
How often do you meet with your customers? If you ask this question to Product Owners, you might be surprised with the answer.
Until you understand your customers, you cannot solve their problems. It’s easy for Product Owners to fall in love with the solution. But it takes a while to accept the product we are working on is not for us, it’s for our customers. Before you start working on any solution, you have to invest enough time to know your customers.
“User research, observations, surveys, and customer feedback are all tools that you can harness to explore the problem from a user standpoint better.”
― Melissa Perri
Product Owners should strive to find problems worthwhile solving. Before jumping into solutions, you have to clarify the problem. A way of doing that is to do experiments with your customers. This technique is known as Product Discovery.
“Product Discovery — a rapid series of experiments, primarily using prototypes, that enable us to us to discover effective solutions to the problems our team is tasked to solve.” — Marty Cagan
When the Product Discovery is performed correctly, you will get the answers you need to focus on meaningful solutions.
Valuable: can the end-users benefit from the solution?
Usable: is the usability natural for your end-users?
Feasible: can the Scrum Team implement the solution?
Viable: does the solution generate the needed business value?
If your solution is valuable, usable, feasible, and viable, you have found an opportunity worth pursuing.
Don’t be scared by the Product Discovery; be afraid of building something meaningless. The discovery process doesn’t need to be heavy. On the contrary, the faster you can learn, the quicker you can succeed.
Your company doesn’t pay your salary. The money from the customers of your company do it.
Only the Customers Know Their Problems
I’ve been in multiple situations where stakeholders insisted on implementing specific features. They claim to know what the customers need precisely. You should be extremely careful with proxies. The hard way, I learned that only the customers know their problems.
It’s painful to invest time in building something worthless for the end-users. Suppose you are enthusiastic about presenting the newest cool feature you have. Then, once you get feedback from the real end-users, you are surprised when they say, “Wow! This feature is cool, but it doesn’t solve my problems.” How can you avoid such dreadful situations? Let me give you some suggestions:
Understand what your business stakeholders know: before jumping into the execution mode, you should understand what the stakeholders know that you don’t. Are their requests based on customers’ needs or stakeholders’ wishes? Remember, your customer is the end-user, not the business stakeholders.
Validate the assumptions: knowing what you don’t know is vital for you to avoid failures. Confidence is essential but dangerous at the same time. When you are confident you know how to solve a problem, you should step back and ask yourself, “Is it an assumption? How do I know that this solution is relevant for the end-users?”
Observe your end-users: don’t expect the customers to tell you what they need. They might tell you what they want, yet, that might not be what they need. The best way to understand the underlying needs is by observing the customers, search for opportunities to make their lives a little easier. Remember, the solution is for the end-user, not for you.
Wrap Up
Technology is advancing faster than ever before. Applying the old ways of working will not lead any team to reach its maximum potential. Executives have to stop treating tech teams as a support area for the business. It’s time to empower the Scrum Teams to innovate.
Product Owners have to strive to empathize with the real end-users. Stakeholders need to act as enablers instead of pressuring the Scrum Teams to implement wishes.
“It doesn’t make sense to hire smart people and then tell them what to do. We hire smart people so they can tell us what to do” ― Steve Jobs
Do you want to write for Serious Scrum or seriously discuss Scrum?