Restore product credibility over time

In taking over as the Head of Products in an organization that had lost a great deal of its momentum, I determined that I desperately needed to rebuild trust in the product development function that is so crucial to the productivity of the teams and to the success of the business.

This particular product story would transpire over many months. The imperfect situation I inherited was not created overnight, nor would it be restored as quickly. Our company had been struggling to consistently deliver products to the market and more importantly, with achieving any real return on our ongoing product investments.

Existing customers had practically given up on expanding their use of our platform and internally, the teams had essentially resigned themselves to promoting, selling, and supporting a clunky and outdated offering.

Something had to be done to restore faith in the product itself and in the collective capabilities of the company.   

What drove this decision

It would not be fair to pin all the troubles on my predecessor or any one team in particular. I still believe that many of our difficulties have stemmed from a real lack of focus - not uncommon for early stage companies. Years of straying from one attractive market to another, chasing irresistible deals, and trying to please too many audiences at the same time had accumulated for us a great pile of problems.

Something had to be done to restore faith in the product itself and in the collective capabilities of the company. 

In somewhat desperate times like these, a company will often bring in new leadership. And in most cases, the troops respond positively and are optimistic, for a time, about the potential for improvement. In my experience, there is usually a brief window where that new person has to prove himself or herself; however, as the collective expectations about fixing what's broken are never realistic - at least in terms of timeframes, this can be a daunting challenge.

This is the environment I walked into 9 months ago. And it would take me at least that long to establish my own credibility and turn the tide for our products. I felt up for the challenge and would build on my previous accomplishments and the solid relationships I had already established throughout the company.

I was determined to make the company proud of our products again by making sure our customers were delighted to use them.

The decision: Consistently make good on authentic product promises by delivering more regularly and more reliably.

A large part of our problems stemmed from chasing product enhancements that did not come from the market but instead from individual customers or worse, from undecided prospects. This lead to all sorts of issues, not the least of which is that we ended up supporting a portfolio of misaligned or disjoint products. I had to stop that practice immediately.

We created another, even more obvious mess by committing to fully-finished features and optimizing our process around uncertain release schedules instead of establishing a delivery cadence that let us incrementally ship software more predictably. Years of bad practices had led to release dates that were constantly slipping which destroyed morale inside the company and frustrated our customers.

Authenticity is important to me as a Product Manager. Ultimately, I would have to prove to all the teams that we were addressing genuine customer pains. The (long) road back to credibility would be built by identifying real market-fit problems and doing the less-flashy work to deliver incremental solutions more consistently over time. 

Plan of attack

So how does a new Product Manager turn things around in a situation like this? How do you get folks to believe in you and be willing to follow, if not fight alongside you? I know I didn't have a quick fix - and I don't think there is one. These kinds of problems aren't created overnight and it is foolish to think that they can be rectified quickly. I will describe the path I have been on for the past 9 months with the hope that it may also help deliver positive results for others.

Learn the product - thoroughly

We have a 10-year-old software platform with hundreds of features and thousands of ways to combine them to solve problems. Unfortunately, there is no accelerated way to ramp up on the entire product suite and no shortcuts to figuring out all of the nuances that have accumulated there over the years. And even after you pick up the core functionality, there is still so much more to learn about why it works the way it does which, of course, affects your ability to go back and tinker with it.

First understand the product, then create a restoration plan. 

I was fortunate to have spent many months embedded with the Sales team, building and delivering product demonstrations to customers and partners and, combined with a natural predilection for tinkering, had become quite familiar with all of the ins and outs of our products. I could now hold my own with the Engineers which I found to be necessary when discussing the feasibility of future enhancements.

It also meant that I could understand and better empathize with all the folks who were struggling with implementations both inside and outside the company.

Build a modest plan and immediately begin delivering on it

The Product team had certainly rolled out roadmaps before I got here. Often, these plans were overly ambitious, had lacked any real cohesion, and could not be easily tied to familiar customer use cases. As the Plans' release dates inevitably slipped again and again, the company's collective confidence drained in both the roadmap and in the products themselves.

So I started somewhat fresh with a new roadmap approach. I borrowed specific roadmapping techniques that other Product people had found to be useful, but my true test would be being able to hit our new Product milestones.

