During some years, I was a functional architecture, working closely with business teams like product owners or field experts. I was both in waterfall and agile projects with cross-competencies teams. I met true users of the application I designed. I defined typical use-cases, personas, … Really classical stuff.

Thinking of this period, I understand that the “user” everyone claiming to serve doesn’t really exist. It is more a myth, a legend that we have invented in order to be able to design our application.

But, my user is the one who is using my application!

As a first approach, we used to be taught (and we used to teach) that we develop an application for someone.

Following scrum methodology for example, we create persona which represent typical users of the application.

However, we can already notice some inconsistencies. First of all, we create abstractions of true users. On an application, you can have thousands to millions promo using it daily. To be able to understand their needs, you have to simplify them.

Second point, how do you design persona for a new application. Two cases: professional application and public application. In the first case, users can be identified. The application will be for them. It is the easiest case, because the perimeter is defined (the company for which the application is developed). In the second case, you choose a market and hope that those users will be the one who will use your application. However, you often have to “pivot”, as stated by lean startup, to find the “market fit”.

Well, my user is not really the main user

On a company I used to worked before, a new rule has been introduced: go to the field and meet “true” users (insofar they truly exist).

Why does such a rule exist? Does that mean that we didn’t have direct exchanges with users? The answer was: yes. As explain above, users were represented by product owners or field experts. Both should be closed to users, understand their problems and prioritize features. But, the reality is sometimes differents. We can expect that product owners and field experts come from the group of users. It can be true. But, I was faced with representatives coming from IT. Oh God! How is this possible?

In a well-organized and highly isolated company (not necessarily big, even in small ones), business can be isolated from IT. Maybe they don’t want to mix with them. They can be afraid by a world they don’t understand. They can also think that everything is obvious, creating some small requirements and expecting magic to happen. They can have high objectives and no time for helping IT. Borders can have been created (like budget, cost, …) making working together harder. Eventually, it’s a fact I have often meet.

I have also meet new comers to business teams as a way to improve their career. They try to control informations in order to be a gatekeeper and be mandatory. I hope it is an exceptional situation.

Well, my chief asked me to do it this way…

Controlling the way a function is made is a strong power in IT organization. Why? Softwares help to automatize acts and process. However, you need to have a well-defined and stable process in order to maximize outcomes. Imagine that business team is divided in 10 groups, like customer management. Each group has a way of working, for example when they received a call, some can authorize customers with a private question, some with birth date. If you define process in a software, you get huge control on the way people work.

Here is my point. Users can not exist and can be modeled according to political views. Maybe they want to have one process, even if every group is happy with today process. Maybe, they want to reduce the number of employees by automating the process…

Anyway, the software produced is designed to solve enterprise problems, not necessarily users problems, it is a side effect. As stated in the principles associated to the Agile Manifesto : “Our highest priority is to satisfy the customer”. Agile don’t really state that user should be happy with the final product. The customer must be. The user from which you build upon the software is a construction made to delight people who need it.