Pages

Thursday, April 14, 2016

Know your customer!


The Agile Manifesto states "Customer Collaboration over Contract Negotiation". But that's not easy to practice without understanding who the customer actually is.
As organizations grow, the question "Who is the customer?" becomes increasingly difficult to answer, and the answer is often hidden in plain sight. 
In this article, we will discuss how to identify and classify customers, using the practical example of an e-Commerce Platform.



Product Customers

The most obvious category of customers are those who actually use the product. However, even they come in two categories: Those who actively go out to use the product - and those who get to use what others got for them.

Primary Customers

This is the kind of customer you can actively reach out towards. When they like the product, they will be generating revenue for you. It's a good idea to build a direct feedback cycle with them.
These could be web users who like to do online shopping.

Secondary Customers

This is the kind of customer you may not even know to exist. Whether they like the product or not is out of reach. If anything, they would give feedback to the Primary Customers - but you don't have much control over that.
These could be the workers in a company who has decided to get their supplies from our online shop.

Value Stream Customers

How does the value stream "Order to cash" map for your company? Typically, it's not the same people who have an idea, deliver it - and have to live with the consequences. In big companies, ideas are collected, then brought into a type of solution design, then implemented, launched - and then become "business as usual".
Depending on how your organization looks like, that will usually involve different departments, teams and people. Each person involved in product creation has a place in the value stream, and to know "who will receive the result of my work" is a good idea. These people are the value stream customers.
Yes, they are also customers! Life can be quite miserable if you ignore this fact.

(Other) Internal Customers

Sometimes also called "Stakeholder", but let's be explicit here. These are people in the company who actually want something from the product and who will usually assign a portion of (their) company budget towards the realization of a request.
For example, that could be Marketing or Sales desiring access to business performance metrics - or Customer Service asking for a functionality reducing the amount of service calls.
These people usually do not actively use the product, but they do have an important impact on how it is being used.
Since they are in the "large" revenue chain of the Product and receive services from Software Development, they are clearly also customers and it's a good idea to keep them happy for mutual benefit. One thing you should never forget: They do not actively create value for the product, they merely assist in value creation. No matter how many features you build for Marketing, there is no benefit unless you actually see an increase in Product Customers!

Indirect Customers

Living in a society, there is a whole bunch of people who neither want your product, buy your product - or even care about your product, but still place demands on your product.
For example, that could be the Better Business Bureau, the legislature around Data Security - or even the IRS. There is no way to "Please" these customers, but they will kill you if you don't fulfil their requests. The best thing to do is invest minimal effort to keep them off your back.


Summary

In large organizations, the relationships between supplier (you) and customer are often either unknown or agreed in contractual form. If they are unknown, there is a huge risk of misfiring. Hand-Over Contracts (responsibility lists) are good to create transparency, but do not help to solve problems or grow the business. To be successful, you have to go beyond the contractual level with your customer - and collaborate with them for mutual benefit.
The simplest Customer relationship every Scrum team should be aware of is that with the PO. The interface contracts are Definition of Ready (PO => Team) and Definition of Done (Team => PO). There are more customers - how do you handle your relationship with them?

No comments:

Post a Comment