Last updated on March 11th, 2018 at 08:20 am
Generating and keeping product management alignment across all levels of an organization – from C-level until the single engineer – is one of the most important (and often most challenging) for a Product Manager.
And while often suggested a simple change of habits like ‘talk more to each other’ or ‘keep a confluence page about what has been agreed’ are right, they don’t necessarily provide the right level of confidence to a Product Manager to strive at his mission.
Why Stakeholders mostly talk about Feature Requests
Almost every product manager knows the situation (if you don’t, please let me understand how you avoid it right from the beginning): Some of your stakeholders just always come up with particular features (aka solutions and no problems) they want you to build into your product.
While some of them may have learned and agreed to the concept of building an MVP first and no stuffing the first product release with more functionality, they a least insist on storing them as they are in the product/feature/idea backlog (here’s why that’s not an approach to pursue).
That’s because they’re like users – They don’t know what they want. And talking about particular features is their way to remain involved in the product development process continuously.
The key for you as a Product Manager is to determine where the urge of some stakeholders to be a regular part of the day-to-day product development process originates. You have to reverse engineer your stakeholder’s feature requests back to ‘jobs‘ they want you to fulfill for them or your target user.
The most likely reason though is that they think that the product output becomes proportionally better with their involvement.
Unfortunately, this misconception is the result of a lack of trust these stakeholders have that the delivered output by you and your development team matches their expectations.
Why that may seem like a miserable situation, the best way to resolve this issue is to focus on alignment early on in the product discovery and the commitment to a particular outcome rather than feature idea.
A better way for stakeholders could be, e.g., to drop in inspiring snapshots they’ve seen in other products with the apparent accompaniment that the way this product approached an individual problem may be helpful for your work.
How Alignment supports you in Stakeholder Management
Why do Stakeholders always come up with Feature Requests? Because they’re like users – They don’t know what they want.
Influencing the roadmap solely with specific feature requests is their way to remain involved in product development continuously. An incredible challenge for product managers within the domain of stakeholder management.
Why do they want to stay involved? Because they’re not convinced that the results will match their expectations. You haven’t earned their trust (yet), and they may also have a hard time giving up micro-level control over ‘their’ product.
It’s your responsibility as a Product Manager to reverse engineer their feature requests using alignment tools to get to the bottom to what they want.
Only then you can come up with better solutions than they can imagine.
So, the next time you’re frustrated with the way stakeholders articulate their need, remind yourself to treat them like your users.
Develop empathy for them, get to the bottom of their actual problems and deploy ideation and creative techniques against those problems to come up with better products.
I know, in an ideal world, we’d all be on the same page already. But on the bright side, you can count on an educational effect on your stakeholder’s minds as a byproduct of problem-centered product development.
But be sure that this is your responsibility. The worst you could do would to just built those specific feature requests.
Product Management Alignment Tools
That’s why I picked four alignment tools for Product Managers for you to grab for your next product strategy session or product discovery kick-off. Going too much into detail about how they’re used would blow the frame of this format:
Luckily, I have been around at XING when this framework was developed. It is a mix of the influence from Stephen Bungay and Christian Becker and has been evolving through internal forces since then. Check out the full guide right here (original link is currently broken), watch my fellow Product Tank Hamburg Co-Organizer Marc speak about it attend the upcoming workshop around Auftragsklärung facilitated by Christian Becker in April at MTP Engage in Hamburg.
A simple but effective one pager developed from the guys at Intercom. They managed to integrate all the stuff I like the most around product development (right now): problems first, defining specific measures of success, job stories, and clear product scope.
Would love to see some writing on the actual usage from the product teams (and stakeholders) at Intercom in the future.
Asana’s proposed format is similar to the Auftragsklärung but goes into a bit more detail. For example, it already requires first mocks of the solution – which can be dangerous without giving the right context to your stakeholders. Also, it also provides the opportunity to ‘attach’ (user) research insights.
While this enables a very ‘complete’ picture of the project ahead, I think it’s on the edge of making starting a project or initiative similar to filing a request. It’s meant to be a pitch document to make C level prioritize.
The best thing about this format is its strong visual aspect. It’s maybe not as sophisticated as the other frameworks above, but it focuses on feature prioritization is its most significant strength at the same time. It ruthlessly forces everybody at stake to develop a shared understanding of what to build next.
Besides, its format is perfect for keeping the aligned vision always visible in the team space.
While there’s no official material on this framework, it’s widely confirmed and well-known in the product manager community. It’s the result of Jeff Bezos’ approach to cut subjectivity and fluff of product development. The result is a document which shouldn’t exceed a page and a half in length which needs to be provided to meeting participants before, e.g., a kick-off meeting for tackling a new product.
Never used it in ‘production’ but will do shortly.
Alignment doesn’t need Agreement
When I talk about the importance of alignment and the several frameworks to create it, I often hear questions regarding what those are for and what the goal of the invitee/creator should be when walking critical stakeholders through an alignment process.
When I then explain that, at the very end, it’s all about getting commitment/buy-in, a typical response is something like that: “Ok, so, I need to convince everybody to agree with my point of view.” And this way of thinking often leads to the initial rejection of an alignment process, because people then don’t see any chance at all, to get individual stakeholders to agree with them on the process ahead.
That’s why I wanted to use underline the importance of not confusing alignment with an agreement. The way more critical part of alignment is commitment. And it’s way easier to get the commitment from your stakeholders, then making them agree.
I stole a beautiful phrase from the most recent shareholder letter Amazon CEO Jeff Bezos just recently published and which I’ll cite blow in a minute: disagree and commit.
Third, use the phrase “disagree and commit.” This phrase will save a lot of time. If you have conviction on a particular direction even though there’s no consensus, it’s helpful to say, “Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?” By the time you’re at this point, no one can know the answer for sure, and you’ll probably get a quick yes.
This isn’t one way.
If you’re the boss, you should do this too. I disagree and commit all the time. We recently greenlit a particular Amazon Studios original. I told the team my view: debatable whether it would be interesting enough, complicated to produce, the business terms aren’t that good, and we have lots of other opportunities. They had a completely different opinion and wanted to go ahead. I wrote back right away with “I disagree and commit and hope it becomes the most watched thing we’ve ever made.” Consider how much slower this decision cycle would have been if the team had actually had to convince me rather than simply get my commitment.
This example perfectly outlines a position a manager should take when working together with an empowered team: It’s fair to have a different opinion in your mind and articulate it.
But when your team of experts then chooses a different path to pursue anyway, you must have their back as if they’d follow your suggestion in the very same way.
So, coming back to the difference between aiming for agreement and commitment in an alignment process, a proper comparison is also to take bets, close the process and back them 100% compared to endless rounds of discussions to get harmonizing everybody’s opinions for the sake of it.
If you’re facing the latter one frequently during internal discussions, it’s also a very fundamental cultural issue within your company. Focus on consensus instead of embracing conflicting opinions.
Which format, framework or result of common sense are you using right now to create and follow-through on alignment within your organization?