Is Stakeholder-driven Development Crippling Your Product’s Success?

3 proven ways to deliver value sooner.

Is your product strategy guided more by stakeholder demands than by user needs? If so, you’re not alone. It might be the root cause of your delays, feature bloat, and the sound of crickets when you deploy.

Here’s a conversation I’ve had countless times:

Stakeholder: “We really need this feature to do ‘X’.”

Me: “Does it have more value than deploying what we have in progress?”

Stakeholder: “It’s a must-have.”

Me: “What are the users saying about that?”

Stakeholder: “I know what they would say. They would say what we are doing is unusable without a way to do ‘X’.”

Me: “OK. Well, how often does this ‘X’ scenario happen?”

Stakeholder: “It has happened once in the past year. But when it happens, it’s super painful.”

Me: “Oh. Is it more valuable to do ‘X’ before we address the other user needs that we’ve queued up to solve? It sounds like a rare situation.”

Stakeholder: “Look, we could save a lot of time and frustration here if you would agree to do ‘X’. Do we really need to keep talking about this, or just do the work? That’s what we normally do.”

Me: (feeling a bit threatened) “OK. Maybe it is better to save the back and forth and just do it. I’ll talk to the team.”

Stakeholder: “Thank you!”

And that’s how it falls apart. Not just for me, but for many product managers.

• We try to stop starting and start finishing.
• We try to act small and harvest value early.
• We try to add logic to a political discussion.

But intent doesn’t always result in the desired outcome. This is especially true when power dynamics are at play. If you are a stakeholder or a product manager and the discussion above hits too close to home, this post is for you. It’s time to start fostering a user-focused culture.

Let’s dive in.

Why do we continue to add more and more features?

We humans like to solve problems.

Any problem will do. Give us a problem, and we can brainstorm several ideas to solve it. They spill out of us. But here’s where things start to go south. We get too attached to our ideas. They become our baby, our precious treasure. We become biased.

Bias gains teeth when it comes from a place of authority. In the power dynamics of today’s hierarchies, those at the top generate the ideas. And those at the bottom realize the ideas.

Tremendous headwinds of power and clout prevent a bottom-up flow of ideas from happening. You get strong egos from those of high rank and fear from those of lower position. Layer this with a long-held culture of lower ranks following the orders of higher ranks. What results is an order-following culture. Those in charge dictate and the workers do as told.

User needs? What user needs?

We call this the feature-factory model in the product world.

Feature-factory behavior. It destroys team empowerment and creates bloated products. And it’s better at this than any other dysfunctional corporate pattern.

Like a real factory, feature teams follow orders without questioning them. They fulfill every stakeholder idea (order) as fast as possible.

Unlike a real factory, each feature produced is not known to be valuable. All product ideas are unproven and add complexity, potential for problems, and delays.

Like a real factory, stakeholder ideas get built, often on time and with high quality. But these orders often debut to an audience of none (unless you count the stakeholders who came up with them).

Logic is not enough to save you from the feature factory. The power dynamics are too strong to overcome the momentum. Reason gets thrown out the door. You must comply…or else.

To break this habitual, broken pattern, we must first desire to change.

And this desire must come from both the product team and the stakeholders. What’s familiar is comforting. What’s not is frightening. This is true, even when the status quo is painful. Both sides have to choose to change and face the unfamiliar.

But if all involved are up to challenge the conventional behavior, keep reading.

---

3 Common Challenges of Stakeholder-Driven Development and How I Overcome Them

The 3 challenges below are by no means a complete list. But they are the ones that plague me like an unwelcome cold. You may have others (you should throw them in a comment).

I have reason to believe these challenges are not unique to me. I have consulted over 70 organizations, big and small, over the last couple of decades. And I see these patterns repeated. So, while your mileage may vary, I bet these 3 paths are treacherous roads well-worn for you, too.

Let’s dive in.

Challenge 1: Overcoming resistance to change — why it’s time to rethink, “The way we do things.”

We resist change even when the status quo is painful and even when we choose to change.

“That’s not the way we do things here,” is a common refusal to adapt.

I don’t know about you, but that statement rubs me the wrong way. It reeks of stagnation, being stuck in your ways.

The behaviors that lead to the factory model often harden into the culture. The proclamation of “We don’t act like that,” is inevitable. It’s like an antibody released to attack a foreign invader. But if we are trying in earnest to learn a new way of working, we need to banish this attack.

The best way to do this, I’ve found, is to use the urge to resist as a trigger for curious inquiry.

We have to turn our resistance into a question.

This curiosity has to spring forth from the one that feels the urge to clutch onto the familiar.

I find it best to form an upfront working agreement. It’s good to address this tendency before it starts happening. Here, I urge the team and stakeholders to prepare for and expect internalized resistance. We form an automatic procedure that we each perform when we sense it brewing. Something like this:

1. When we sense the urge to challenge behavior contrary to our norms, we should stop before we call foul.
2. Instead, we ask a question, like “Why do you believe we should defer this feature?”
3. Then, we discuss the pros and cons of adding more rather than finishing.

