Showcase roadmap to advance a large deal

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

To accelerate the largest sales opportunity in our pipeline, I agreed to lead a spirited, product-oriented discussion with the prospect free from any heavy sales pressure.

It is not uncommon for Sales to pull the Product team into large deals, especially late in the sales cycle where there is a need for even greater assurance that we are a vendor on which they can rely. I have developed and shared sanitized, customer-facing roadmaps on many occasions and have even delivered custom product demos to help our Reps close their transactions.

I do have to be careful about sharing too much information prematurely. Even hinting that the product may be headed down a particular path can send an overeager Account Executive spiraling off in a wrong direction. But I do appreciate the positive impact for a potential customer to "be invited to a private meeting with the head of our Product group." I also think it is valuable to assist in efforts like these and to maintain a healthy relationship with our revenue-producing Sales team.    

What drove this decision

 I am firmly against letting any one customer hold sway over the roadmap and my product priorities

I was familiar with this particular prospect - indeed we had all been watching the opportunity progress over the past few months. The use case was squarely in our wheelhouse but the prospect had identified a few specific feature requests that we might not otherwise have delivered in a suitable time frame. And while I am firmly against letting any one customer hold sway over the roadmap and my product priorities, I do believe there is room for a large, active user base to weigh in on decisions about product direction. 

The decision: Demonstrate an impressive pace of innovation through a series of past accomplishments and future intentions and encourage the customer to weigh in on the ongoing roadmap priorities.  

Image source: http://tinyurl.com/qjogg57

Customer seem to love talking about roadmaps. Even when you lay out all the disclaimers about lack of certainty and best guess estimates, there is still enough curiosity remaining to drive a lively conversation.

I don't mind sharing our vision for the products and where I'd like to take them in the months and years ahead. There are certain paths that are quite clear to me at the moment and others that are more directional in nature.

I am also very comfortable weaving a strong product story that incorporates past achievements with current work and that extends into the not-to-distant future.   

Plan of attack

As I mentioned, the meeting was not intended to be overly sales-y but the parties on both sides knew this would be another part of our pitch for their business. I built a product-focused agenda that put our offerings in the best possible light. I accentuated the products and features that were high on their list of needs, starting with items for which we had just completed development and moving to the ones that were still several months away.

Demonstrate A working version of an early prototype 

Previously in the same sales process, I shared some clickable prototypes with this prospect to give them an idea of where we were headed. One prototype in particular was more relevant to their primary use case and the prospect had showed great interest at the time.

The Product and Engineering teams had since made good progress with the development of this feature so I used this opportunity to walk the prospect through a fully implemented version. The feature was intended to be the highlight of the upcoming product release so the demonstration was positioned as an early and somewhat exclusive sneak peak.

Preview unreleased features

Another keen area of interest for the prospect happened to overlap with one of my high priority product initiatives. I had been pushing our internal teams to complete the first iteration of a major component whose full delivery schedule would stretch out for many more months.

It turned out that while this initial cut was not quite ready for widespread use, it was certainly viable for use in pilot exercises like the one the prospect had scheduled. Again, we emphasized the exclusive access being offered and made sure to highlight our company's rapid pace of development.    

Share detailed roadmap of prospect's most requested feature

After completing the feature demonstrations (which were well-received), I switched gears and walked through a customized product roadmap. The prospect had expressed a need for functionality that was not yet part of our product but that would represent a natural extension to the platform.

While I was careful not to make promises about specific dates, I was able to talk through a plausible plan that illustrated the incremental delivery of their requested functionality. 

Unveil results of relevant internal research efforts

In a separate internal research & development initiative, I had recruited a data scientist to help us look for useful and insightful ways to share the data we were collecting around our customers' workflows. She had produced some impressive dashboard-style reports and charts that were scoring huge points with our internal stakeholders. 

So, as the big finale to the conversation with our prospect, I rolled out these artifacts and tied them back to the workflows they would ultimately use in their own solutions. The resulting discussion was quite fruitful for both parties as we collectively described a future partnership filled with great potential.

The impact

