It doesn’t make sense to say “stakeholders need a digital mobile app,” because:

1. Stakeholders don’t need an app. They might want one, but that’s different.
2. Stakeholders might decide that they want an app, but they don’t want it because it’s digital or because it’s mobile; they want it because of what they’ll get out from it. That’s what they’re after: an outcome, not an app. Identify that outcome before you spend the effort building an app.

Business analysts enable change. We enable stakeholders to shift from their current situation to their desired future. We take stakeholders on a journey; we help them achieve the things they’ve dreamed of achieving, one step at a time.

Every stakeholder you facilitate is unique. Each has a different combination of wants, needs, problems, and desires. Though in many ways, they’re the same. They share a bucket list of hopes and dreams, each with different priorities, depending on who you’re asking, but with plenty of overlap.

Here’s a list, the fundamental list, a shared lexicon we each choose from when sharing our hopes and fears.

You could perhaps consider a dozen more. But it’s unlikely you could identify another fifty. This core bucket list of hopes and dreams means that business analysts, like musicians, don’t need many notes to strike a chord.

And this is where we start: with curiosity. Curiosity about what the people we seek to serve, our stakeholders, want and need. Curiosity about what’s on their to-do list when they get to work, what they talk about around the water cooler, what wakes them up at 2 o’clock in the morning.

And then we’re curious about how our story and our promise can intersect with their wants and desires. When we facilitate someone, will we see what they see? Will they want what we think they need? Will they accompany us on the journey?

Don’t begin with your systems, your processes, your functions. Don’t begin with your one-size-fits-all template or distract them with your mission. Instead, begin with hopes and fears, with perspectives, and with the change your stakeholders seek to make.

There are three popular misunderstandings that many of us get knotted.

The first is that stakeholders are implicitly aware of their wants (which they mistake for needs, we’ll get onto that in a moment) but they are quite awful at communicating them. They often state solutions instead, not seeing that it won’t solve the problem. When it comes time to share their requirements, they get stuck.

“I need a car.”

The second is that stakeholders mistake wants for needs. What they need is to commute daily to the office. What they want is a convenient and comfortable means of travelling to and from work. And if they’re expectant enough, a travel time of no more than 30 minutes.

Will a car make the distance, in rush-hour traffic, in that time? Is the train or bus faster? What about moving home closer to the office, is that an option?

The third is mistakenly believing that all stakeholders want the same thing. They don’t. The marketing executive wants something bright and shiny; the finance director wants reliable and affordable. There’s even conflict inside the stakeholders own head. They need things to be improved, but, at the same time, they don’t want things to change.

One stakeholder wants a Mercedes S-Class, another a Honda Civic.

We need to understand what our stakeholders want (not what we think they want) because it shapes the story. And if we don’t know what they start out wanting, it’s hard to take them on a journey somewhere.

If you ask them, you probably won’t get what you’re searching for. You’re unlikely to find the true answer. It’s our job to connect with stakeholders, figure out what they desire, and then create the transformation that will deliver that utility.

Focus groups didn’t invent Locomotion No. 1, Project Gutenberg, or Bohemian Rhapsody. Focus groups didn’t invent Virgin Airlines, Zara, or Habitat for Humanity either.

in 1999, John McNeece, a cruise ship designer, speculated about the desires of Henry Ford’s potential customers, “There is a problem trying to figure out what people want by canvassing them. I mean, if Henry Ford canvassed people on whether or not he should build a motor car, they’d probably tell him what they really wanted was a faster horse.”

Everything you’ve learnt at work and in training about doing good business analysis is about writing the specification, delivering on the requirements, getting the quality right, doing the specific thing for the specific technical purposes.

“What do you do” is about a title, a task, a deliverable thing.

Consider this job description from an insurance company:

BUSINESS ANALYST

Understanding the business requirements, and through a structured process, modelling, validating and translating it into business requirement specifications that are used by developers to craft a technical solution.

Work on solutions supporting multiple business areas, integration points and a large number of affected components. Required to work under general direction within a clearly defined accountability framework. Gather and interpret requirements from the business. Participate in the solution design process. Prepare the requirements specifications. Define the success criteria for solution testing. Analyse and decompose relevant business processes. Performing business analysis and process improvement within assigned solution project. Provide assistance to solution delivery on implementation and training. Assist (when necessary) with systems testing. Ensure that proposed test solutions cover all aspects of delivered business specification

While this is the description of a job, it’s not the description of a dream or a desire. While it’s specific, it could easily be altered without changing what it delivers.

This is how education works as well. MBA degrees are meaningless. It’s the doors that they open that we strive for.

The same is true of your product or service. You may say you’re building a feature, but don’t believe it. When you’re enabling business change, you’re offering your stakeholder a new opportunity, a step closer to their dreams and desires, not a feature.

We enable change, utility, possibility, not tasks or papery stuff.