Serve your stakeholders’ NEEDS, not their wants

People requesting work from your team are somehow hiring you to do a job. Even if they don’t see it that way. By understanding the jobs they want you to do, and even the unfilled jobs they may not be hiring anyone to do, you can make your team’s efforts count more.

My product management team gets a lot of requests from stakeholders. Some easy, some hard, some obvious, some that don’t yet make sense. The quantity and range of requests used to stress me. Perhaps you feel the challenge of handling demands on your team too?

For what it’s worth, I get less stressed now, because I’m more often able to help stakeholders based on their underlying needs, not just their immediate “wants”. This post is about how. 

Recently, a sales director asked me “Can we pop up a dialog that syncs with a tool that checks for reusable snippets?”

My response was instant. It was the same answer I’d give to any feature request that I hadn’t heard before. Whether a request is for an icon that shows a counter, for a way to use a new framework, for something “simple to implement” that’s actually hard; or for the kind of feature that’s easy to add and add but not to take away – whatever the request, the response is the same.

The response, of course, is “Why?” In this case, why did the sales director feel that the synced dialog would help customers?

Lessons from the product world

The “why?” response might sound flippant, but most experienced product people would have the same response. Asking “why” is not just another way of saying “no”. It’s a desire to truly understand what challenge the requestor is experiencing, or passing on. This is the most valuable information that a product team can receive.

Without a sense of “why”, any technical work is unlikely to help many customers or enhance the product sustainably. It might help one customer at most, the one who asked for the feature. But even then, often a customer that’s given a feature exactly as they specified it, becomes unhappy that the feature is not better integrated into the rest of the product, or is not as helpful as they imagined it would be.

This is not something revolutionary. Melissa Perri wrote the book on it: her “Escaping the Build Trap”. But it’s still not common enough to see product people taking this considered approach. Too often, product managers and product owners simply take the feature orders. They’re like restaurant order-takers, the archetypal “waiters” that Perri describes:

I’m not building a product – what about me?

What if your team is not building a product as such? What if it’s a project you’re managing, and a stakeholder wants to add to the scope? What if you have a team that provides internal support services in your company, and a leader thinks you can just pick up some different kind of work? These things take your team’s effort and focus, but they might greatly improve the outcomes of the project, or your team’s value and visibility. To respond without thought and engagement is usually a mistake, whether the response is a flat “no” or the waiter’s “yes”. You miss opportunities or you over-commit without knowing whether your efforts will be truly useful.

It’s best to act as good product people do — at least respond with “why”, and find out what the person is trying to achieve.

HOWEVER, the single question “why” isn’t going to get you very far.

“Why would customers benefit from this feature?”“Because it would show them the synced information.”

Clearly that’s not enough. What next? You can ask more “whys” to try to get to the root cause of the request. Taichii Ohno famously described the “five whys” diagnostic technique in his “Toyota Production System” (1998). But unless you are well trained in that system (I’m not!), it is easy to use the five whys in a superficial kind of way. In my experience, by the time you get to the fourth or fifth “why”, you’re often discussing  things at a far too high level.

“Why?”

“To advance world peace”

That’s not terribly helpful in understanding the specific challenge or opportunity. What next?

Focus on the job

If the five whys get too general, how else can we figure out what lies behind someone’s request to our team? I like to think of it as uncovering a kind of “job”. The person has a need for some kind of progress. That could be to do things more efficiently or with less risk, or to do new kinds of things that help to grow business (ie make more money). We can call this need a kind of “job”. A “job to be done”, to use a concept popularized by the late Clayton Christensen¹.

Jobs to Be Done theory says that the consumers of a product are “hiring” that product to do a job. The underlying job may not be something that the consumer or the product company are fully aware of. But if the company can understand the job, they can make the product fulfil that job better, or even develop a new product to do so. (Christensen writes that this is truly useful “innovation”, rather than the type of innovation that simply adds features and capabilities.)

💡 For classic JTBD cases, see Christensen’s milkshake story, and make sure to then listen to Bob Moesta’s podcast episode “The Rest of the Milkshake Story”, for the full context.

When a product team has good understanding of an underlying job to be done, they can either come up with good ways to do it, or say clearly why it is not currently doable. And first, they can compare that job with others, judging whether it’s the most worthwhile one to tackle right now.

