Recalibrate product priorities for the next 6 months

Flickr image source: http://tinyurl.com/pb94a5u

As we approached the half-year mark, I recognized that I needed to regroup with my internal stakeholders to make adjustments around what we would be delivering for the second half of the year.

You could argue that the half-way point through a calendar year is a somewhat arbitrary juncture, but nevertheless it provided me with a good checkpoint opportunity. Since the beginning of the year, my team had planned, built, tested and delivered product updates through several releases. Before we commenced with the next cycle, I wanted to revisit our priorities and review any significant changes in the business that would require some course correction in the product roadmap.

What drove this decision

I was confident that the Product team had been addressing the full range of demands and that we would continue to balance stakeholders' priorities as we were all committed to satisfying our end customers' needs.

We had already begun to carve out big plans for the next 6-9 months and some of them would require significant investment. I knew we were aligned with individual departments but over time, the various department heads had lost sight of what was most urgent for their peers. It would be more difficult for me to deliver and promote an updated product roadmap without some preliminary group consensus at the topmost level.

The decision: Organize and facilitate a product strategy summit with all the department leaders to revisit and rebalance priorities.

I will be the first to admit that the word "summit" sounds a bit lofty (pun intended) but I assure you this was not some trumped up, off site boondoggle - I'm saving that for my big end of year 1st Annual Product Strategy Retreat.

My goal was simply to get all the department VPs and some key Directors in the same room and run through a formal, Product-focused agenda. I wanted to use the time to review the roadmap choices we had made over the last 6 months (some good, some bad) and continue to push the company to pursue sound product investment decisions.

Balancing 3 related concerns: curb appeal, interior living space, and structural foundation 

In the many discussions I had been having with the different departments leading up to this summit, it became increasingly clear that there was a lack of mutual appreciation, if not basic understanding of what was driving the other departments' priorities. A number of the stakeholders were out of touch.

I wanted to share this insight with the invitees but in a way that didn't offend or alienate a particular group. In the summit invite, I offered the following apartment building metaphor to help explain the different, but complementary perspectives of each group:

Image sources: http://tinyurl.com/nbzkcoz, http://tinyurl.com/pno7n9f

• Sales wants the building to have massive curb appeal, to look good from the outside so as to increase the chances of attracting new customers.
• Customer Success wants all our new tenants to have a smooth move-in experience and to enjoy living in their new home for many years.
• Operations wants to make sure the building itself can safely support all the tenants and their various housing needs.

And of course everyone in the organization should be focused on increasing customer satisfaction as it will lead to renewals and referrals!

Plan of attack

Setting proper expectations: everybody wins! everyone loses!

I started the meeting by setting expectations for the group - which largely meant telling them that no one was going to get everything they wanted. The summit was an exercise rooted in compromise. I told them that it was equally important for them to defend their own priorities as it was to become more aware of what the other departments were struggling with.

The bulk of our time in the summit was spent prioritizing a lengthy list of wish list items. To kick things off, though, I offered an assessment of the past six months to remind everyone why we built the things we did and to get some feedback.

Review the roadmap themes for the year

I first presented the product strategy I had introduced at the beginning of the year that outlined how I would be making decisions for the next 12 months. Specifically, I highlighted the roadmap themes that were established back then and verified with the group that we were still confident in those decision-making guidelines.   

Review 1st six months

Building on the initial validation from the group, I proceeded to show how the recent product decisions we had made were in line with the roadmap themes. This brief, high level review of the advancements we had made in our product portfolio over the past 6 months provided an ideal opportunity to explore queries such as:

• How accurate was the original plan and how close did we come to hitting our targets/metrics?
• Are the major initiatives still on track or have there been new insights that require us to adjust our course?
• What have we learned about estimating work, about dependencies, about our ability to accurately respond to customer demand?

I was certainly pleased to hear the group confirm that the first half of the year was largely productive and that we had been made solid product investment decisions.

First pass at prioritization

From the Trello board I created to capture individual wish lists for the different departments, I pulled the top 30-40 cards to start the prioritization exercise. The first step was to bucket the items into either one of only two lists: High Priority or Low Priority.

This first pass proved to be relatively easy for the group. I was pleased to see the Low Priority list ultimately accumulate many more cards which meant the final pass would be that much easier.

Overall, it was a constructive discussion. None of the participants were particularly unreasonable and did not fight excessively for their own items.  I did occasionally use the following prompt when we seemed to be getting stuck: "Can we get through the second half of the year without spending any time on this item?" That was often the only nudging that was required to properly bucket the topic.     

Crash course on product constraints

I had prepared a break in the summit schedule in case we needed a cooling off period - and intentionally scheduled the catered lunch to arrive during the break. It turned out there hadn't been that much contention so I instead used the break to revisit some of our constraints and to remind the group about why the next half of the exercise was going to be frustrating for all. Specifically, I talked briefly about the following topics:

