Product development – whether it’s products for sale or internal products – is ultimately an exercise in working with people.
To make it fun and interesting, those people have a wide variety of perspectives and have different relationship with the product.
People with different perspectives about your product
There are those who develop your product. They make up your team, and we’ll talk about them a different day.
There are those whose needs you’re trying to satisfy through building or updating the product. These are the customers of your organization. They give your organization money in exchange for some product or service. In the case of internal products, the product you build enables that exchange but is not itself sold to your customers.
There are those who use your product. In industry parlance, they are referred to as users. They may be inside or outside your organization.
Then there are the people who have a part to play in satisfying your customers needs and may interact with your product in some way. They may be inside your organization, or they might be partners. I’ve taken to using the term stakeholder in a specific sense to refer to this group of people. They might also be users. They are not customers.
Why it’s important to understand these different perspectives
It’s important to understand these different perspectives because they have a different part to play in your overall effort to introduce powerful internal products.
You determine the right thing to build in a broad sense based on what will satisfy your customer’s needs. You may struggle to decide whether to favor what’s best for your customer or best for your business. If you favor what’s best for your customer, that will ultimately be what’s best for your business.
You consider users when you make design decisions. You want to build your product in such a way that people choose to use their product if they have a choice, and people look forward to using it if they don’t have a choice.
Your stakeholders introduce considerations in the form of constraints, risks, assumptions and dependencies into what you build.
Stakeholders may be directly involved in satisfying your customers needs and look to your product to help them do that. If you’re working on your organization’s website or mobile app (now commonly lumped under the term “digital”) you’re in this situation.
Stakeholders may work on internally focused business processes and don’t interact directly with your organization’s customers. If you work on something like an HR or accounting system, you’re in this situation.
It’s the second situations where being explicit about the difference between customer and stakeholder is important. Rich Mironov pointed out what happens when you confuse stakeholders for customers:
- Budgeting replaces prioritization – decisions about what to (or whether to) build for internal organizations is based on spending a budget (spend it or lose it) rather than considering priorities across all the possible activities.
- Scorekeeping is based on delivery dates rather than business outcomes – success is measured on whether something was delivered by an arbitrarily determined date rather than according to specific business objectives.
- Short term trade-offs accumulate over the long run – because it’s intended for use inside the organization and we’re very focused on delivery date, there is a large temptation to forgo good engineering practices (automated tests, usability, clearing up technical debt in appropriate places)
Use the impact on actual customers to determine whether to undertake work for those stakeholders and the degree to which you perform that work. The purpose based alignment model is helpful here.
Once you’ve decided the extent of the product you’re building it certainly may be helpful to view your stakeholders as users – if they in fact are.
The key point: you should understand the relationship people have with your product and the perspective they hold, and then work with them accordingly.
In this issue, I’ve included some resources that you may find helpful for identifying the difference between customers, users, and stakeholders. In subsequent issues of Inside Product Management, we’ll explore customers, users, and stakeholders in more detail.
The Product Owner Guide
Do you have your CSPO but still have questions when you run into various day to day situations?
Do you find yourself searching for practical tips on how to refine your backlog but are overwhelmed by the suggestions you come across?
Do you wish you had a place you could go to learn about specific product ownership techniques when you need to use them?
Do you wonder if other product owners have done when they faced the challenges you’re facing?
Then you may be interested in the Product Owner Guide. KBP.media is in the process of compiling the Product Owner Guide, a just in time resource of product ownership tips, techniques, and experiences to help product people create powerful internal products.
If you’re interested in learning more about the Product Owner Guide, sign up to be notified of when we’re open for subscribers.
Abandon the terms Customers and users, not the actual people
Rich Mironov’s post suggesting you should abandon customers and users (not in the way you think) clarified a lot of things for me on the subject. I mentioned his thought that there really isn’t such a thing as internal customers. That nugget was actually in a post script rant.
The primary point of the post was that you’re well served to be avoid using generic terms customers and users and instead be specific about who they are (unless you’re talking about the abstractions of customer and users in a newsletter of course). I’ll explore that more in upcoming issues of Inside Product Management.
The important difference between users and customers.
Products for sale have a much easier time differentiating between customers and users because they can think about who buys it and who uses it. When you’re talking about internal product, it’s more difficult.
Marc Shiller provides another reason to be precise when you refer to users, customers, or stakeholders. This reason is particularly relevant for those in an IT organization.
The Law of the Customer
In this video from Business Agility 2017, Steve Denning discusses the three laws that are key to sustaining business agility: the law of the customer, the law of the small team and the law of the network. The law of the customer is the relevant one here: an agile business focuses on delivering value to customers, which means they satisfy their customers’ needs.
Customer Experience and User Experience are different.
Did you know there was a difference between customer experience and user experience? Do you know what it is? Briefly stated, user experience looks at someone’s relationship with a specific product. Customer experience looks at a person’s interaction with the organization that provides that product.
Thanks again for subscribing to Inside Product Management.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email.
Plus if you think someone else would get some value out of the newsletter, let them know they can sign up and get a free copy of Product Ownership in the Wild.
Talk to you next week,
Kent J. McDonald