Recently, I had lunch with a bright young product manager trying to perfect the process for deciding which features to include in his next product release. Skipping past theory about “internal ROI” and other quantitative approaches, we talked about having to choose among the many demands for enhancements from sales teams: that MRDs are only the starting point in an ongoing lobbying campaign for product improvements. In other words, product managers will always have to manage the emotional world of people and internal politics.
First, Let’s Set the Stage
As product manager for the next version of TechX, you’ve collected a nearly infinite list of possible improvements, advances, new features, and architectural repairs. Your goal is to build an orderly list of items, review them with Engineering for size and suitability, then issue a definitive requirements document (MRD or PRD) that formally declares what will be built. Being analytical and a bit compulsive, you think of this as the end of a long process, after which Engineering will leap into action.
You’ve had to make choices from a dissimilar list of potential projects:
- Customer specials needed by specific big accounts, even if they are not likely to be of general use to others (more on this later)
- Broad feature improvements as demanded by the market, reviews, user groups, and your keen sense of what customers want
- Internal architectural changes that will be invisible to customers but are needed for improved quality or longer-term goals
- The occasional high-profile product bet anticipating emerging market needs or hoped-for shifts in related technologies
Trade-offs within each group are easy, but across groups are nearly impossible. Part of your job is to balance these different categories so that your next release meets a few needs from each group. (Does this sound like a state budgeting process?)
Within each group, you try to draw up rational criteria. Among features demanded by specific customers, you look to your sales teams for revenue commitments and certainties. (“How big is the deal? Is this the only feature blocking the sale? Can we get a commitment from the customer to buy if we deliver by March 15th?”) You probably built a deal-specific spreadsheet to track opportunities and likelihoods, which you will need later.
For more general market requests, you poll sales teams and industry analysts. Engineering typically demands a few sacrifices to the gods of architecture, so a few of these make the cut.
In addition, you are trading off time and resources against your overall list. For example, adding a data conversion option will push back the release date by two weeks. Including Voice-over-Telepathy costs five month. Since most engineering schedules run late, you need to negotiate a delivery date that gives you some breathing room. Etc.
Ultimately, an MRD is the culmination of intense negotiations with all parties (engineering, marketing, sales, customers). It represents a compromise based on your best judgment and the facts on hand. BTW, great PMs deliver superior MRDs and also leave each constituent group feeling valued/respected/listened to. After emailing the final MRD to all groups, your team takes you out for a well-deserved celebration. This feels like a milestone.
But The Fun Has Just Started
Nearly immediately, two kinds of problems arise. One is caused by actual changes in the world: shifting customer needs, market trends, product experience, and general evolution. The second is lobbying from the sales teams who did not get their favorite enhancements into your MRD. By making hard choices about which features are in your next release, you’ve had to postpone other legitimate requests.
A quick aside about your most successful sales teams: they are experts at understanding and influencing how customers make decisions. Faced with customers who want to make rational buying choices using objective criteria, they will cajole, schmooze influencers, rewrite RFPs, promise upcoming features, sponsor golf outings, scrutinize budgets, and generally work to tilt rational decisions in your company’s favor. This is precisely what makes them so successful and so valuable to your company. And why they take deals away from less aggressive competitors. And why they wield such influence internally.
What should you expect from sales teams that don’t get their favorite features committed in your MRD? The same behavior that you’ve consistently rewarded them for: lobbying Sales executives about the strategic importance of their deals, having customers call you demanding action, rejiggering revenue projections to improve relative ranking, taking you to lunch, asking your boss to send you “into the field” for a week, insisting that one more feature can be shoehorned into the release. You may call this “politics.” Sales teams call this “influencing decision-makers to improve the MRD process.” Remember that you normally applaud this approach.
Now, we have an analytically-minded product manager beset by account teams trying to reprioritize the MRD. Each sales team has some legitimate argument or new information to present. You would rather be managing the next phase of product delivery than listening politely to ten more pleas for help. How did you find yourself in this situation, and what can you do next time to avoid this trap?
Political Issues Require Political Solutions
Allocating scarce resources always leaves some people dissatisfied, and drives them to escalate complaints or question the decision-making process. This is certainly true of MRDs, which prioritize Engineering’s projects and schedules. You can call this “politics” if you like, or “group decision-making” or any handy phrase from the MBA Organizational Behavior handbook. Regardless of the label, even the perfect MRD will leave some of your constituents unhappy. To keep the process moving forward, you need political support for the decision process and your final choices. Generally, I’d suggest this comes out of a pre-negotiation with the head of Sales. Imagine this discussion with your VP of Sales:
- “If we’re going to hit our delivery dates for TechX version 5, we can allocate up to 45 engineering-weeks to one-off enhancements for high profile customers. I need your help to support the most important deals. I’ve built this spreadsheet of requests, required effort and likely revenue.”
- “OK”
- “Looks like we could commit to these 5 special deals for GM, Goldman Sachs, Deutsche Telekom, the Air Force, and Safeway. That leaves 20 other deals uncommitted, including Sloan Kettering and FedEx. Are there any you’d move up the list and replace the ones I chose? After all, I’m just a lowly product guy and not the all-knowing head of Sales.”
- “This looks about right. Good job.”
- “One other thing I need: those next 20 account teams are going to be pushing you hard to get their enhancements back in. I need your commitment that we won’t add any to the list without pulling off one of these 5. If we expand the requirements, the release date will slip and you’ll lose several of your top deals.”
- “Hmmm. How about if I go over your list with my regional managers and make sure this is right? We’ll get back to you by Monday”
- “Absolutely. You’re my customer on this. After your meeting, I’d love your initials at the bottom of my spreadsheet, so that I know I have the right information handy for follow-up discussions…”
What just happened? You found someone in Sales to help make and confirm decisions, and a defined method for considering changes. When the sales rep covering United Airlines calls you, feel free to explain that her VP of Sales approved the final list. This also sets up a more rational discussion about changing priorities: if FedEx is suddenly more important than Safeway, you can explore the revenue and technical trade-offs involved in swapping their place in the queue. Getting “buy-in” from Sales management means that your choices are more likely to meet Sales’ overall goals and revenue objectives.
Of course, this applies to the other key constituents of your MRD: executives in Engineering, Marketing and perhaps Finance or Manufacturing. Having your decisions ratified now by future lobbyists will keep things moving.
SoundBytes
Product managers are paid to make decisions that have an impact on the broader organization. This makes us part of the internal political process. Rather than ignore this reality, we need to understand how decisions are made and re-made, then design our processes to let the real world help us.