How Product Managers Get Team Commitment with Limited Influence

Leading without authority in product management

Is it normal for your product requirements to sit in the backlog for months?  When you write good requirements and there is no reaction from engineering, then what does it mean?  After spending time researching and developing requirements, you do need a reaction beyond going into the backlog.  As a product manager, you need to get out of this situation quickly.

However, you have limited influence in your organization - perhaps you are new to product management or in a new team or maybe someone else is supposed to get commitment to your requirements.  Or possibly this is a repeating pattern for you.  For many reasons, you feel as if you have limited authority to get commitment to your requirements.

How to Get Commitment to Your Requirements

Even with limited authority, there are things you can do to get commitment to your requirements:

1. Think about the priority of your requirements

2. Collaborate on who you need to get commitment

3. Prepare a story for your target reviewers

It is important to lead your product team to a conclusion on your requirements.  You need one of these outcomes:

• Commitment to planning the effort to deliver on the requirement

• Decide not to do the requirement

• Defer the planning of the requirement until a trigger brings it up for consideration

Too many other things are competing for your product management time to leave requirements hanging out with no direction!

Let's talk about the strategies to get a response to your requirements.

Get the Priority Straight by Collaborating

Talk to potential reviewers of your requirement about the priority of the requirement.  You likely have an opinion of the priority and this is a good basis of 1 on 1 conversations with your team about the priority.

Suppose you have written requirements about auto-discovery during the installation of your SaaS product.  Customers are making mistakes and need to get help from Support to complete installation.  Your program manager is about to put this in the backlog since no one from engineering is planning to address this.

You meet 1 on 1 with engineering to discuss the priority of this auto-discovery feature.  You learn the following:

• Architect thinks this is low priority because it is high effort

• Test leader thinks this is high priority because it will make testing easier

• Sales engineer thinks this is high priority because service activation is delayed

• Lead software engineer thinks this is high priority since he has a script that does auto-discovery

Now you got a breakthrough!  Your requirement can be handled with a script.  You hold a follow-up review of your requirement and engineering agrees to include the feature in the plan.

Collaborate to Find an Owner

Sometimes a requirement is high priority but no one is working on a plan to implement the requirement.  This happens a lot on features that have business requirements.  Software licensing, usage tracking, and freemium versions of products are examples of requirements that are hard to get committed.

The strategy in this case is to break the requirements into business and engineering parts.  You need to write the requirements to align with organizational boundaries while orienting to the customer experience you need. 

Suppose you need to add a premium license tier to your SaaS product.  You have defined the user experience of ordering and upgrading to the premium license.  No one is planning for this feature.  You decide to break the premium licensing into 2 parts:

• Business licensing for your IT team to implement in your licensing system

• Engineering requirements for using the updated licensing keys from IT

With this separation, you and your program manager can work with IT and engineering independently.  When both the IT work and the engineering work are done, then you can enable the premium tier of service.

Make the Benefits Clear

Sometimes your most straightforward requirements just don't get any attention.  Often performance improvements and UI improvements fall into this problem.  Examples of these requirements are:

• Reduce the installation time by 25%

• Provision customer data before accounting data

• Support more transactions per second

Simple requirements that have multiple solutions across the product team.

The strategy to break out of this limbo is to provide a story behind the requirement.  With a story, engineering can address a specific issue.  Examples:

• Reduce installation by 25%

  • John kicked off the installation in Public Cloud and it took 4 hours to complete.  He was charged for 4 hours of reserved computing with no benefit.  A reduction of 1 hour provides 25% savings to John.

• Provision customer before the account

  • Lisa uses your SaaS product for her small business customers.  Each account has one customer per account.  Lisa has to put in duplicate data for each customer and each account.

• More transactions per second

  • Zac has several enterprise customers of your database service.  Zac's largest customers are unhappy with the response times on database queries.

You might feel uncomfortable that these stories only address part of the requirement.  Your goal is incremental improvement.  You can always write new requirements after getting these requirements finished!

Conclusion - Break Your Requirements Out of Limbo

When you can't get commitment to develop your requirements, it is easy to get frustrated.  You might feel powerless to influence work on your requirements. 

After your hard work in writing clear requirements, there are 3 strategies to drive requirements into your product plan:

1. Confirm the priority of your requirements with your product team

2. Collaborate on who owns the plan for the requirement

3. Communication on the problem behind the requirements

By using these strategies, you can drive the closure of each requirement into:

• A committed plan for implementation

• Cancellation of the requirement for business or demand reasons

• Deferral to your backlog until a triggering event

The benefit of these strategies is progress on the backlog through teamwork and collaboration.

---

Related Articles

Requirements Tracking for Product Quality

Communicating Your Intentions

When Frustrated, Write a Requirement

---

Product Management IRL now has a paid subscription option! Many of the articles in this newsletter come from my experience in product management. Once a week I write the backstory of an article in Product Management IRL and what happened when I put the article into practice. This gets sent to paid subscribers on Friday nights.

If you are interested in the paid subscription option, you can learn more by hitting the upgrade button

or get a free month for referring 3 subscribers