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. Those people are your team (a topic for another blog post) customers, users, and stakeholders. Let’s take a closer look at those last three.
Customers
The customers of your organization are those whose needs you’re trying to satisfy through building or updating the product. They give your organization money in exchange for some product or service.
In order for that product to appeal to those people, it should satisfy a need they have.
If the product you work on for your organization is the thing you’re selling to your customers, the importance of understanding those needs should be fairly evident.
But what if you work on a product that you don’t sell but rather supports the actual products or services you provide your customer?
What if you work on your organization’s website, mobile app, claims processing application, HR system, or conference submission system?
Customer needs still matter.
Customer Needs and Digital Products
If you work on a website, mobile app or any other digital product that customers directly interact with, your product may not be the thing you sell, but it certainly helps you satisfy your customer’s needs.
Understand your customers’ needs to make sure you make the right changes to the website and to make sure you make the right design decisions for those changes.
Customer Needs and Enterprise Products
If you work on a claims processing app, HR, system, conference submission system, or some other enterprise product that your customers may not even know exists, customer needs are still relevant. You want to understand how your product supports the processes necessary for your organization can satisfy your customer’s needs.
For example, let’s say you work on a claims processing system for an insurance company. Your product supports a process that provides value to your customer. Your customers bought an insurance policy to manage their risk. Something happened and they need the insurance policy to do its job – help them recover financially from an accident.
A customer focused approach to processing claims means you’ll make sure that the process results in the appropriate decision in the shortest time possible.
There is a balance. You won’t approve those claims that clearly fall outside of coverage, because that will result in higher premiums, or an inability to cover risks down the road, which does no one any good.
Focus first on the needs of your organization and you may find yourself inclined to skew the process in favor of your organization, to the detriment of your customers. This may benefit your organization in the short term. In the long run it results in a loss of customers and potentially failure of the business.
Want to build the right thing? Focus on your organization’s customers.
Understanding customer needs helps you make decisions about whether to update or replace an enterprise product and how you approach the changes you choose to make. If the process you are improving is a differentiating activity for your organization, you want to take a unique and creative approach to it. If the process is parity, mimic what already works in your industry.
Knowing which customer needs your organization satisfies helps you determine whether a process is differentiating or parity.
Users
When it comes to determining if someone is a customer, user, or stakeholder, the users are the easiest to classify.
A user is anyone who uses your product. They may be inside or outside your organization.
Ironically in the case of internal products, users are often taken for granted, especially for products used inside organizations.
The line of thought is users didn’t really have a choice whether or not they used a product. It’s their job to use a product, so why care about the experience they had.
People do have a choice. And they can be quite crafty in finding ways around using a product that is a pain to use.
Or they use the product, but they dread it, and that outlook results in mistakes.
What if products for internal use were built with as much thought to being delightful to use as products sold directly to consumers?
People might enjoy their jobs more. They may do a better job. They might treat their customers better. Everyone wins!
Ok, that may be a bit of a stretch.
But improved user experience is a vital aspect to building powerful internal products. It starts with understanding your users, and using techniques to make sure what you build is something they don’t dread using.
Stakeholders
Stakeholders are problematic.
Ok, perhaps I should say that differently. The concept of a stakeholder is problematic.
(Although I know some of you immediately thought “you said it!” and had a particular person in mind.)
Technically, a stakeholder is anyone who impacts or is impacted by an organization’s actions or products. By that definition, customers, users, and anyone inside your organization with an interest in your product is classified as a stakeholder.
That definition of stakeholder isn’t very helpful if you’re trying to differentiate between customers, users, and those internal folks who have an interest in your product.
Since those internal folks who have an interest in your product can quickly become cumbersome I apply the term stakeholders to that group specifically.
Stakeholders play a big part in internal products. If you’re not careful, you can easily confuse them for “internal” customers.
Don’t do that.
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)
The road to bloated internal products is paved (with gold plating) by features added to appease stakeholders, but do nothing for your organization’s real customers.
It’s easy to do. Stakeholders may control access to the users because the users work for the stakeholders.
Or the stakeholders are the users.
It can be very tempting to ask them what they want and just deliver that.
Except that isn’t necessarily going to result in something that’s good for your organization’s actual customers..
You can’t ignore your stakeholders and you can’t focus solely on them either. When your product is used by both stakeholders and customers, the customers needs should trump those of your stakeholders.
Make things seamless for your customers, even if in the short term they may be a little clunky for your stakeholders.
But don’t make it painful for your stakeholders. Remember you want to have a product that your users don’t dread using.
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.
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.