But this is all about products, and I want to make this post useful also if you’re not producing products but services, projects, or internal support. So we can generalize the approach like this: when you are talking with someone who’s making a request of you and your team, try to understand the underlying need that triggered this request. It may not be something that they can put into words, but by skilful questioning, you can see what job they really have to be done.

How do I understand the underlying jobs?

There are a couple of levels of doing this. The more basic level is what I’m generally able to do on a day to day basis. That is, to ask enough questions to understand clearly what the requestor is looking to achieve, within the current scope (current product, service, or range of my team’s activities). To do this, you need to want to really understand the context of a request. You need to remind yourself to take a beginner mindset, since what you assume about the environment that the requestor is working in and the reason they’re asking may be quite different from how they see things. If you can talk to people face to face, preferably at the exact place where they do their work, that helps.

There’s also a higher level of understanding jobs, one that’s harder to describe or learn. Often, experienced colleagues of mine are able to understand a request within a wider context, and recommend solutions that go far beyond the stated scope. Sometimes, they help the requestor see the situation differently and resolve their need without the need for any extra effort from anyone. Occasionally, I too can peel back the layers of wants, needs, and underlying jobs, to come up with a solution that may not be at all like the questioner envisaged, but instead is a true innovation – a new capability to meet an unmet market gap.

All this is so vague – there really is no recipe for jobs-to-be-done interviews. The best way I can suggest building your skills is to learn from stories, and to practice as much as possible. There are several good stories in Christensen’s “Competing Against Luck”, and many more in Bob Moesta’s “Circuit Breaker” podcast. You just have to mentally translate the discussions of products to suit the kinds of services and capabilities that your team provides your organization.

Don’t wait to be asked

You can also use this approach proactively to increase the value of your team to the organization. If you take time to think about the occasional odd requests you might get, do they hint at ways to better help other groups and also increase your own team’s visibility?

For example, if you’re leading a documentation team that is sometimes asked to polish internal presentations, and resents doing so, are there other ways to look at that? Helping managers communicate clearly is a great help to the business, provided that you still have time to do your normal work (or that you can renegotiate commitments for that normal work because of the new tasks). And, working with strategic presentations can also help you understand your organization’s direction, so your team can better steer its normal work to that direction.

Or, if you’re in a customer support team and you routinely reject requests to support something that isn’t your area, could you reconsider? What if a job to be done is actually “support the things that your company sells” rather than just supporting your company’s own products? Customers are often happier dealing with one team from one company rather than several. Stakeholders and managers might appreciate a single team, your team, taking ownership, helping to strengthen your team’s position. (If this sounds too power-hungry, remember that a good position helps you get adequate funding and ensure your voice is heard, making work more fulfilling and helping your organization at the same time.) Of course you’d probably need to renegotiate your KPIs, planning for time on training and getting up to speed as well as the increased sustained workload.

By understanding your colleagues’ or customers’ underlying needs and the contexts around them, you can often help them more than if you simply agree to do what they ask for, in the way they specify, just when they ask for it.

I don’t suggest

To be clear, two things I’m not at all suggesting:

1. If a request is simple and easy, and you already understand why it’s being made, don’t wind up your colleagues by going through a Jobs To Be Done style interview every time. “Sorry Joe, could you help me grab that figure from last week’s presentation?”“Well I could, but let’s instead talk about why you need that, and how we could jointly look at our processes to optimize for your underlying needs.” Don’t do that, unless you want to stop colleagues asking you for bits of help and you like being unpopular.
   

2. Don’t feel you have to go through a formal Jobs To Be Done innovation process to benefit from the insight that underlying needs aren’t always what’s explicitly asked for. By borrowing from the concept of Jobs To Be Done, I’m just hoping to inspire you a little with that focused yet intuitive way of analysing people’s unmet needs. I don’t want to pretentiously suggest a formal approach of “Jobs To Be Done For Internal Requests”. I’d rather let JTBD be its own thing, very suited for product marketing and development. It’s OK to simply be influenced by it when considering stakeholder requirements for things that aren’t products.

Briefly…

People requesting work from your team are somehow hiring you to do a job. Even if they don’t see it that way. By understanding the jobs they want you to do, and even the unfilled jobs they may not be hiring anyone to do, you can make your team’s efforts count more. At best, you all get valued more and work can be more fun.

Receptive skills — perceptive listening and reading — are crucial to understand jobs to be done. For more, see Skills > Uncover Thoughts.