In my experience, all of your stakeholders have ideas on how to make your product better. Some are more proactive in sharing them, but there is rarely a lack of incoming ideas to the product team.
Frequently, industry discussion on handling these ideas focuses on giving quick feedback and uncovering the underlying problem/need the idea is seeking to address. Tools like Aha and Craft provide portals for clients and other stakeholders to provide ideas directly and get into this discovery funnel. These enable the entire community to be engaged in reviewing, commenting, and giving prioritization input.
The challenge that many enterprise Product Managers face is not tackling these individual requests, but dealing with a spreadsheet of 25-100 requests coming from a single customer. Repeat this over multiple customers and you have a Product Manager that feels like they are drowning in reaction mode.
Moreover, the customer may want a firm status on each item and to have regular follow-up meetings. In each follow-up meeting, they may have additional requests and adjustments in their priorities.
This is a common challenge for newer enterprise software products. Even more mature products that are expanding into new customer segments or markets. If you discuss this with Product Managers of B2C or B2B limited scale apps you are likely to get unactionable feedback like:
-
You should focus on the market not one loud customer
-
That sounds like you are a custom project shop.
-
If that customer represents over 20% of your business you are too concentrated.
-
Just tell them no.
I am here to tell you that you are not alone. This is not that unusual. You are not in some broken parallel universe. You need to deal with these requests.
You are not Alone
Buyers of enterprise software are making a very large bet on your company and product. Buying a product typically involves a large budget allocation for acquisition, implementation, and training. Moreover, there were likely opponents to the selection of this product who favored (and still favor) alternatives or doing nothing.
This creates great reputational risk for the buyer and team now responsible internally for demonstrating success. It only stands to reason, that they will want to push you to help them to:
-
Close perceived functional gaps that opponents continue to raise
-
Deliver nice-to-have features for key executives/influencers to gain their support
-
Fix those design flaws that could not have been known during due diligence (which they now refer to as Bugs)
-
Fix any actual technical defects that they have uncovered
-
Ensure your roadmap aligns closely with their changing business needs
-
Demonstrate you are committed to their success
-
Assure them they made the right decision so they don’t view you as a risk to their continued employment or general professional success
And so on…
How to Tackle
First, let’s acknowledge that having customers this engaged is a great thing. If they are ambivalent about your mutual success you would hear nothing from them and should be very concerned.
Here are the steps that I have used to successfully navigate these situations.
-
Thank and acknowledge their commitment to being successful
-
Meet to review the spreadsheet
-
Post customer meeting triage review
-
Automate, systematize ongoing tracking
-
Follow-up review the status of existing requests
-
Engage the customer in discovery
1. Thank and acknowledge their commitment to being successful
Starting off on the right foot it critical to these customer relationships. As the Product Manager, you want the customer to be aware that you have received their list as soon as you get it. Do not wait for discussion with other internal stakeholders but make sure you acknowledge this input they have provided.
In parallel to setting this meeting, be sure to review the list for any low hanging fruit that can easily be rectified before the meeting. These may be issues resolved by answering a question, recommending some training, or modifying a setting.
There is absolutely no reason to wait to tackle these issues. Show up to the first meeting with progress to report on these quick wins.
2. Meet to Review the Spreadsheet
During the first review of this list, you must set the expectations for how you will be treating these requests. This is an important chance for you to align on terminology and how you will be working with them to ensure they are successful.
Attending this meeting should be key people from the product team and delivery team involved in this customer implementation. From the product team, this should be the Product Manager, Product Designer, and Engineering lead or their delegates. As this may be a crucial relationship building for the future, it is best to be done in person whenever possible.
On the customer side, they must come with sufficient expertise to discuss every item in the spreadsheet.
Your team’s goal of this meeting is to listen and learn, but also to shape their expectations of how you will tackle these in a way that makes them feel heard.
I recommend that the meeting starts with the customer sharing their current deployment status and high-level plans moving forward. This will provide you the necessary context to adjust toward during the rest of the meeting.
Follow this with a pitch of your Product Vision and Strategy. Describe how your organization relies on this as a context to decide which problems to tackle and when so that the customer understands your prioritization approach.
There are only two ways to influence human behavior: you can manipulate it or you can inspire it.
Then provide them with an overview of your approach to performing Product Discovery, Development, and how you release product updates. Show them there is a methodical process to uncover the best approaches to solve the most worthwhile customer problems.
Once this critical groundwork is laid, the customer will be in a better position to understand why you make decisions that you do moving forward. Further, some customers will actually shift into problem-solving mode and work more collaboratively with you to optimize their agenda within your constraints.
From here you can review the full spreadsheet. If this meeting is done remotely, it will likely need to take place over multiple sessions. The goal of this review is to understand the ask and impact from the customer. Communicate up-front, that you will not be committing to solving anything during this review.
Close by scheduling a follow-up review, which can be done remotely.
3. Post customer meeting triage review
After the customer meeting, bring together the key product and delivery team members internally to triage the request list. Here you will rapidly review and split the requests into the following buckets.
Solvable now with the existing product – Delivery (or Customer Success) Team owns
Aligns with strategy – Product Team owns
Outside of the strategy – Product Team owns saying “No” to.
At this point, it is important to split the follow-up, assuming the Delivery and Product Teams work on different time horizons. The Delivery Team can generally move to take those items they can address back to the client to discuss a resolution.
The Product Team will take those that align to strategy, those that do not, and those requiring more research.
4. Automate, systematize ongoing tracking
At this point, the Product Team will take requests they own and add them into whatever scaled mechanism they are using to track requests and defects. For all the requests, the team should be translating these into desired outcomes and mapping the customer requests to any that are already being tracked.
This consolidated set of desired outcomes and defects should be incorporated into the product backlog and prioritized according to the product strategy.
From this point, the Product Team should be able to assess what fits into the existing roadmap plans. For example, the customer requested a feature to solve a problem that you already planned to solve in the next 6 months.
Without creating new commitments or rearranging your roadmap such that it no longer aligns with your strategy, you now have sufficient information to have a follow-up review with the customer.
5. Review the status of existing requests
In the review meeting, it is important to do a quick recap of what you have done so far. The number of requests raised by the customer, some have already been solved and some are getting address with the delivery team.
Now you will walk them through the requests that the Product Team has handled. On each, you explain the interpretation of the underlying problem/need it solved which may differ from the language of the feature requested. Then indicate which requests you will not tackle because they do not align with the product strategy despite being potentially good ideas.
People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas.
Follow this with a deeper review of the requests that did fit the strategy.
If you have a customer request portal, available to all, you can now direct the customer to access this website for ongoing tracking of these existing and new requests they submit over-time. The goal is to get into a continuous flow, and rhythm with the customer rather than periodic batching of requests. The transparency and automation will build trust that you are committed to solving meaningful problems to them.
A public portal view of the ideas coming from all customers gives them a broader perspective and appreciation for your support.
Periodically, you should still meet with the customer to discuss their overall status and share updates to your product strategy and roadmap. In these forums, you can focus on higher-level feedback to your strategy and supporting the business in managing a healthy relationship.
6. Engage the Customer in discovery
Now that you have built a solid relationship around shared goals with the customer, you can further strengthen the bonds by directly engaging them in your discovery process.
This type of deep engagement will re-enforce your commitment to your customer and ensure you have the best possible chance to deliver valuable solutions to them as well.
In large organizations, this discovery work may occur with users and managers of the software but not with the buyers themselves. Be sure to communicate with the buyer about these types of ongoing activities.
Avoid Unnecessary Landmines
There are a number of landmines that we can create for ourselves as Product Managers that can be predicted and mostly avoided. When managing a long list of requests from a customer these are some of the ones I have seen repeatedly.
Think about the issues from the customer perspective, not how your organization is structured.
In enterprise software companies, the customer may have purchased one solution from your business but it internally encompasses the work of 5 different product teams with 5 different Product Managers. They do not want to go through 5 different tracking and follow-up processes. That is an internal business issue for you. Figure out how to act as one interface to the customer. Do not make them adjust to how you decided to internally organize.
Make sure your Product Vision and Strategy context is relevant.
Frequently the vision and strategy for our products my expand beyond what the current customer cares about. Be sure to tailor your context to things that matter to them.
They want to know that your R&D investments are going towards things of value to them. Where possible, attempt to tie discussion of planned investments into things you believe resonate with this customer.
Example: If your customer only has domestic United States operations and your strategy involves expanding to EMEA next year, you may downplay this for these important 1:1 customer meetings.
Try not make commitments
Commitments are constraints on your business agility. Ultimately, they do more harm than good to the success of your customers. If you must make them, keep these to an absolute minimum and focus on committing to solve a problem not delivering a specific feature. Absolutely do not make these on the spot in a review meeting, regardless of how easy something looks to address.
Get alignment with your product team on these before making them. Even if you are sure of the result, it is important to engage the broader team in creating such constraints. After all, the whole team will be responsible for addressing it.
For more on this topic, check out Outcome Roadmaps with Feature Commitments
?Every single idea/issue does not belong in your product backlog
If the idea is not going to be considered in the next 18 months, don’t include it in the active product backlog. This just becomes noise. By the time you get to it, you will need to rethink the need from scratch.
Some experts say not to bother recording these at all, but given that some strategic investments extend our to Horizon 2 or 3 (multiple years), it seems reasonable to keep these requests but in an archived state. This will enable future discovery work to unearth additional inputs and decide then on applicability.
Conclusion
Being an Enterprise Product Manager can be difficult. When your product starts taking hold, all of a sudden you have customers that get very demanding and want their long lists of wishes granted.
First, take a breath. This is a good spot to be in.
Next… engage them in your Vision and Strategy. Remember that the buyer needs to see your product become a success too — or it reflects poorly on their decision-making ability. By working smart, you can build trust, a better product, and maximize value without getting bogged down in a spreadsheet blackhole.