In communicating the new roadmap to the troops, I emphasized that we would be backing down from the unrealistic goals that crippled the previous plans. I wasn't going to promise flashy or bodacious features (at least not anytime soon) that we all knew we could not deliver. I didn't try to dazzle folks with elaborate charts. But most importantly, I didn't explicitly ask up front for people to put their faith in me.

In fact, the early commitments on the new roadmap were the same ones we had already made, just with more realistic dates. We would finish the features already in progress IF and only if they could be tied back to legitimate customer pain points. I joined forces with the Head of Engineering who was also pushing for a more frequent and predictable release schedule and the updated roadmap clearly put us on the path to get there with smaller, more incremental product releases.

As we completed the first few milestones on the plan, I made sure to communicate our moderate and steady progress to everyone. And it was important that we celebrated these early wins as an entire company in events like the monthly Release Preview.

Make the unpopular short-term decisions that are hindering overall progress

As I have discussed before (see here, here, here, ...), there were a number of ongoing product-related problems that needed immediate attention. In some cases, I would be winding down, canceling, archiving, deprioritizing, or flat out reversing previous decisions. But in every case, I made sure I had a solid rationale for doing so and tried to stick to my convictions - any wavering would have undermined the entire effort.

Most of these decisions would be unpopular with at least one person or group in the company. To offset this, I sought to secure support from at least one camp as I went about making these tough calls. Every department had their own list of grievances when it came to the product direction. In making my weekly rounds with each of the groups, I was able to identify specific problems that were causing friction and made small improvements at each turn. Gradually, we put things back on track and were able to focus on the bigger problems as a more unified team. 

Listen to others while I follow my own instincts

It has been my experience that everyone likes for their voice to be heard. So I attempted to speak with as many people as I could throughout the company. I listened to their many suggestions about how we could improve our products. I listened to the reasons they gave for where and why things had gotten off track. And I got more than one earful about what I needed to do to turn things around.

In the end, I incorporated what I could and filed away the rest. It was going to take me many weeks and months to prove myself to the company and over that period, I would have sufficient opportunities to directly address their individual concerns.

The impact

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

It's now been almost ten months and I can see things starting to turn around at the company. We have hit record sales numbers and our customers have been steadily raving about our products. The teams are now working well together to deliver positive outcomes for our users and for our stakeholders. The Product team has linked up with key allies in Engineering, UX, QA, Operations and Customer Success to restore confidence in our offerings.

Any immediate criticism I had received for some of those unpopular decisions has now been forgotten for the most part, overshadowed by the Product team's more favorable track record. It takes time to address these kinds of problems and to reverse an existing trajectory. Our approval ratings are as high as they have ever been though it was a slow, purposeful march to get to this point.

Look for more reports from theProductPath around the PM Role, managing stakeholders, and PM credibility here on PM Decisions.

More articles from our blog PM Decisions

Guide and advise fellow Product Managers

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

After many rounds of discouraging conversations with less experienced and struggling Product Managers both inside and outside my own company, I decided to assemble and share some helpful resources for advancing one's own PM career.

I believe that we are still in the early development stages of the Software Product Manager (SPM) role and also, that there is a general lack of clarity around this particular breed of Product Manager. That would certainly explain the flood of books, articles and similar resources all aimed at helping PMs understand and navigate this career path. But along with those are an even greater number of online conversations that seem to add to the confusion by attempting to explain it.

Here are a few of the top links returned when searching for "What is a Product Manager":

• What, exactly, is a Product Manager?
• Product Manager 101: What Does A Product Manager Actually Do?
• A Product Manager's Job
• Product Managers: Who are these 'mini-CEOs' and what do they do?

For someone who has recently landed their very first Product gig or is just looking to transition into becoming a Product Manager, this visible and honest industry conversation is simply an indicator of how confusing it can be to get started. And while there are some terrific resources being developed, most new PMs don't even know where to begin. 

What drove this decision

Closer to home, I knew of three individuals at different stages in their own PM careers who were each struggling with the similar problem.

Arthur was already pursuing a UX calling and was a semester away from earning an advanced degree in that area but had spent enough time around Product people to become intrigued with the role and was now curious about whether he could do both.

Brandon had been tapped by his current company 2 years ago to take on a Product Management role after proving himself as a reliable project manager and was now convinced that he wanted to find his next Product opportunity to continue down this path.

Carl had been a Product Manager for several years but had received no formal training and while he had mastered the more tactical activities of getting customer requirements through Engineering to deliver features to customers, he didn't know where to start to improve beyond that.