The short version is that it worked! The conversation was very productive and we impressed the prospect enough to have them throw more weight behind the initiative. Nothing specific was promised but they did acknowledge our commitment to advancing the products and their unique opportunity to work with us to guide its long-term development.

Look for more reports from theProductPath around product reviews, socializing product roadmaps, and the PM role here on PM Decisions.

More articles from our blog PM Decisions

Complete an Opportunity Assessment for proposed new product

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

After disappointing results from my previous attempts to stall the momentum building around this "must-have" component, I decided it was time to break out the heavy artillery.

If you had read any of the articles leading up to this post, you might conclude that I have been fighting a losing battle. Indeed, I have been chronicling the story of my struggle with this new product idea over the past few months:

1. Head off a new product idea
2. Clarify win-loss speculation with post-mortem interviews
3. Build a quick proof-of-concept

Each of those product decisions was driven by healthy skepticism around my company's impulsive and in my opinion, short-sighted product recommendation to build an MS Office plug-In. For the record, I'm not against this product idea at all. The campaign I'm engaged in here has more to do with making good, long-term product investment decisions.

What drove this decision

New product decisions should not be driven by fear, such as the purported threat of some competitor's offering. Likewise, they should not be pursued just because the solution appears to be simple to build or is otherwise easily accessible. There are so many more factors that should be considered. And they should be considered together, holistically.

What I needed was a way to communicate the whole picture to my stakeholders. I wanted to engage in an open discussion around all the decision criteria. And I wanted to come into this conversation with the main talking points already distilled from a more thorough study and backed up where possible, by actual data from relevant research.

The decision: Use Cagan's Opportunity Assessment to approach this product decision with more rigor and less bias.

Marty Cagan's Opportunity Assessment is described in his book Inspired - How to create products customers love - a must read for Product Managers.

This product decision really had 2 parts. First, I knew that I wanted to use Marty Cagan's Opportunity Assessment, which is an excellent and straightforward framework for evaluating new product opportunities. I think it is one of the best tools a Product Manager can have in their "belt". I deploy it whenever I encounter exciting new ideas - my own or another's. The Opportunity Assessment helps you exert solid due diligence before a good sounding proposal gets too far along.

Second, I wanted to use the Multi-Tool, a PowerPoint-based tool created by the team at theProductPath for this exact scenario. The Opportunity Assessment Multi-Tool puts Cagan's framework into an easy-to-use PowerPoint structure where the user can capture, then distill, and finally present the Assessment all using the same tool. 

Plan of attack

In this particular instance, Cagan's framework lays out the "plan". I stepped through each of the questions of the Opportunity Assessment capturing my answers as best I could. Using the Multi-Tool, I was able to focus on each question in isolation, using the "scratch area" on each slide to record all my rough notes.

When I felt I had sufficient material for a given topic, I distilled a shorter version of the notes in the "summary area" on the left side of the slide (the Multi-Tool shows these boxes in presentation mode while hiding the draft notes). 

Below, I have included copies of my rough notes for my company's proposed Office plug-In product. At the end of the article, you will find the distilled version of the notes that I used for the stakeholder discussion.

View fullsize

1 - Value Proposition

I started the Opportunity Assessment by looking at the problem we are trying to solve - not the solution itself. Note that it can often be difficult to focus only on the pain and not talk about the way you or your customers would like to solve it. But here - and this is important - we are trying to assess the opportunity itself, so we can ultimately decide if it is worth solving.

In my case, I had spoken to enough customers and prospects to know that using a cloud-based content repository presented challenges to teams that traditionally work with desktop authoring tools like MS Word.

View fullsize

2 - Target Market

The next step in the Assessment is to clarify exactly who is struggling with the problem(s) identified in question 1. When you have answered these first two questions, you have the foundation of a solid Problem Hypothesis: we believe that [the target user] has problems with [specific task(s)].

I had been able to zero in on the Legal teams as the target users in our customers' organizations who were most struggling with accessing their cloud content from their desktop tools.

View fullsize

3 - Market Size