• Our true development capacity - what we should really expect from the current size and skill level of our Engineering teams. Read more about setting expectations around Engineering capacity here.
• Software's total cost of ownership - how each line of code we add requires more of our company's resources from Product, Engineering and QA all the way through documentation, support, and training.
• Opportunity costs - each time we agree to start building something new, we must recognize how that will limit our ability to respond to the next "must have" requirement (yeah Sales, I'm talking to you!)

I can't be sure if all the messages landed on point with the entire group but it was my meeting and I was going to take advantage of this ideal product soapbox opportunity.  

Final pass at prioritization

In the home stretch, the group now turned its attention to reviewing the much shorter High Priority list (14 items, down from 40). One by one, I went around the table to get individual input. I guided the group by having each of them select 1 primary item and 1-2 backup items.

When we had finished the final pass, we had arrived at a prioritization list that had mutual support from all departments. And I had a clear indication of how I would be adjusting the Product Roadmap for the second half of the year.

The impact

Not only did we finish the full exercise (on time no less) with a shared prioritization list but I was told afterwards by the group members that it was one of the more amicable and productive meetings around product direction in which they had participated in recent memory.

I made it clear to the group that the summit was not designed to immediately produce a new or updated roadmap. It would take me more time to work through the items on the High Priority list and factor everything into the Product Roadmap for the second half of the year. Still, I would like to believe the outcome of the summit extended beyond achieving consensus around particular product priorities. I think it represented a milestone for advancing inter-departmental agreement. Maybe next time, I'll refer to it as a Product Peace Accord.

Look for more reports from theProductPath around feature prioritization, product strategy, and managing stakeholders here on PM Decisions.

More articles from our blog PM Decisions

Create a shared space for departmental wish lists

In accepting a PM position with an organization that had no central place to capture and prioritize product-related requests generated from each department, I decided to pull together the lists from all the stakeholders into a common forum.

Of course departmental wish lists had been created over the years but were languishing as disparate spreadsheets, as bulleted lists in shared Google docs and as giant backlogs in our issue tracking software. These lists had not been kept current, were not being shared, and thus were impossible to synthesize for product planning.

What drove this decision

So what I really inherited was a bigger challenge and this was a known problem throughout the company. The lack of a central place to discuss product priorities had led to more than a few skirmishes and past product releases had been poorly received as various constituencies inevitably had begun to feel neglected or and complained that the Product Team simply misunderstood their needs.

I am now in charge of the Product Roadmap. As any Product Manager knows, this is a challenging assignment as it involves collecting, verifying, and prioritizing inputs from many stakeholders. To get started, I wanted to review any previous roadmaps and revisit the current backlog of requests from Sales, Customer Support, Operations, etc. The old roadmap was easy to locate but when I started asking around for the backlog, I was surprised to learn that there wasn’t one.

The decision: Introduce the team to Trello

I needed to (re-)create a forum where each department could list their own issues and make them visible to the other groups. It had to be conducive for collaboration and ultimately, allow stakeholders to collectively agree on the next set of priorities. But most of all, it had to be easy to use.

I decided we would begin planning high level product strategy using a shared Trello board. Trello is a flexible online tool that helps you organize lists and is very simple to use. 

• The free version would more than suffice for the size of our team and our limited needs
• Those who chose to invest more energy in capturing their requests would have ample means to do so using Description fields and other Trello features
• Each card would have its own comment thread to encourage and preserve group discussions 
• Users have the option to use card-level voting to avoid duplication and find common ground
• Plus, the good folks at Trello have made it work equally well in browsers, on tablets and on mobile phones

Plan of attack

I cannot share our company's product priorities here of course but you may adapt this approach for your company's own planning needs.

Build new board with a good name

I started by creating a new Trello board for our company and named it “Roadmap Priorities”. I chose the name intentionally as I knew I would need to push back on well-meaning folks who would get carried away creating cards that were important to them and the company, but ultimately unrelated to our product strategy. Instead, I encouraged them to create separate Trello boards for their own departments.

Create a list for the current release

To provide some perspective to the group, I created the first list on the board and backfilled it with cards that represented our current set of priorities, mostly to provide a model for what we would be aiming for in future strategy sessions. I made this the left-most list on the board so they would see it first and that proved helpful in on-boarding users who were new to Trello.

Prime the board with existing lists and examples

I created separate lists for each Department so that each would have a place to add their own set of cards. In an effort to prime the pump, I imported a few lists from existing spreadsheets that had been floating around some of the departments. For other groups, I created some sample cards to give them a starting point. In this way, I was able to accelerate the adoption of Trello and the roadmap planning discussions. 

Use colored labels for Each department

I used Trello’s colored Labels to assign a unique color to each department. This has made it easier to identify the originating department for each request and, as we move over cards to create a single “Release” list, has allowed us to see the relative priorities of each department. Even better, by combining multiple departmental labels on a single card, we were able to quickly find common ground among common requests. 

Invite collaborators to the board

I formally invited all the department heads to join the board. For some teams, it made sense to invite more than one person, especially where I anticipated some early, tool-related friction. Each collaborator received a friendly email invitation with a simple call to action to join the Trello board.

Onboard stakeholders

Even though Trello makes the sign-up process easy for new users, I expected and struggled with early engagement. As a precaution, I also schedule 15-minute meetings with each stakeholder to get them past the initial access challenge (e.g. logging in) and to provide a quick tour of Trello. The preparation (described above) went a long way to getting early buy-in. Stakeholders immediately identified with their department and were comforted to see familiar items in their own lists.

In explaining to the stakeholders how I would be using the board and the cards on each list, I also tried to motivate them by strongly implying that the best prepared departments would have a chance of seeing their priorities folded in to our roadmap.

The impact

The results for our company have been quite promising in these early weeks. Five of the six departments have been very active on our Roadmap Priorities board and that is making the planning for our next release much easier for the Product team. Trello deserves a great deal of the credit for providing such an amazing tool and we have witnessed its broader adoption throughout the company.

Look for more reports from theProductPath around Trello, roadmap planning, and working with stakeholders here on PM Decisions.

More articles from our blog PM Decisions