I found myself in impromptu mentoring conversations with all three in the span of a single week. I took that as a good sign to revisit my own collection of PM material and pull together suitable resources for at least these three practitioners.

The decision: Create simple orientation assignments for Product Managers who have a genuine appetite for advancing their careers. 

The challenge was not finding relevant material but rather curating the collection to zero in on the items that would have the biggest impact. I was looking for artifacts that would be easy to consume, that would provide good direction in the short term, and that might inspire them to explore topics even further on their own.  

Plan of attack

These three colleagues were in different stages of their careers but I knew that all of them would benefit from some strong, foundational material. There is a growing body of informational resources for the SPM but I didn't have a place to point them to get started.

So I published my own list.

Required Reading (AND LISTENING)

Inspired: How to Create Products Customers Love by Marty Cagan

The first question I always ask Product Managers who are just getting started is whether they've found and read Marty Cagan's book, Inspired - How to Create Products Customer Love. I have received nothing but rave reviews from every person to whom I've recommended this book.

I consider it required reading -- and re-reading. It is easy to consume and is filled with great advice for PMs at all stages. But perhaps the greatest benefit for an early-stage Product Manager is that Cagan clearly outlines the role itself and distinguishes it from the related but often overlapping functions of Project Manager, Product Marketer and UX Designer.

And If you need a break from reading, I can't recommend enough the amazing podcast, This is Product Management, created and hosted by Mike Fishbein. Each episode provides a fresh and unique perspective on this incredible role. Mike recruits inspiring guests who generously share their experiences working in and around the Product function. 

Your New PM Job

Gopal Shenoy provides a Getting Started guide for PMs

I then turned our attention to what Product Managers should be thinking about in their early days on the job. Some years back, I came across this wonderful article written by Gopal Shenoy called Software product manager’s first 30 days at a new job …. In it, he lays out a great guide for what good PMs do (or should be doing) in their first few weeks. The list is extensive and a little intimidating - perfect for setting a new PM's expectations.

I encouraged Arthur and Brandon to digest Shenoy's 30-day list and create a distilled version for their own use. And if they made it through that, I further suggested that they read his companion article on what to do in the next 45-90 days.

Brandon is actively interviewing but had not yet found some of the great resources that the PM community has contributed for job hunters. I encouraged him to take a look at one particularly interesting app at http://www.thepminterview.com. The author leverages material from Cracking the PM Interview and Decode and Conquer to create an online, interactive exercise where you can practice your answers to sample interview questions.

Formal Training Programs and Peer Groups

I pointed Carl, who was already embedded on a Product team, to look into cursory workshops and/or full, multi-week courses created specifically for Product Managers. There has been an increase in the number of online or self-guided options from companies like Udemy, but I encouraged Carl to look at local options such as General Assembly's 10-week course or the Pragmatic Marketing program. I explained to him that he would enjoy the added benefit of meeting and networking with peers in his own community.

And speaking of networking, I am a big fan of getting plugged into monthly meet-ups and similar informal, after-work forums related to your career choice. Every month, more and more opportunities spring up for Product Managers to meet and share ideas. I told Arthur, Brandon, and Carl to sign up for an upcoming event in our city and even offered to accompany them.

On the Job Training

Fall in love with a product framework

I prefer to give tactical advice when I can. So I followed up on my previous recommendations (read this book, take this class, join this meet-up, etc.) with a single proposal that I would expect each of them to incorporate differently on their own product paths: fall in love with a product framework.

Over the years, the greater Product community has created and shared many formal templates, authoritative checklists, proven models and reusable processes. A few of these attempt to address the entire product lifecycle but I believe that would be exhausting for an up-and-coming PM to consume, much less apply in practice. Instead, I advocate that new Product Managers zero in on a more discrete area, by starting with what interests them the most.

I used this approach when I was first getting my bearings. I was overwhelmed by all the material and product experts I encountered and was struggling to find any method that I could confidently apply. I eventually discovered Marty Cagan's Opportunity Assessment and used this as a foundation for my building my own method.

And I wouldn't discount the searching process itself. You will inevitably stumble onto new ideas just by sifting through the still disperse product knowledge base to find frameworks that interest you.

Volunteer to do a PM's Job

And what do you do with this new framework you've recently embraced?