When you are confident that you know who has what problem, your next task is to determine just how many of these users exist out there. This will give you a sense of your potential market size and should be a good early indicator of whether you're chasing a real opportunity or not.

As you might guess, some of the information in my particular Assessment is sensitive and I have further sanitized it for this article. As compensation, I have included an image of the draft version of the slide where you can see some of the assistance the Multi-Tool provides in the form of notes and pull-out tabs.

View fullsize

4 - Business Metrics / Revenue Strategy

The next topic forces you to think about how you will measure your success if you decide to proceed with the opportunity. I have found that too often, we push forward with new product development and even bring new products to market before we get agreement on exactly how that offering will help the business! That is exactly how we got into the situation I inherited where my company's product portfolio was bloated and unmanageable.  

For this assessment, I simply created some placeholders for the ensuing conversation with my stakeholders. I wanted them to be thinking about the revenue impact on our business for sure but also how our customers, our partners, and even industry analysts would ultimately measure our extended product portfolio offering against our competitors.

View fullsize

5 - Competitive Landscape

Now we come to the competitors, or more accurately, the competitive landscape. Because the truth is, you don't always lose deals to another vendor. Sometimes, it is inaction or the prospect's failure to make a decision. Other times, the customer just decides to live with the pain or finds some acceptable workaround.

In our case, I knew what customers had been doing to get by and we had a pretty good idea of what our primary competitor was offering. All the signs would seem to be pointing us toward building our own solution that was more attractive than both the existing alternatives.

View fullsize

6 - Our Differentiator

At this point in the Assessment, it is time to look within. In short, you need to determine, as honestly as you can, why you feel that your company is uniquely positioned to address this opportunity. Put simply, this question is, essentially "why you?"

I saw the customer's problem as a content-related one, and that was certainly within our wheelhouse. Compared to the broad range of functionality we already provide both in the browser and in other desktop applications, I felt that we would be confident in delivering a compelling solution here as well.

View fullsize

7 - Market Window

If the previous question was, "why us?", then this next one could be summed up as, "why now?" Even if all the previous answers had trended more positive than negative, you can still get hung up here.

For example, perhaps the overall market of your prospective users is known to be shrinking. Or perhaps the technology you need to build the product is still immature, giving you good reason to pause. Or maybe it is as simple as postponing this opportunity until after you complete other in-flight projects.

I think my company actually does have some urgency and that if we were indeed going to head up market, then we would need functionality like this to stay competitive. Even though I was still unconvinced that the entire opportunity was worth pursuing, I couldn't deny that the timing was right for us.

View fullsize

8 - Go To Market Strategy

All the white boarding and prototyping and story writing and development and QA and deployment won't amount to a hill of beans if you don't execute on your go to market plan. Think carefully about this topic as you consider how you will get your new product in front of your customers. Do you already have the channels in place or will you be exploring some unfamiliar territory?

This is another area where I have chosen to over-sanitize the material from my own Assessment. I would apologize but I'm sure you can appreciate the sensitivity of this information.

View fullsize

9 - Solution Requirements

If you've made it this far in your Assessment, congratulations - you're in the home stretch. This is where you sit with your top technical folks and have them spell out all the dependencies and unknowns that will affect your development plans. In my experience, this is often a sobering discussion. It's not that Engineers like to rain on parades, they are just blunt and frank by nature - but you need this information to help guide your decision making.

In our case, the list of requirements was quite long, especially considering that all the stakeholders had been assuming this would be an easy win. If I needed more ammunition to build the "no-go" case, then I could count on this laundry list to aid me.

The impact

Cagan's Opportunity Assessment actually has 10 questions. The first 9 essentially prepare you for the last 1: the go/no-go decision. Many times, when using the Assessment, I can stop well before I reach the end when I can see that the target market is not big enough or when the timing is wrong, or when I don't have an obvious go to market strategy. You might think that those are frustrating outcomes but actually, I am always pleased that I arrive at that conclusion before I waste a lot of energy chasing a bad opportunity.

I have yet to share the entire Opportunity Assessment with all my stakeholders but they know it's coming. I'm looking forward to reviewing the information with them and although I'm fairly certain where we will end up, I am genuinely open to the group's collective reasoning.

