Facing the Hydra:
The Product Team’s Role as the Company Emerges from Crisis
Before the crisis I could have said that your job is the most complex of them all — you’re under pressure from all directions, while you can only influence the major actors. All of the responsibility, yet very little authority. But now, in the midst of the race out of crisis and toward a winning position for your company in uncharted territories, I will say that your job is even more challenging.
While all of this is in progress, you can’t just feed every constituency with a little fodder and get them all to take afternoon naps until the next discussion on content of the following release. Now you need to bet on winning horses and convince your internal clients that these are the best bets, and that they should please have lower expectations for getting one of their favorite requests into the plan. I don’t envy you. Your job as VP Product Management is nebulous at times, but now it’s immersed in fog.
In order to clear some of the fog and help you stay focused on the essence of your executive role, I recommend that we break down your team’s responsibilities into hard and soft skills, and start examining it with the former category. Hard skills of your team are in writing user stories, the soft skills are all the communication activities around it.
More than ever the quality of your team’s work should inspire full confidence and no doubt. That means that the output of story tickets – documents designing the user experience of features – is going to be accurate, comprehensive, modular, clear to the people who need to read it, and delivered without delay. Here are a few internal techniques I employed to help my client companies raise the quality of their PM output during that key part of the work – authoring tickets.
PM Pairing. I’m sure you recall from your highschool or university years that doing homework with a friend improved the experience and the output’s quality. This is true in general – an idea is always improved when it’s being talked about (that’s why for each good idea you’ll find more than one person claiming to be its parent). Working in pairs and doing mutual reviews also guarantees that more than one person has knowledge on each work item, thus you’re avoiding knowledge bottlenecks. PM Pairing will immensely improve the quality of the tickets’ first version.
Ticket Review. You’ve seen the concept of Code Review in Engineering and you know why it’s used broadly and how it’s done. For the same reason you should create a standard process inside your team by which each ticket goes through a Ticket Review by unbiased peers, i.e, not by theauthor’s PM pair. If your team is large enough, there will be enough PMs to assign as reviewers; otherwise, create a pool of peer reviewers from outside your team. Only once it’s improved with the peer recommendations will the ticket be ready for discussions with engineering. Employing Ticket Peer Reviews will reduce the number of interactive cycles with engineering, it will improve the professionalism of your PMs, their self confidence and outside perceptions.
Tickets templates. I assume you already have templates for how to write user stories in a structured manner. I will suggest, however, that you review these templates with your mind on the readers. Developers read such documents very differently from marketing personnel, for example. Those tickets need to satisfy all varieties of reader needs.
Checkpoints with R&D. A few steps into the overall Roadmap process have concluded, and the finalist tickets make it to R&D. One of the major productivity issues that I have seen occurs right on the frontline between Development and PM teams. If you see, as I have seen in quite a few instances, that there’s some going back and forth with a few tickets once an engineering difficulty is encountered, you should put standard checkpoints to minimize the waste effect of these iterations. The idea is to catch the gaps as early as possible while they are still small. Weekly or bi-weekly checkpoints of tickets in development will prevent a lot of rework that’s usually unaccounted for, and yet it adds up to overall delays in delivery. Another side benefit, albeit important, is the learning and experience that PMs gain through these checkpoint interactions.
The techniques I described so far are relatively simple to apply; they’re regimented easily. All you need to do is to enforce the process and the discipline inside your team. The quality of your ticket factory will improve without additional effort. 
The more challenging aspect of your role lies in how you manage all the key actors who influence the content of the roadmap. It’s a huge communication challenge with components as diverse as: listening, proactive listening, satisfying interest groups with different focus and goals, considering the outside industry trends and balancing with the capacity of the development group. And if the development team is occupied with a big project, as it sometimes happens, like a change in infrastructure or architecture, you may find part of your team working for a while only for the drawer without ability to execute any of it. The following are some points that will help you put some order in the chaos and clear some of the fog.
The most helpful action is to set a standard calendar of meetings and actions for each release. If it takes 4 months to work on a release from start to finish, design all the steps and set the meetings on the calendar with all invitees, and with specific agendas embedded inside the meeting invitations. This calendar will serve as a metronome to pace a lot of the company’s internal activity that you, as VP Product Management, are charged with leading. You’ll gain efficiency because all participants will be prepared better for the meetings and you’ll save coordination time. Moreover, when all stakeholders are used to the regular steps of the process they won’t feel the need to peddle their ideas in an ad-hoc manner, since there will be a pre-designed place for every type of input.
Start the process with a meeting of all stakeholders to hear the strategic guidelines for the next two releases. This could be divulged from the head of marketing, the CEO, or whoever is the actual head of product strategy for the company.
The next phase is the parallel meetings with each interest group to collect inputs and vet ideas. Customer Success, Sales, Marketing, a sample of existing and prospective customers and R&D, they all have interests that could be conflicting to a certain extent. For example, Sales will want the feature that will enable deals, while CS might not be prepared to support customers in the usage of such a feature. Sales will want to prepare the product for a new market segment, while the strategy of the company doesn’t include this segment. And these are just two common examples. The most important aspect of the meetings in this phase is to allow every stakeholder to be heard and proactively listened to. R&D is also a stakeholder because it might have technical debt to attend to, and also because a bunch of engineers have some good ideas.
With all requests gathered it’s time to create the first version of the roadmap and run it by R&D. A good capacity allocation of engineering resources should follow a balancing rule such as: 50% for tickets coming from PM, 20% for bug fixes, 30% for code health (infrastructure, architecture, code quality initiatives). It will be a mistake to demand all of the engineering capacity for PM defined tickets. It will not pass a reality check, so better don’t attempt it. The more pressure you put on engineering for a larger allocation, the more you will pay for it later when engineering is consumed by big projects that could have been prevented. At the end of this step you will be able to divide the tickets into groups such as: likely included in the coming release, likely in the following release, not likely as defined.
Ticket development. With the output of the previous phase you already have a roughly prioritized list of requests, a rough idea of what might go into the release. You could start your team working on those higher likelihood tickets.
Final Roadmap. About one month into the work on tickets, your team already has a better grasp on the weight of each ticket. You can now prepare with your team a proposal for the final roadmap. For reviewing this proposal you have pre-set a meeting with key stakeholders (not all) to review the feature candidates and decide on the roadmap in three tiers: features that should be in, features in second priority, and features that will probably not make it into the roadmap and that should overflow as candidates to the following release. This proposal should now be reviewed with R&D to decide on the committed roadmap. With the R&D leadership team together with the PM team, you will draw a red line above which are all the committed items by engineering and below it are the “maybe items”. This final roadmap should be communicated to all internal interest groups – sales, marketing, customer success, etc.
As the funnel of requests is being streamlined from one phase to the next in the waterfall process that I described, you, the VP of Product Management, will be faced with ripples and echoes coming from all the dissatisfied interest groups as they see the evidence of their requests shifting lower on the priority list. Some of those ripples will try to circumvent you and go directly to your team members – it’s a multi-headed hydra. Your ultimate test is to stand erect, protect your team from such disruptions and stick to the process. The best communication technique for these formal and informal conversations that you will be pulled into is to let the facts do the talking, such as: “I may agree or disagree with you, the facts are that we went through a methodical vetting process and that’s the result of it. Anyone who challenges the choices we made is welcome to influence those decisions in the next checkpoint”.
As you progress from version 2 to the final version of the roadmap, you will probably enter the step with a list which is at least two times bigger than the discretionary (50%) R&D capacity to execute. Most items on the list have been prioritized as priority 1. There are several voting techniques that will help you select the items that are priority 1 from the ones that are priority 1.5. The technique I like the most reduces the list in one voting round usually, and that’s voting with a fixed “budget”. Here’s how it works. Each voter gets a wallet of 100 “coins” and they are instructed to put as many coins as they like against each item on the list. For example: 20 coins on item B, 15 coins on items A, D, G, and then 5 coins on 7 more items. This voting technique forces the participants to bet their money on winner items. It’s highly effective also in surfacing the true convictions that each participant has.
Agile vs. Waterfall. No matter if R&D employs Agile as their governing process, or if your PM team is a regular participant in it. Agile is the best process for work in progress. The waterfall process that I recommend is upstream of the work in progress. It’s meant to create the lighthouses that give direction to the Agile team. If you’re one of the lucky VP Product Management that have fixed lighthouses and no storms and undercurrents at sea, then you don’t need the process I described above. But, I highly doubt it.
Paralel calendars. Don’t get confused if by designing the calendars for two releases, the coming one and the one following, you will have during the same week two (or sometimes three) sets of meetings from the cycles of different releases. If your release cadence is every 3 months and the waterfall process for each release is 4 months, then you’re bound to have these releases step over each other on the calendar. Your role is maintaining discipline and not letting meetings drift off their pre-set agendas.
As VP Product Management you need very strong hard skills and very strong soft skills – that’s the nature of the job. Follow the guidelines above and use them as a checklist to do periodical reflections and corrections, and you will come out as an impressive VP of Product Management, totally in control in conditions of fog as well as in a sunny clear view.