I was once told that the best way to get into Product Management is to start doing it. This guru urged would-be PMs to hunt down the closest Product team (or whomever is performing that function) and offer to assist. As someone running a Product team, I genuinely like that approach. But I would argue that showing up empty handed is not as attractive as arriving with expertise around some useful tool that the Product team can use to improve discovery, planning, or execution.

The impact

Ultimately, it is up to Arthur, Brandon, and Carl to move forward at their own pace. I'd like to think my advice is helping them to navigate but I feel like we're still far away from having any kind of proven curriculum. Despite that, I'm seeing more and more people gravitate to this kind of role - and I'm encouraging it. The Product community is fortunate to have professionals from so many disciplines join our ranks, making us a much stronger collective.

Look for more reports from theProductPath around Product teams, PM credibility, and the PM role here on PM Decisions.

More articles from our blog PM Decisions

Present a Product Roadmap to the Board using the 3 Horizons Model

Image source: https://www.flickr.com/photos/donkeyhotey/6143615821

In preparing to present the new Product Roadmap to the Board of Directors, I decided to employ a popular investment framework to organize our product decisions.

If your company has a Board of Directors or similar advisory group that helps guide the organization, chances are they will be curious about where the product is headed; however, more than the other stakeholders, this group is likely to view your ongoing product decisions as a series of investments. And, like any investment, yours are expected to deliver positive returns down the road.

As the head honcho for the Product team, you are responsible for crafting a rendering of the product roadmap that gives them the appropriate level of detail. There a number of ways you can organize your product investments to maximize both short term and long term opportunities but communicating that plan to “The Board” can be a challenge.

What drove this decision

In refreshing our roadmap, the Product team had established high-level themes to guide decision making but these tend to be more appropriate for filtering and prioritizing work and less useful for calling out specific product initiatives.

The 3 Horizons model was first published in The Alchemy of Growth by Merhdad Baghai, Stephen Coley, and David White in 1999 and made popular by the likes of McKinsey, Geoffrey Moore, and others.

I knew our Board members would not have the patience or the necessary product-level knowledge to absorb a thorough presentation of our detailed product roadmap, filled with epics and stories. Plus it can be difficult to get a good sense of the overall product direction when sitting that close.

For this particular audience, I needed to use broad strokes. Specifically, I wanted to explain exactly where the investments were being made and how we expect them to pay off in the next 6, 12, and 24 months.

I first ran into the 3 Horizons model in a wonderful presentation entitled 10 Roadmap Tools created by Radiant Minds (now part of Atlassian, makers of Jira). They recommended using this tool to communicate a high-level product roadmap as a set of investments that extended the current business but that also created viable options for the future.

The decision: Use the 3 Horizons Model to present the Product Roadmap to the Board of Directors and show how we would balance short and long term investment opportunities. 

I recommend exploring the Radiant Minds presentation and perhaps even reviewing the original source material for additional insights. I found this model to be convenient for speaking to our Board members - so that rather than try to impress them with impressive-sounding technical jargon, we were able to spend time talking through how we would leverage the technology to drive real, positive outcomes for the business.

The 3 Horizons model can help you organize your thoughts so that you continue to capitalize on the current customer opportunities while carving out appropriate cycles for favorable market conditions in the future.

Plan of attack

It would be impossible and also inappropriate to provide the full details of my company’s product roadmap here so I have obfuscated much of what follows. I have included a few examples that should help to illustrate the thought process I used in adopting the 3 Horizons model for our Roadmap presentation.

Horizon 1

The first horizon in the model shows how 70% of your investment should go into existing technology that you currently use and in an existing market that you currently serve. This best positions you to defend your current business and capitalize on your company's existing resources.

For our company, we used Horizon 1 to outline the scheduled work in the roadmap that would build on the technology components already present in our core platform. For example, we planned to develop a new mobile application for our customers based on feedback we had been gathering for the past few months. I explained to the Board that, because we had built front-end and back-end software like this several times before (and were quite good at it), the business risk for this new application was fairly low.

Horizon 2

In the second horizon, you describe how 20% of your product investment will utilize existing technology currently not in use in your company to address an existing market that you do not currently serve. Adopting proven technology lowers the risk for your company as you look to serve customers in the new market.

Internally, our teams had been researching an alternative to our outdated reporting infrastructure and, in the months ahead, we were planning on dedicating resources to the effort of overhauling our reporting engine. The new technology would allow us to better aggregate the information our platform collects and build helpful data-driven dashboards. As I explained to the Board, the Horizon 2 product investments would allow us to deliver an analytics offering to new and existing customers, opening up additional revenue opportunities outside of the markets we serve today.

