Stakeholder Wants vs. User Needs: Why Following Orders Creates Bad Products
How one small mindset shift can transform your product development
“I know it’s what I asked for, but I hate it.”
It was like a punch to the gut for me and our entire team.
We had just completed our final demo after spending the past 18 weeks creating a complex, mobile-enabled, multi-sided marketplace for a nationally renowned brand.
This brand had been supporting an underserved channel with a huge potential future Total Addressable Market (”TAM”).
When we started the product, we were shocked a brand of their size was managing this entire user group through a mix of legacy systems and paper forms. The client knew they needed our help.
I had the fortune to lead a strong team with experienced leads across technical architecture, mobile engineering, and User Experience (“UX”).
After our initial kickoff, we were told all communication would go through our single point of contact, the channel lead.
Our stakeholder assured us they knew exactly what each of the different users would need from the mobile app.
Kicking off
We worked from the successful PowerPoint sales pitch deck that laid out the basic functionality and initial mobile screen concepts.
Like most consultancies, we started working in a series of handoffs.
Once our stakeholder signed off on our technical architecture, we went through a series of approvals and handoffs before our Tech Lead started assembling the engineers to start development.
Approvals only came after multi-hour presentations and discussions and many rounds of rework. At each stage, we politely but firmly asked our stakeholder to give clear sign-offs.
Pushing the envelope
Due to our mobile track record for global brands, our stakeholder pushed our UX team to design “cooler” interfaces.
The approved designs turned out to be way harder for our mobile engineers to code than we had estimated. The team put in the extra effort to code everything to the desired “requirements.”
And our weekly client check-ins made sure there were no surprises.
Our team also became experts in each of the multiple personas’ user journey flow as they carried out their tasks in the app.
Prepare to launch
After four months of late nights, the client downloaded a beautiful, fully-functional mobile app, powered by a mobile services platform.
And then came the bad news. Our stakeholder hated it.
Despite frequent reviews and incorporating multiple rounds of feedback, our stakeholder was mad at us and at themself.
And that wasn’t on the client – that was on us.
No guarantees
Had I known then what I know now, we would have tackled the glaring red flags way up front.
Probably the biggest warning sign was that all communication went through the single stakeholder. They had all the power and control, and no one to bounce ideas off of or to check their thinking. The entire fate of the product rested in their hands.
Secondly, we took everything told us at face value, and never tested assumptions nor gathered meaningful qualitative and quantitative data.
Second life
Fortunately, despite the stakeholder’s initial concerns, the company marketed the app through splashy press releases and social media before launching it in the app stores.
Some small problems cropped up right away once real users started using it.
Go figure.
But after getting some good end-user feedback and doing a few rounds of fixes and changes, the app gained some traction, even earning our stakeholder a promotion.
Feeling lucky?
My experience wasn’t unique, although it was extreme.
The simple fact is that everything we plan to build is a guess, a bet, based on assumptions of what we hope might work.
It doesn’t matter whether you design the most beautiful app, code it with the hottest mobile framework, or use the latest DevOps pipelines to move that code.
The only test is when “the rubber meets the road,” i.e., what happens when your app comes in contact with real users.
Until that happens, we won’t have a clue which of our many assumptions hold true, and which are plain wrong.
Admitting we don’t know
A good first step? Start with some humility about our ability to guess what our users want.
We suck at it.
Alternatively, we do have the ability to collaborate with our stakeholders and co-create better products with the right users.
Not all users are equally important to your product
Given the aggressive timeline, creating a product that met every possible user persona’s needs was a bad idea.
Like everything in life, it comes down to the 80/20. As app tracking data confirms, only 20% of users contribute 80% of the traffic and revenue in any app.
Zeroing in on these “super” users and serving their needs would have made our product design and development process far easier and created a better app.
A different strategy
The end result might not have been exactly the image our stakeholder had in their head.
But it would have allowed us to build the right app for the most important users, moving them from paper forms to a mobile app in ways that anticipated their needs and made their lives easier.
The only way to accomplish that would have required us to use a very different strategy than slavishly building whatever our stakeholder told us to build.
Talking to people
While we were busy trying to meet our stakeholder’s expectations, we had two other options:
Identify the “super”-user persona, and talk to some actual end users
If for any reason we couldn’t talk to end users, the next best approach would have been to talk to the customer support team – the people who spend all day listening to user problems. In my experience, I’ve noticed they’re great at keying in on classes of issues, (“problems with log-in”) as well as prioritization (“this is a top-5 user problem”)
Bringing our stakeholders along to these discussions, along with Tech and UX, would have allowed everyone to move from “building an app” to solving real people’s problems through the app.
Discovery
So how do we and our stakeholders shift our thinking to better understand the problem we’re really trying to solve?
One opportunity could have been to encourage our stakeholder to tone down their micromanaging in the “solution” space (the app looks like this, has these 12 buttons, and does exactly these 15 things), and shift to the “problem” space by asking these kinds of questions:
“When you have the mobile app, what then? What would persona A be doing differently? And how would your company support them to accomplish those tasks if they needed help?”
Our goal is to take that information and use our team’s combined expertise across Product, UX, and Tech to innovate and create better products.
The biggest risk is building exactly what we’re told to build when the least information is known.
Because clients don’t know what they want.
And even when they claim they do, they have no idea what the right team can do with the right technologies to solve the problem.
Tonight on the menu, we have…
An excellent way of thinking about balancing serving with leading is Jeff Patton‘s “waiter“ versus “doctor“ analogy.
Waiters take instructions and act.
Their focus is on getting you whatever you asked for, quickly and courteously.
While it’s well-suited to some service businesses, it’s a mindset that prevents “product” thinking and our ability to innovate and deliver value above and beyond what we’re asked for.
We’re so focused on “serving” who we think our “customer” is that our real customer’s needs are forgotten.
“Success comes “when product teams don’t mistake their CEO or business stakeholders as customers. And this is also what happens when business stakeholders don’t mistake themselves for customers.”
Jeff Patton
Is there a doctor in the house?
Doctors, on the other hand, are seasoned professionals who listen for and spend a great deal of time accurately listening for and diagnosing problems.
They then decide how to use their expertise to solve them in the best way they see fit, given the unique situation.
The focus is on the achievement: Creating healthy outcomes for their patients.
The majority of consulting businesses are based on the idea of trying to be the best possible “waiter.”
There are a few top-flight, respected consultancies that charge top dollar and can take a problem and solve it comprehensively.
But the reality is that it’s never usually a matter of taking orders and executing, or making brilliant diagnoses.
It’s a range
It’s key to understand the waiter-to-doctor mindset shift isn’t a binary on/off switch; it’s more varying degrees on a range:
Depending on the client, the dynamic, or the engagement, we can fall into a pattern that’s not right for the situation.
The key comes in making two shifts:
How we frame our problem
How we define success
Let’s look at the role each shift plays.
Identifying the Problem
Waiters or doctors have very different ways of defining the problem to be solved.
“Waiters” define the problem as: “My stakeholder wants me to build a new feature like competitor X. Doing what my stakeholder tells me to do is my mission.”
“Doctors” define the problem as: “After talking to some people and reviewing the data, many people want to go ahead and build X. But it seems to me the real problem is that too many sales are one-off sales. Merchandise is frequently sold out, and shipping takes too long, so when customers finally do get their merchandise, they don’t want to buy again.”
While the “waiter” takes stakeholder commands at face value and jumps to “execute” a half-baked solution, the “doctor” works to better understand and more clearly state the client-centric problem that forms the foundation of achieving meaningful client and business outcomes.
Defining Success
This mental shift allows us to change our definition of success:
A waiter’s definition of success would be: To deliver an app, on time, and on budget. (Also known as an “output.”)
A doctor’s definition of success would be: Speed up shipping from 2 weeks down to 3 days. Enable our target customer persona group to post 20% more products to the system and eliminate friction from interacting with more prospective buyers, thereby selling 20% more repeat business and boosting their own (and our) revenue by 10%. (This would represent both user and business “outcomes.”)
From the doctor’s perspective, we’re answering the question:
“How can we shift this user persona’s behavior in measurable ways that help them achieve success for themselves, as well as our business?”
Working backward from our problem and having a new definition for success, we begin going through Continuous Discovery, the core of which is customer interviewing.
A new level of partnership
As we shift into trusted professional doctor mode, once we’ve redefined the problem and what success looks like, we can share that information with our stakeholders.
We can invite them to partner with us in discovering better solutions by speaking to end users and engaging in Continuous Discovery.
Only when we shift the dynamic underlying our product development can we open the door to collaboratively building truly great products.
Summary and Takeaways
In our work, there’s always a “stakeholder,” and an end-user “customer.”
Don’t make the mistake of confusing them, or you’ll kill your ability to deliver value to the people who need it most.
Remember we always have the choice to either stay heads-down and just “execute” what we’re told to do, or take a step back and work towards a higher level of achievement by better understanding the problem.
Becoming aware of the “Waiter” to “Doctor” dynamic can help us intentionally choose which role we want to play, and what’s best for each situation.
The two keys lie in shifting:
How we frame our problem
How we define success
Once we’ve done that, talking to real end-user customers and engaging in Continuous Discovery are keys to building better products that achieve customer and business outcomes.
Mike, I'm going through something similar at work right now. We're asking for funds for a new experimental facility. It wasn't my idea. I have to contribute my part although I haven't been involved in this project until now and it's been running for a couple of years. A colleague said, "Fake it till you make it." So it looks like I have to make an intelligent face and pretend I know what I'm doing.