Users, customers, Situations or People?

[Helge]

I’ve got one question: Who are we building for?

The language we choose shapes what we can see and how others can see us.

Terms like ‘users’, ‘customers’, situations or people can describe the same person, but since the language and focus is different we often don’t work together to solve shared problems.

e.g.

According to anthropologist Rikke Ulk a ‘user’ is an ‘operator’ of a tool, app, website etc.. They don’t have context. Their motivation is simply to ‘use’ something in order to accomplish a task. Building for ‘users’ often means understanding these tasks, their content, what good looks like, removing friction and increasing satisfaction. The focus is on getting tasks done as good as possible.

A ‘Customer’ is a wallet who’ve decided to ‘hire’ a product or service. They might still be looking for the right option, wanting to learn and need to make decisions. Our focus is often on optimizing the customer journey or purchasing funnel, presenting good product features, making sure we can out-compete the competition (whatever the competition might be).

A “Person” is a simplification, a quantification of a human being of a certain age, belonging, status and stature etc., who most commonly has a family, friends, a job, income, some material possessions, education etc.. A person is often represented by demographics, and used to make assumptions about probabilities or media buying.

People are driven to action by motivates them, and one of the best indicators of motivation is the ‘Situation’ people are in. The situation gives people a need, motivation, specific routines, technologies, relationships etc. Everyone shows up in different situations throughout the day. Each situation has a unique set of forces influencing us.

–

My question therefore is: who are we building for? The user, customer, person or situation?

And do others agree or disagree with my assumption that the language we use shapes what we can see and how others see us?

[EricZ]

I like this breakdown, as it takes what appear to be clear synonyms and draws out the distinctions. I think I’d complicate this a bit more in some ways.

Let’s take a B2B companies SaaS offering. You may need to understand the Person and/or Customer within their situation in the marketing phase, then the User and Customer as they engage with the SaaS product.

B2B Marketing - The customer will be a business, and the users of the website will people persons within the business’ situation. We often distinguish between communicating with the decision-makers and the producers in the marketing phase, as the producers will be future users and have a need for greater technical detail.

B2B Product - Now that we’re in the product itself, we’re dealing with persons who are users, and we’re looking to optimize the situation and positioning of the customer. Decision-makers will need reporting to justify the SaaS product, but won’t be the primary focus.

Wonder if this changes the definition of what is being used here, or if it changes the heading of the scenario?

[ben]

Language is SUPER important imo. This is a really awesome breakdown here @Helge.

I think this has been something that I’ve had a closer look at, especially while exploring how to build the right things.

However, especially with B2B, it feels that you’re building for the user, the customer, and the executive at times (example: the engineer using the tool, the dev lead with the purchasing decision, and the CEO who wants to see the results).

[Helge]

Hi @EricZ and @ben thank you both for your comments.

My question is not so much which term we use, but what happens when we don’t use the same one?

If an executive business team asks for a business improvement, a cross-functional team does the research and develops a strategy and an execution team builds the service. But they all use different terminology and language. Isn’t there the risk that one of the teams starts solving a problem that is important to them, but which the other two teams/groups don’t understand?

One of the most prominent / famous managing directors here in Norway recently at a conference said: “when the people in the room start talking about the user interface I know we have lost”. I was very surprised, why would he say that? The user interface is very important. ..

But from his perspective, it was spending time solving the wrong problem. He didn’t understand why it was important and the people discussing it didn’t bring the language where he could see why.

Would you agree?

[EricZ]

@Helge

One of the most prominent / famous managing directors here in Norway recently at a conference said: “when the people in the room start talking about the user interface I know we have lost”. I was very surprised, why would he say that? The user interface is very important. ..

Particularly in cross-functional meetings, agreed. Aligning on the correct end-user will shape the feature being built, because the end-user tells us what will be most valuable to them as an individual or company in their given situation.

Discussing whether to implement search, and the most valuable place for that implementation is what is valuable to discuss in cross-functional meetings. It reveals what gaps we have in our understanding of how to solve the user need.

Discussing whether the button should be an icon, the word ‘search’, or style of the input is just wasting time.

[Bryan]

@Helge

My question therefore is: who are we building for? The user, customer, person or situation?

This is one area in the framework where we need to drill deeper @Helge. I think they coexist as a network.

For example… customer has many different flavors:

• Customers- Users across the journey:

  • Trial or Pilot Accounts
  • Freemium Users
  • Dormant Accounts
  • New Paying Users
  • Habitual Users
  • Power Users
  • Advocates
  • Churned Accounts

In targeting a group to serve, I believe focusing on attributes is most important:

[Helge]

So. I have a bias

I put out a video the other day on altitude. Where i argue that when we go to deep our language creates silos and pushes people away.

In the video I share a story of a project we did where we needed to lift the altitude in order to discover where different teams had something in common giving them the opportunity to collaborate.

This altitude was the ‘situation’ (that’s my bias )

I would argue that every user in the list you’ve kindly provided @Bryan is in the same situation, but with the energy or motivation to lean in more or less, or through different instruments (e.g. advocacy). And it is the situation that helps us see them as having something in common.

Also I believe if we start calling some of the e.g. ‘power users’ we will be hitting a level of granularity where some of our stakeholders won’t understand the nuance.

If we split them into ‘efforts’ then it’s their energy we’ll focus on (maybe) and not what they are trying to achieve that leads them there in the first place. Or what motivates the behvaior bringing value to both them and to us (for specificity a situation can come with different needs / motivators).

Does it make more or less sense?

[The video for reference: https://youtu.be/uTO77L4TDeo\]

[EricZ]

I think what I’m seeing is that “Situations” is playing more of a role than just “context” assumptions for the initiative or build. I’d be interested to hear more about how focusing on Situations, or otherwise might affect a team’s process.

[Bryan]

Love the concepts @Helge (and your videos!)

After watching the video, the thoughts that came to mind:

• In which cases should you NOT align language to customers? Isn’t that the altitude to focus on in most scenarios? Does this keep the throughline grounded?

• What is the goal of the overlap of these abstractions? Better results? More efficiency?

• Does this not add a layer of complexity that the stakeholders must understand? I find that executives struggle to manage these abstractions across the business.

Keep on sharing these ideas!

[Helge]

@EricZ we found that our commercial colleagues (mostly marketers, but also sales and a few other roles) changed their thinking when we introduced “situations and needs”. As they were used to thinking about “products, channels and content” . But the reason we changed it to situations and needs was because in our case this was the lowest hanging fruit. Because they already had the answers. These people knew the insights, they’ve known their customers for years, listened to them, met them, done tons of research on them. But they never changed the thinking from “our job is to talk about our products” to “our job is to understand situations, discover and deliver on needs”. When we changed their mindset we changed their language → this changed their questions → which changed the data they needed to answer these questions → this led to discovering new opportunities and experiences → which led to a need for new technologies and competencies → leading to a need for new skills, talent and ways-of-working → and finally the need to be incentivized (measured) in a new way.

@Bryan I would independently align the terminology to what is best for the project/ organization. I personally don’t think it’s universal answer to this. In the case I present in the video we aligned on the patient (not a customer), because there was the commonality in terms of: who do we want to benefit from the otucomes this system produces. It could also have been the physician, but we found in this project the right altitude was the patient I would argue the goal is to produce outcomes that matter instead of outputs that don’t. And we found that it removes complexity because you find an altitude that is natural to everyone instead of adding layers of abstraction or complication by introducing many different roles at different altitudes that needs to be understood through different data and in different ways.

[EricZ]

Super helpful explanation, thank you. Particularly your “which led to…” portion, that helps clearly explain how the switch transformed the process.