Horizon 3

The final horizon in the model is used to highlight the remaining 10% of your investment, which is where you target new technology with the intention of entering a new market. It is admittedly harder to aim for that third Horizon - which explains the proportional size of this set of investments.

Our team has set its sights on eventually moving away from relational databases entirely and the decisions we made in this iteration of the roadmap reflect that. We are looking to the next generation of database technologies to help our software platform scale that in turn could open up much larger customer opportunities. Over the next 12-24 months, we intend to incorporate new technology into the platform to better position the company to go up market and pursue larger customer opportunities. 

The impact

You will find that there are different audiences for your Product Roadmap and each audience may have different expectations - and different level of interest. Our Board responded positively to the overall roadmap presentation and was especially engaged in the investment-oriented nature of the product decisions based on the 3 Horizons model.

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

Reset expectations around Engineering capacity

In recognizing that many of our company's developers had been committed to important engineering tasks unrelated to advancing product features, I decided to clearly illustrate our true capacity for product innovation.

The pressure on a Product Manager can be intense at times. On the one hand, you are responsible for answering the deceptively simple question, "what are we planning to do next?" All eyes are turned to you for long term product strategy and the product roadmap. And as the owner of the product roadmap, you will have no shortage of helpful suggestions streaming in, from many strong voices, constantly weighing in on what they think should be done.

Perhaps just as stressful though, is having to address the related but more nagging question, "why can't we get more done?" This was a recurring question in my company as many stakeholders were eager to see us move faster. 

“Why can’t we move faster?”
”Why can’t we get more done?”

These are fair questions from well-meaning people but it didn't take long for me to realize that there was a fundamental misunderstanding at the senior leadership level about our true capacity for product development. 

What drove this decision

If you are not directly attached in some way to the software development machinery in your company, then chances are you don't have a good appreciation for all that goes into building solid product features. The decisions that are made by Designers, Engineers, QA, and Operations are just as foreign to other groups as the inner workings of Sales, Marketing, and Finance are to us software types. In our company, though, there was growing frustration with the lack of progress being made on the product side.

The software team I joined had indeed struggled, missing targets, dropping features right before a big release, and generally falling victim to interruptions and emergencies. We have a strong Engineering team but a good number of them were being assigned to tasks that, while important to the company, were not contributing to product innovation.

In my new role as PM, I had a plan to begin a new chapter for product development at our company. Success would depend on building credibility early with stakeholders and a big part of that meant resetting some expectations. Specifically, I would need to explain why I would not be able to achieve as much as they had been expecting. I would have to justify why we weren’t able to accomplish more.

Image source: https://www.flickr.com/photos/jurvetson/2292656889

The decision: Publish a straightforward model that would clarify our actual capacity.

Through a number of internal meetings, I learned that members of our talented engineering team had been assigned to work on internal projects such as scaling our core software platform and optimizing our development process. Other team members were allocated to team management or committed to rotating assignments with Customer Support.

The net impact was that the size of our Engineering team had been reduced. The remaining developers were available to work with my Product team on new features but would also have to address bugs that cropped up. Then there were research tasks that did not directly yield new software but would certainly benefit future development. And finally, we had to plan around holidays, vacation days, sick days, and any scheduled technical training.

All in all, there are far fewer available cycles in a Release than one might think.

To clarify our true output capacity to our senior management team, I built a simple scoreboard of sorts for each release that showed how many FTEs were available for product development.

Plan of attack

Normally, I'd relish an opportunity to build some elaborate model but in this case there was no need for fancy diagrams. Instead, I created a simple picture using PowerPoint, similar to the image at the top of this post.

I started by using squares to represent each engineering resource making it easy to visually determine the total number of Engineers on staff. Then, using different colors for each bucket, I identified how many engineers were being assigned to non-product initiatives and labeled each initiative appropriately. I chose to omit specific names in the diagram, even when it was obvious (e.g. team leads).

The result? A clear model that illustrated our company's actual product development capacity.  

The impact

You could disparage this approach and claim that I had prematurely adopted a defensive posture or taken a pre-emptive CYA step. But our senior leadership team was overdue for a reset. In the weeks that followed, in conversation after conversation I used the diagram to remind everyone exactly why we could NOT move faster.

