When Managing Up is Failing

Alpha’s thought leadership in the product and user researcher space continues to elevate the influence of these important roles, yet their latest study “How Decisions are Made” reiterates a worrisome sentiment that product managers continue to feel at the behest of leadership decisions and bureaucracy.

46.8% of respondents say that decisions are primarily made from the top down. This helps explain why 62% say that the most significant challenge that their teams face when trying to make good decisions is too much deliberation or slow reaction to change.

To be completely frank, that was my biggest frustration in corporate settings and the reason I love being a consultant. And I’m not the only one who sees it that way:

Good consultants and agencies can be an important driver of growth and innovation because of their ability to think, speak, and act independently.

Of course, this is not the case for all organizations. Alpha’s sample heavily represented small-midsize companies where 41.2% of their respondents work in companies between 1-100 employees and another 27.4% have between 1001-1,000.

So what is it about those sized organizations?

Anecdotal hypotheses

Founder’s Syndrome

In the smallest of companies, product managers are in the shadows of leadership making the transition from driving the product and managing a bit of everything, to looking beyond the present towards long term strategies. Everyone is heads down and output expectations are high, which does offer a lot of autonomy for how things get done. But what gets done often still rests with leadership.

No OKRs

It’s hard to say whether it is a communication problem from the top, an accountability/fear issue or perhaps it is a sense that being agile equates to being able to pivot and eschew concrete goals. I have yet to work in an organization where the executive team has set up clear OKRs for the Product team other than to “get more users” (and the time Product did, it was seen as usurpation of power.) This is unfortunate. Because the best way to hold Product accountable- to see whether they are fulfilling their mandate- is to do exactly that. Galvanizing a company around quarterly metrics also reduces the negotiation required to make decisions on what shape the roadmap should take.

Lack of clear responsibilities and Ownership

The role of a product person is to “own” the product and take ultimate responsibility without having explicit authority. That is the fun and challenging nuance assigned to the role in most organizations: to “lead from behind” through collaboration and well-crafted arguments that support ideas. Arguably, any great employee will work with others this way. When UX and Product can’t find a compromise and resign to escalate the issue however, why can’t we make the product person the final arbiter? One might posit that through explicit ownership, there would be more incentive to collaborate so as to minimize risk. Thankfully, many organizations are moving towards this structure.

What can be done

One of the caveats mentioned in the study was that while consultants help drive growth and innovation,

most respondents don’t regularly retain consultants to support decision making... Rather, the consultants have functional or industry expertise.

In general, this is true for management consultants hired by leadership and active boards looking for oversight. But I would argue that product consultants are champions of better decision-making and may facilitate organizational process changes, in addition to supporting Product teams with improved approaches. I outline the steps I take during client engagements below, in a frame that can be done by any advocate within an organization.

Roadmap Prioritization Process as an Example

It’s easy to become mired in the day-to-day and feel like the cultural frame cannot be shifted. It’s tough. Though incremental changes can be made. For the recommendations I outline below, I’m going to center the decision-making process around roadmap prioritization since that is one of the major inflection points across stakeholders.

Buy-In

First, create the buy-in needed so that you can gather major decision-makers to rally around addressing where prioritization decisions and approvals get sticky. Identify the commonalities that are frustrating your team, and other teams, by interviewing pivotal stakeholders one-on-one. The goal of these interviews is for you to learn more about the challenges of that team, to make the stakeholder feel heard and that their needs are respected, and to incite them to help you improve the process. After this, pick a small cadre of people among the different teams to be your allies in driving consensus.

Consensus Driving

After getting the lay of the land, work with the small group of allies to facilitate a meeting with all the decision-makers. I recommend this group meets first to determine the agenda and goals of the meeting. Invite all decision-makers. Allies should do their own positive “pollinating” of the meeting amongst their colleagues.

At the meeting, establish the rules for participation: no talking over one another, no blaming, and keep criticism constructive and objective. If that seems unlikely or you have some extremely shy people in the group, consider using index cards to solicit the feedback rather than having a real-time feedback session.

When everyone has shared their perspective, start clustering the common threads. Then, as a group, go through a similar prioritization process as you would do with a feature set: figure out the amount of work needed to make the change and estimate the pay off. Not only will this practice make prioritizing those changes among the group easier, but it doubles to educate everyone on Product’s process of prioritization.

Once you have three to five points to improve on, assign a member from the inner circle of allies to steward the best practice moving forward so responsibilities are spread throughout the organization. Outstanding questions are bound to require follow up. Assign them to anyone willing to take ownership and as the point person for this endeavor, make sure they are done and distribute those answers to everyone later.

Before the meeting adjourns, commit to a Retrospective meeting in three months to evaluate what is working and what is not. Essentially, you are running decision-making changes much like a product!

Follow Through

As the advocate of this endeavor, be sure to continue to check in with your allies over the next few months. Not all of this will go perfectly and most likely the outstanding questions will require additional discussion. Document the notes and actions items from the meeting in a shared location and share (in plain text) through email. Keep track of any metrics the changes contributed to and review at the Retrospective. For instance, an estimate of the amount of time saved and by whom. Anecdotes are fine. Don’t be afraid to give personal updates to leadership and the executives as to how everything is unfolding.

While the time dedicated to this process is not to be underestimated, in the long run, the gains will be seen.