The problem of Proxy Users

User Stories - what's a user story, what's even a user? And: Why is that important?

The definition of a "user"

User - a person who uses or operates something.
Sources: Oxford, Google

A "person" can be both an individual or a legal entity.
The specific mention of the term "person" is quite important. We will get back to that later.

There are other definitions out there, also - that have a different emphasis:

User - a person or thing that uses.
Sources: Dictionary.com, Collins Dictionary

This definition opens a different way of thinking - that "things" (physical and/or virtual objects) can be users s well.

Types of "users"

There are various types of users.

To explain them, let's take a look at this scenario:

Scenario:
A person has bank account without any deposit money.
The problem? Checks bounce on this empty account.

Here are some core types of potential users and their problems in this scenario:

Category	Description	Example
End user (Customer)	Someone whose problem is being addressed.	Bank client: Bouncing checks means there is unpaid debt.
Service Provider	Anyone who provides a service using the product.	Bank: May get calls from both their customer and the people their customer gave checks to, asking what's wrong.
Intermediary	Representative of the Service Provider towards the person whose problem is being addressed.	Bank clerk: The person at the counter, answering on behalf of the bank what's happening.
Proxy	Representative of the person whose problem is being addresed.	Bank account: A virtual entity that acts as a proxy on behalf of the customer both towards the bank and the customer's transaction partners.
Delegate	Acting on behalf of the person whose problem is addressed.	Accountant: Responsible for balancing the customer's finances.
Administrator	Responsible that the product or service can be used correctly.	Bank IT: Checks need to be rejected rather than processed.

Why is the discrimination between those "users" important?

Know your Users!

Users define success

For example, if you develop in-house business support software, your user is often a single company, which means you'll have an entirely different way of measuring success than if your user is a Customer on the free market (of whom there could potentially be a couple billion). And the value of your product may depend on two categories of users: the Service Provider, whose balance sheet ultimately determines whether you are building the right product - and the Intermediaries, whose use of the product determines whether you are building the product right.

Users want their problem solved

Especially in large corporations, it's easy to lose sight of what the product actually is - and who the users actually are. By solving the wrong user's problems, you run the risk of local optimization - potentially damaging the interests of your real users in the process!

For example, look at this rather typical "User Story":

As a Security Specialist, I want people to choose difficult passwords and short password renewal cycles, so that accounts stay secure.

Then, think of yourself: How would you like it if the engineering team of your favorite app would spend a month to create password rules so complex that you need a PhD in Cryptography just to be able to determine what's a valid password - and then being forced to choose a new, different password every time you log in!

Solving the right problem

Intermediaries, proxies and administrators pose requests on systems, and while their requests are undoubtedly important, they all don't help you to solve the right problem!

Compare, for example, the following two user stories:

As a bank clerk, I want to be able to see the customer's balance with a single click.

As a bank, I want to know why I'm losing customers!

And now, let's add another user story:

As a bank account, I want to let my customer know when I have no money!

Do you see the difference between those three stories?

Users who have no financial stake

The first story may have sprung up from a conversation with a real intermediary user, and it's fairly easy to know whether you are solving this problem. However, it's almost entirely disconnected from the real user's (the customer's or the bank's) problem.
Unless it just by happenchance occurs that seeing customer balance also addresses the second problem, there's a good chance that spending time with the concerns of intermediaries derails the team from relevant business objectives.

Users that don't have a voice

The second story is an existence-threatening problem. Yet the "bank" as the legal entity that gives employment to the engineering team, has no face or voice. Its true voice may be hidden behind layers of management and bureaucracy. It may be too far away from the engineers to give it relevance and too abstract to be worth touching.

Proxies have no real needs

The third story is all too common in large enterprises: Components, proxies - even API's become "users" - assuming that if we service them, we are solving a relevant problem!

There are no proxy problems

Here's an uncomfortable truth: the proxy has no problem.
It's never the proxies' problem - it's ultimately, a customer or provider problem.

Only when real users (end users and/or providers) interact in a way that requires interacting on a path that crosses the proxy, is there a real problem. And there are two ways of solving this problem: either helping the proxy to do their job better - or to eliminate the proxy's part of the process altogether.

Hidden assumptions

There are always hidden assumptions in proxy stories:

1. The voice of the proxy echoes the voice of the unheard real user
2. The proxy is on the critical path of transactions 
3. The proxy is the constraint to the performance of the system
4. A dependency on the proxy is inevitable
5. Solving the proxy's problem is the best solution to the real probem

By accepting the "story of the proxy", which most agile teams do with little pushback or thought, we run a massive danger of sub-optimizing a solution, and limit the solution space. While this can be valid in many cases to provide focus, this begs the question: When, if not during refinement or planning, does the team spend time to think of which solution is the best to solve the most pressing problem?

Working the Constraint

The reason why I harp so strongly on the point of "proxies" and "intermediaries" versus "real users" - is that while they are on the road to creating a higher-performing system, it's nowhere automatic that improving upon their bidding improves the performance of the system.

Theory of Constraints teaches us that:

1. Optimization outside the Constraint is - at best - ineffective.
2. Time spent optimizing outside the Constraint is Waste.
3. To work on the Constraint, you need to know how to optimize it.
4. When the Constraint is operating at its capacity - elevate it!

Here's what happens when you listen to the voices of Intermediaries or Proxies as if they were the real users:

1. You start to forget who the Real User is.
2. You remain oblivious of how the changes you are making affect overall performance.
3. You don't know if you're working the Constraint or somewhere else.
4. You may institute a new Constraint on the Critical Path, worsening the system.
5. You will miss solutions that elevate the constraint, especially if the constraint is of higher order.

Summary

It's not forbidden to have "proxies". It's just dangerous. 

To avoid the most common pitfalls, start asking:

• Do we understand the real customer behind the problem we are solving?
• Is the solution on the critical path to success?
• Are we working the Constraint?

If you can't answer these questions with a clear and resounding "Yes", you're definitely in dangerous territory - and if you can answer any them with a clear "No", you may want to reconsider implementing this story to begin with!

The problem isn't as much who your user is - it's that "fake users" make you lose sight of what value is and how to create it!