When you execute this curiosity loop, it breaks the cycle.

It diffuses the change resistance and helps you start learning new behaviors. By side-stepping the resistance, you can take real steps to move away from the feature factory. You will get on the right path to keeping things simple, finishing them, and putting them into use sooner.

Leading with curiosity leads to change.

Challenge 2: Covering every…single…possible scenario bloats your product. Time for a new tactic.

We don’t want to leave the door open for unsolved situations—I get it.

But all use cases are not created equal. And all are not needed on day 1. You could avoid some by improving another use case first.

Let’s break this down.

Assume you are creating a submission process to post a corporate message.

You create a simple way to do this and are ready to put it out. But someone realizes the submitters can provide an incorrect request. So, the receiver has to correct the request after submission. The gut reaction we have is to stop and build a way to edit requests after submission.

But this would delay usage of the simple submission process and build something we don’t really need. What if we first put our simple solution out for use? Then, we improve the submission process to ensure the correct format gets submitted. Now, you don’t need editing abilities at all. You get value out quicker and avoid building extra features.

If you try to cover every scenario before you launch, you are bound to add bloat for things you don’t need. This will delay getting value out to your user. Here’s how I operationalize avoiding this pitfall.

1. Start Simple. I start modest, with a simple, inexpensive version for a base use case (no extras allowed).
2. Ship It as Is. I put it out for use and get feedback (even though I know it’s incomplete).
3. Assess Feedback for Root Cause. I assess the change feedback and determine the root cause.
4. Inspect Future Use Cases. Don’t address the feedback on autopilot. First, examine if an upcoming use case will avoid the situation.
5. Decide to Defer or Address Now. I first solve use cases that make the problem disappear (unless this use case is far down the list of priorities). Only then, will I consider addressing the feedback now, even if we have to throw it away later.

The order you address usage scenarios can make certain alternate path scenarios irrelevant. Pay attention to it.

All this is another way of saying that you don’t have to cover every base before you have a useful solution.

It’s surprising how valuable a partial solution can be to your users.

The first version only has to start to solve their pain. It doesn’t have to solve every possible pain to be usable, used, and useful.

If you solve and ship one simple use case at a time, you get two massive benefits. One, you learn how it works in the real world and you get feedback. Two, your users start to benefit while you build the next use case. This starts a virtuous cycle of finishing and harvesting value. You benefit, your users benefit, and your business benefits.

So, don’t mistake completeness for being useful. Otherwise, you will build things you don’t need and delay the things you do need. And who wants that?

Challenge 3: Ignoring users to please stakeholders misses the mark (and the value). Let’s shift our focus.

Should we please our stakeholders or our users? The answer is both, but the order is important.

Building stakeholder ideas to please them neglects the most valuable player—the user. This behavior is at the core of stakeholder-driven development. It leads to feature bloat, not what users need in the time they need it. And unhappy users don’t translate to the business impacts we all desire.

Assuming everyone wants to change this, here is what I recommend. I move away from the feature factory produced by stakeholder-driven development, like this:

1. Clear the Slate. Put all the stakeholder ideas in an options backlog.
2. Know Your Users. Get to know your users and their needs (bring your stakeholders along for the ride).
3. Select One Problem (Not Two) and Ideate. Pick one user need. Then, ideate to solve it with your stakeholders. You can pull from the ideas in the options backlog if they fit the need.
4. Select an Idea to Try. Build a lightweight, cheap (throwaway) experiment.
5. Test It. Test the simple experiment with your user. See if it solves the pain. Get feedback. Form insights with your stakeholders.
6. Iterate If Necessary or Build. Trash your test if it misses the mark. Evolve it if you need to. Build it for real if it strikes a chord.
7. Deploy Into the Wild. Let your solution be used; set it free. Track analytics. Talk to users. Review findings with stakeholders. Iterate if necessary. Go back to the drawing board and try something else if it fails in the wild. Celebrate if adoption soars.

This stops us from defaulting our focus to stakeholder desires. We instead serve user needs side-by-side with our stakeholders. And happy users are our focus. We aren’t satisfied until we delight them. Why? Because that leads to business impacts. And when we meet business drivers, we get happy stakeholders.

Happy users. Happy business. Happy stakeholders. What’s not to like?

---

That’s it.

Changing your culture to abandon stakeholder-driven development is easier than you think. It only requires a willingness to change and deliberate practice to do so. You can do this in 3 ways by:

1. Turning resistance into curiosity with upfront agreements.
2. Starting small, releasing, and evolving based on user need in the right order.
3. Putting user needs first to drive the business impacts stakeholders desire.

What steps will you take today to change your stakeholder power dynamic? How will you act now to move away from stakeholder-driven development?

• To start embracing new behaviors to limit and finish what we start.
• To be content with solving one use case at a time instead of all of them at once.
• To stop chasing stakeholder ideas and start solving real user problems.

Share your tactics in the comments.

---

➡️ Sign up for weekly insights like this. Learn about returning to the fundamentals that make product teams unstoppable. Join a community of like-minded professionals committed to achieving outcomes sooner.