I mentioned earlier that the Multi-Tool is quite handy when you need to share your Assessment results with others. To demonstrate this, I have included the final Opportunity Assessment here, in presentation mode. Click through the slides to see how the Multi-Tool can also be used to create a beautiful presentation without any additional work. Just digest the best points from each question into the boxes on the left and start the slide show - that's it! 

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

More articles from our blog PM Decisions

Sit with customers for product training

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

In yet another attempt to get out of the building and sit face to face with my customers, I decided to grab a seat in the next customer training session.

Product Managers, of any rank, need to get to know their end users. You don't get to hide behind a fancy senior-type title to avoid the difficult and often humbling experience of interacting with the people who buy and use your products.

But it can be more challenging for the Product Head Honcho to carve off blocks of time to sit with customers because the role has so many other responsibilities.

What drove this decision

In the back of my mind, I knew it had been too long since I had had any real interaction with our users. For months, I had been relying on solid, but second-hand input from my Product team to help drive roadmap decisions but I very much wanted to supplement that with my own data points.

Some weeks back I learned that the company had scheduled the next multi-day training class for customers and partners. I knew that would be a decent opportunity to step away from the office and spend some quality time with my target audience.

The decision: Spend most of the class in listen-only mode while also weaving in some interactive, product-focused discussions. 

Our customer training course is a week long affair and operates on a fairly tight schedule because of the range of functionality we cover to address a rather broad set of use cases. As such, I would not be able to carve off big blocks of time to do proper customer interviews. So rather than hijack the agenda, I looked for other windows of time for both formal and informal interactions with the attendees.

I made it my goal to bring back new product insights to my team and to learn as much as I could about both our existing and future product direction.

Plan of attack

You don't get to hide behind a fancy senior-type title to avoid the difficult and often humbling experience of interacting with the people who buy and use your products.

As I mentioned, the training agenda is tight so I would be squeezing in opportunities here and there to cover my own topics. To kick things off, I gave the standard welcome speech on the morning of the first day and wove in my parallel agenda as we covered the week's schedule.

I teased the audience by inviting them to attend a "working lunch" where I would deliver a live overview of new enhancements that were part of the major release that had just been pushed the week before.

I also proposed that we gather before class on one of the days to preview some of the exciting ideas we were brewing up in our Research Lab. This would be a unique opportunity for me to pick their collective brain and for them to help steer the products themselves.

And finally, I encouraged anyone looking for 1 on 1 time to track me down during the regular breaks to talk about any specific topics.

Emphasize the value of feedback from customers

View fullsize

Product roadmaps must balance inputs from many sources. (Click to enlarge)

In every interaction, I tried to stress how important it was for me and my team to hear from our users. I talked about the different options they could utilize for passing back their concerns, suggestions, and praise (ha!).

I was careful, however, not to set the expectation that we would act on every input. I showed a product-centric chart that I use to educate/remind both external and internal audiences of the complications of owning a product - specifically that the inputs are many and the available resources are finite. 

Spotlight product updates based on voice of the customer

To reinforce those messages, I queued up some of the new product features and enhancements we had delivered over the past few releases that were largely driven by customer feedback. I talked about how early interviews had revealed common pain points across customer implementations. And I showed how, through constant validation with end users, we had been able to advance the product to address their requirements.

Recruit end users and administrators for future R&D

Always be recruiting. That could be the slogan for our research team - and they never let me forget it. So I also put in a few plugs for our ongoing R&D initiatives. Passing out business cards is easy but somewhat impersonal so I also followed up with an email to all the participants.

The impact

I did gather some good product feedback from the group, some of it unsolicited and some of it through more formal discussions. I would recommend opportunities like this to other Product Managers looking to spend quality time with a captive audience.

The class participants seemed appreciative as well. They had positive reactions to the connections I made between customer feedback and product innovation. There also seemed to value having a direct line to the company's Head of Products, if only for a short period of time.

Look for more reports from theProductPath around customer research, customer development, and voice of the customer here on PM Decisions.