This led to more productive discussions about resource allocation, hiring decisions, and generally rearranging priorities. And to me, those are the right kind of questions to debate.

Look for more reports from theProductPath around capacity planning, communicating with charts, and working with stakeholders here on PM Decisions.

More articles from our blog PM Decisions

Campaign for early Product Roadmap support

Image source: https://www.flickr.com/photos/amycgx/3119640267

To increase the chances that the new Product Roadmap (and my first here) would win favor throughout the company, I decided to conduct a campaign to build early support for the Roadmap itself.

As the new guy now leading the Product team, I had my hands full getting up to speed in the first few weeks. My immediate concern was keeping the current Release on track but the greater challenge was creating a new Product Roadmap for the upcoming year and rapidly drumming up support within the company.

What drove this decision

Taking over a Product team at the beginning of a calendar year has some additional pressures as you might expect. Many internal and external parties are looking for clear indications of the overall product direction, the most concrete of which is the Product Roadmap.

Our company likes to kick off the new year with a rousing, all-hands pep rally for the entire company and one of the meeting's big agenda topics is the presentation of the refreshed Product Roadmap. A big reveal from me that early on would be risky as I hadn't built up sufficient credibility by that point. And with just a few weeks into this PM role, I really hadn’t hadn't been able to speak with as many departments as I had hoped. To pull this off, I needed to build a groundswell of support by having the various department weigh in on, or at least preview the Roadmap before I tried to broadcast it to the masses.

Image source: https://www.flickr.com/photos/israel-mfa/14616944000

The decision: Build support for the new Product Roadmap in stages

My ultimate goal was to present my new Product Roadmap to a room full of supporters. To improve my chances, I started a somewhat calculated crusade to win friends and influence people all around the company.

Plan of attack

There is no one, obvious way to plan a campaign like this but the strategy I recommend is to start small and with people whose opinions you value and push them to poke holes in your product strategy before moving to the next group. I have outlined the approach I took which proved successful.

Start with just the Product team

I began the exercise with my own Product team, perhaps the most empathetic of the groups I would encounter. These folks were the most patient and, because their future paths were most closely linked to the Roadmap, the most eager to engage. With this group's help, I was able to get my initial story straight, confirm the overall themes, and plug some minor gaps in the strategy.

run the roadmap past the Sales Engineers

The next audience I sought, though discretely, was with the Sales Engineers. I had worked closely with this team in the past and knew they would be supportive. I trust their general feedback but it was also important for me to vet out some of the key product decisions with someone who interacted more frequently and directly with our prospects and customers.

pitch to the Key Stakeholders

With my confidence growing, I moved on, skipping over the individual departments to gather all the stakeholders in a room. As you might expect, this group of department heads, their bosses and our senior leadership team is composed of a great number of strong personalities. But when invited to sit alongside their peers, even the feistiest individuals will often tamp down their protests, yielding to and general supporting the views of the larger group. I found this to be the case with my Roadmap presentation and used the inferred approval from the group to launch into the home stretch.

present to Individual Departments

With support from the top, I proceeded to set up separate meetings with each major department including Engineering, Operations, QA, and Customer Support. In each meeting, I tried to highlight those parts of the Roadmap that I thought would appeal most to each group. This proved valuable later, in the larger setting when I was able to direct different topics to specific members of the audience, with the effect of making it seem as though they had already endorsed the individual ideas.

Announce to the Entire company

The final stop in the campaign of dreams was pitching the Roadmap to the entire company. At that point of course, through all my previous efforts, I had eliminated the element of surprise. I had effectively planted sympathetic individuals in the crowd who consciously or not, were giving me the nods of support I needed.

And, while there was no thunderous applause at the end of my presentation, I did get relatively high marks for a "new guy". In fact, a number of people approached me afterwards with positive feedback and great suggestions about how to further socialize the Roadmap internally. For example, we decided to start using the many monitors hung on the walls throughout our office to track our Roadmap progress over the coming weeks & months. 

The impact

When I look back, it is obvious to me that this kind of approach to build internal support takes more cycles than one big reveal. Meeting with each team, one at a time and reviewing the Roadmap over and over was certainly more work in the short term but has paid off. I still have to demonstrate that we can achieve what was promised but I should not be spending as many cycles defending the Roadmap itself.

Look for more reports from theProductPath around product roadmaps, promoting product ideas and working with 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