More articles from our blog PM Decisions

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

Repave the road...map

Image source: https://www.flickr.com/photos/willemvanbergen/4498186500

After inheriting a weathered product roadmap whose years of wear and tear had been the source of chronic problems for our company, I decided to fortify its very foundation.   

Like many early stage companies, we had been struggling with product direction, with making and keeping promises to customers, and with overall Engineering churn. The source of many of these problems was a Product Roadmap that frequently over committed and that failed to adhere to any consistent vision.

What drove this decision

It's fair to say that no one expects every promise to come true. And that holds for product roadmaps as well. Roadmaps are simply a plan that drives towards some future state of your product and as Eisenhower famously said, "Plans are nothing, planning is everything".

Some Product Managers get into trouble when they get too specific about future plans and end up prematurely commit to features and dates in their roadmaps. This was a perpetual problem at my company and over the years, our credibility with customers and prospects as well as with internal sales & support teams had deteriorated.

The change in leadership on the Product team presented me with an opportunity to address the problem head on but that would require some real road(map) construction work.

Image source: https://www.flickr.com/photos/seattlemunicipalarchives/3749710569

The decision: Repair the roadmap infrastructure

There are quite a few good sources on the Internet that describe proven techniques for constructing sound product roadmaps and bolstering product planning efforts. Indeed, the tactics described here are not fundamentally revolutionary. What is novel perhaps, is how, with a few straightforward changes to how we built and socialized our product roadmap, we were able to directly address and ultimately improve the Product team's credibility.

Plan of attack

We identified and committed to three changes (at least in this first phase of construction) that would yield the most value for our stakeholders. They are not mutually dependent and could be done in any order.

Use 3/6/12 months increments

We immediately dropped the former convention of spelling out exact release dates in the roadmap. Instead of prematurely committing to specific monthly releases, for example, we create a 3/6/12 month plan. Because our confidence was much higher in the short term feature enhancements, we described these in more detail on the roadmap. And we decreased the level of detail around features as we moved into the six- and 12-month phases.

This change shifted the focus away from specific dates and to the prioritization and staging of the work itself.

“We use high-level themes because it makes communication simpler and allows us to keep uncertain details vague. It also helps to limit scope creep – if a request for a new feature doesn’t align with the agreed themes then it’s easy to push back. The use of themes, combined with broad delivery windows as we move into the future, helps us to be more confident that we can deliver what’s on the roadmap.”

— Roadmap issue of the Product Management Journal, vol 9, pg 7.

Create themes for prioritizing product decisions

Roadmaps that stretch out for months or years can be complicated and unwieldy for the newcomer. It is difficult to capture all the finer points of a Roadmap in a high-level, visual chart or to communicate all the thinking that went into developing it.

To make our Roadmap easier for others outside the Product team to consume, we introduced and described a few themes. These themes helped to visually connect different units of work so that the causal observer could find order in the abundance of features.

The themes helped our audience to better understand our decision process. For instance, we could show how when a particular feature on the roadmap aligned with multiple themes it was given higher priority over other features. 

Separate commitments from candidates

There is another simple technique that roadmappers can employ to avoid making explicit promises, especially when facing increased uncertainty about the ability to deliver features far down the road.

On any/all external facing versions of your roadmap, you include a graph that has two opposite endpoints: Commitments and Candidates. The features about which you feel more confident, likely the ones you will tackle sooner, will appear on the Commitment end of the graph. The features that are further out in the future will inevitably be designated as Candidates on the graph.

While this tactic might seem obvious to you and your Product team, it will help to set the proper expectations with your stakeholders and help you stave off unproductive conversations around future roadmap commitments. 

The impact

I published the updated Product Roadmap at the beginning of the year with these three improvements: 3/6/12 month timelines, high-level themes, and a commitment/candidate graph. And, while the changes were relatively simple, the outcome was significant. Product conversations with internal and external audiences were more focused. Our team spent less time explaining or defending our decisions and more time engaging stakeholders in productive dialogue about solving important customer challenges. 

Look for more reports from theProductPath around product roadmaps, roadmap planning, 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