Document a full Year in the Life of a Product Manager

In a dauntless attempt to answer the near ubiquitous question, "What does a Product Manager do?", I decided to dedicate an entire year to recording and sharing my own journey down the product path.

I have had hundreds of conversations about the PM role, about this particular career path, and about the product development craft itself.  There is one topic that still dominates these discussions: what does it actually mean to be a Product Manager? I have collected several, almost stock responses over the years and readily share the one that best matches the other party's relative interest level.

For example, I was once asked by a colleague who had been practicing in the role for a little more than a year, "How do I even know if I'm actually doing product management?" Up to that point, I had never considered that an active PM might question whether they were really doing it right! After a bit more discussion, we agreed that an easy confidence test for an uncertain PM would be to provide affirmative answers to these 3 simple questions:

1. Are you regularly shipping your product?
2. Are your target users really using your product?
3. Are customers paying for your product?

I am not suggesting that we cracked the code here. Anyone who has been in this role will attest that it is not that simple. While we are all ultimately working toward those same goals, our methods can vary widely, even within the software/digital product space. So, where do we go to dig deeper into understanding that complexity?

Over the past few years, I have seen a real surge in the availability of authoritative resources that PMs can now access to help hone their craft. Many of these resources fall into the "How To" category, offering prescriptive approaches to addressing product-specific challenges. I set out to create something different.

What drove this decision

Even after having created software products for more than a decade, I don't believe that I can speak authoritatively on many product-related topics. But in my role as the head Product guy at this B2B software company, I have plenty of material to share with my peers and I can now confidently contribute some insights to what some have called our "often ambiguous discipline of product management".

It has been almost 20 years since I had regularly authored anything formal for an external, professional audience but I was up for a good challenge. I subscribe to the credo of pushing yourself outside of your comfort zone, to doing things that intimidate you at first. By committing to publishing 50+ articles in a single year, I was certainly going to do that. Plus, there was a good chance that I would become a gooder writer along the way.

What was most important for me, however, was creating a unique resource for other PMs who are going through the same challenges in their own jobs. I have discovered that people find great comfort in hearing that their peers have and are also struggling with the same problems that they have. Sometimes an honest report from a colleague can renew self-assurance and even inspire us to do better.

The decision: Contribute to the growing body of knowledge by sharing weekly accounts of my on-the-job experiences as the Head of Product for a late stage startup.

As far as I can tell, this is unprecedented in our field. As of this writing, I still haven't found anything comparable although some folks have published a handful of day-in-the-life pieces. Here's a few that stand out:

• A Day in the Life: Product Manager at Microsoft by Melanie Danko, published December 6, 2012 on Bloomberg site
• So, What Do You Actually Do As A Product Manager? by Catherine Shyu, published Feb 5, 2014 on Medium
• A good thread on Quora with several contributors dating back to 2010

I didn't have any year-long examples that I could follow but I was eager to plow forward anyway. I started in early January 2015 with no real audience. I had no Twitter followers, no email list, and no subscribers to this website. I started with a blank (blog) page and my atrophied writing muscles and dove right in. As I saw it at the time, there was very little risk and only upside (said the 3-time entrepreneur:-)

Plan of attack

I titled my new blog PM Decisions with the intention of using each post to document a different product decision I had made. This is the final article in the 52-week exercise but only the fourth that isn't directly tied to an actual decision I made while working at this company. At the outset, I would never have guessed that there would have been sufficient topics for me to produce a full year's worth of non-overlapping content.

I can't take much credit for the frenetic work environment that offered all these article opportunities but I do think the weekly journal format I chose was pivotal to the sustainability of the whole initiative. I wrote each article as if it were my own Captain's Log but I found that the diary approach was equally helpful as a narrative for aspiring and practicing Product Managers.

Highlight a single decision in each article

Toward the end of each week, I would find a particular activity that stood out from rest of the normal PM routine. I would qualify each potential topic by considering its relative importance to other Product Managers (my intended audience) and also how well I could decompose the elements to fit my own article template.

By focusing on one product decision at a time, I was able to go deeper into each particular topic, identifying constituents and stakeholders who were pushing for or were affected by the decision, and providing the specific steps I took in executing the decision.

I did my best to sanitize each story to avoid exposing sensitive details while still providing sufficient background information about my decision.

Create an article template for consistent storytelling

One of the best moves I made was landing on a common format for each article. I spent about 4 hours writing and publishing each article, always spread out over multiple days, but I would never have succeeded if not for this article template. It was much easier for me to flow the text, quotes, and images through each of the predefined sections in the template and in the end, I'm still convinced it is a good arrangement for documenting key decisions.

Thoroughly cover each decision

I used the following sections in the template to help me organize my thoughts:

• The article title offered a one-line summary of the actual product decision, making it easy for readers to scan over what would eventually become a large collection of content.
• The opening statement was specifically worded in the format "because of this...I decided to..." to provide context around the decision so that in article listings, the reader would have more information about whether the article would be relevant or not. I also included this statement in the article digest that was used for RSS feeds, email newsletters, and for creating smaller collections on the website.
• I followed the opening statement with a few paragraphs that tied that week's particular decision to a broader product management topic
• The next section in the template titled, What drove this decision is where I explained my motivation. This was often my favorite part to write because I was used the space to vent somewhat and occasionally, even climb up on my soapbox. I wanted to explain the reasons behind each of my decisions and justify those reasons both to the reader and also to myself. Sometimes, I approached this section as if I were prompting the reader, "would you have done things differently if you had been in my shoes?"
• After formally declaring and explaining the decision itself, I stepped through the actions I took in making the decision. I never meant to prescribe a repeatable solution and I didn't mean to suggest that my approach was the right one. I simply offered my plan of attack at the time, thinking it would be useful to the reader to see one person's approach.

The final section was called the impact, as in, the impact of my decision. Looking back over the collection of articles, I would admit that I mostly failed here. Others have also confirmed that the articles would typically start strong but would ultimately fizzle out toward the end.

Part of me would like to attribute that to the notion that you can't really measure the impact of a decision so close to making it. That it was too soon to appreciate or even understand the effect well enough to discuss it in the same week. I could just as easily blame it on running out of steam each week (did I mention this was an exhausting exercise?) Perhaps there is still an opportunity to go back to some of the articles and provide an updated postmortem.

Experiment with format, layout, and outreach

I could say that it's just my nature as a PM to tinker, to hypothesize and validate assumptions. And it is true that throughout the year, I tried some different things with my writing to see if I could improve my results. But in the end, I put most of the effort into just organizing my thoughts and capturing the words.

I mentioned that, up to this point, I had not been an active writer and even less of an online, social idea promoter. The latter made it even more challenging as I struggled with finding and attracting an audience. With some help from nearby experts, I eventually got the knack of publishing via Twitter (@theproductpath) and Linkedin but never went beyond that. Believe me when I say that I am happy with those results. Some early visibility on social channels is welcome of course but I had always set my sights on producing a collection with a longer shelf life.

I quickly learned from readers that I was good at producing tl;dr material

The lengthy article format was another strain. I quickly learned from readers that I was good at producing tl;dr material and that my weak attempts to call out specific points with quotes or bold text weren't really helping. I tried including more images and charts to break up the text but ultimately I was asking a lot from the reader.

I have recently given some thought to creating true digests for some or all of the articles and re-publishing the content in a way that would be more consumable for other Product Managers.

The impact

All in all, this has been a tremendous year. Even if my year-in-the-life series is not a first of its kind for product people, it was certainly an achievement for me. I improved as a writer, if only slightly, and now I have a unique body of work that makes for one heck of a conversation starter. In fact, I have made quite a few new product friends just from the word of mouth buzz around my efforts.

One of the unexpected, but positive outcomes of an exercise like this is that it became much easier to interview PM candidates at my company. I found that I could simply tell them, "if you want to know what its like to work here, just read this!"

So as I close out this particular series, I want to thank everyone who encouraged me. Even though I didn't quite acquire the fan base that I might have once dreamed of, I did get the support I needed. I will continue to write on product-related topics here on theProductPath and have already found the next intimidating activity to tackle.

Reach out to the local product community for growth

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

After a year's worth of lessons learned from all the good and bad product decisions I made as my company's Head of Products, I recognized that I would need even more help from the larger community of Product people in the months and years ahead.

As I learn more about what it takes to be a skillful Product Manager, I am continuously humbled by how much more there is to know. I try to expand my understanding by consuming product-related books, articles, podcasts and the like, but I have really come to appreciate in-person exchanges with peers of all experience levels.

And I am fortunate enough to live and work in a large enough metropolitan area to supply many hundreds of these peers. I had only begun to explore the human resources available in this city since moving back several years ago and I am now intent on fully tapping into this fertile (and accessible!) product population.

What drove this decision

I believe that if you actively look, you can always find opportunities for growth, both in your own personal career and with the teams with whom you work in your organization. I was actively seeking both.

I found myself craving fresh ideas and new resources. I wanted expert guidance from outside the company to grow my own skill set as Head of Product - and I would be growing my own Product Team at the same time. It was clear to me that, to improve my prospects, I should better connect with the product community.

The decision: Advance my own professional product capabilities and better address the expanding needs of my company by tapping into the rich pool of talent and experience all around me.

In my own observations over this past year, I began to realize just how large the local Product community was and how fast it seemed to be growing:

• Most of the 30+ new PMs I met seemed to have their own circle of peers with little respective overlap among them.
• My own inbox had accumulated a plethora of local, product-related new stories that would make it seem like this city was a breeding ground for "successful" product startups.
• And one of the local meet ups in which I regularly participate reported to have over 1,1,00 members (although no more than 60 or so ever showed up at a given event.)

I was determined to infiltrate this sizable community using a number of different tactics to track down the right resources to help me with my own product plans.

Plan of attack

I had already put in a lot of effort over the past year, trying to extend my network of Product Managers, both locally and long-distance. But most of those encounters had been introductory and brief. In this new campaign, I had much more specific intentions and would need to precise.

Proactively expand my personal network of product people

One of the activities I enjoy is sitting down, in person, with Product folks I've never met before. And whenever I come in contact with any smart person, I try to make a point of asking them if they know and would introduce me to good Product people.

This past week, I got introduced to a senior PM who is working right up the street from my office. We met for a quick chat over coffee and immediately hit it off, finding common ground with familiar product stories from our respective day jobs. It turns out we were both connected to some of the same people in the community, but he also acknowledged the need to proactively reach out more to our peers. Despite the overlap in our mutual professional networks, the proximity of our offices, AND the fact that I had recently attended an event in his company's space, we would likely never had otherwise met!

This meeting confirmed for me that, if I wanted a potent peer group to draw upon, I would need to drive the outreach myself and continuously build my network the old fashioned way.

Start recruiting for a new PM to join the team

For too many months now, I had been struggling to balance my strategic product work as an executive in the company with the day to day story-level work as a Scrum Product Owner for one of our Engineering teams. I needed to offload the latter so I could better concentrate on the former. In short, I needed to hire a new team member to free me up.

So, with this in mind, I went back out to the community to talk to current job hunters. In the span of a single week, I tracked down four Product Managers who were all looking for their next gig. Two were pursuing senior roles and two were focused more on entry-level positions.

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

I inquired about the state of the job market and their own personal challenges with finding good opportunities. I tried to get a better understanding of what I would be competing with compared to how other companies were hiring. I wanted to understand whether or not the recruiters were effective. I was also curious about the different interviewing techniques they had encountered.

As a result of these discussions, I was a little less optimistic about my chances of hiring my new PM. These were talented product people and for different reasons, they had all been struggling more than I would have expected. In the end, I would have to adjust my own expectations and prepare for a longer recruiting campaign.

Create my own discussion group for practicing PMs

Product-focused community events seemed to be proliferating. I had attended recently a new Product meet up nearby that was just getting off the ground. I tracked down and spoke with the group's organizers to get a better sense of what they were trying to offer to the local community. This week, I ran into another, would be event organizer who had similar plans for launching his own product-specific get-together. Ultimately, these event organizers here in town are increasing the number of opportunities for Product people to engage with their peers. I certainly appreciate those efforts but still felt like there was a gap around engaging in more personal interactions on a regular basis.

these event organizers here in town are increasing the number of opportunities for Product people to engage with their peers.

I will certainly continue to attend and support these product events, but I had been thinking about creating a very different forum. So, in this past week, after several months of planning and preparation, I successfully piloted a new, unique gathering with a small subset of local Product Managers of all experience levels where peers could comfortably share their product-specific stories.

For this initial meeting, I hand-selected a small number of PMs who I had met in my travels over the past year but who, for the most part, did not already know each other. But what they have in common are a sense of modesty (no giant egos), a passion for product development, and intrinsic curiosity - and I found that that set of traits ultimately made the group-based conversation easy, inclusive, and informative. At the end of the night, I walked away satisfied with the outcome of the pilot meeting and now am encouraged to extend the experiment next month with an even larger group of like-minded participants. 

The impact

After a year of writing about my Product experiences, I am still surprised by the sheer breadth of this role and that awareness continues to be reinforced as I speak with more Product Managers. This past week, I chose to engage with the larger community of Product people outside my company and outside my existing professional network. As I look to broaden my circle of peers, I am taking advantage of opportunities to grow my own skills and to grow my company's Product team.

Look for more reports from theProductPath around product teams, recruiting, and PM networking here on PM Decisions.

More articles from our blog PM Decisions

Convey the Product Vision to outside influencers

To do my part in helping promote the company with external stakeholders, I decided to tune up my product presentation to deliver a compelling blueprint for the future.

An early stage company often needs to do more than simply sell and support its products. For instance, there are occasions where larger and longer term plans must be discussed to advance the business through the help of customers, partners, and investors.

As the Head of Products, I often participate in these discussions, usually to tell our unique story from a product perspective. My contribution is relating all the progress made over the past weeks and months to the broader and still unfolding product narrative that will continue to propel us forward in the years ahead.

What drove this decision

With all the hyperbole about taking it to the next level, I rarely see anyone writing about what you do when you get there. There is, of course, the want to celebrate the achievement but that is short-lived and you usually don't rest there for very long. The same energy and passion and drive that got you and the team to this point is what will ultimately compel you to keep moving forward.

My company had reached another stage in its growth and it was time to turn our sights to the next plateau. New players were now starting to take an interest in the company and it would take additional time and energy investments on our part to engage with them.

It should be no surprise then, that in this situation, I would turn to the same tools and tactics I had used to help get our company this far. It was clear to me that, going forward, I would be telling and selling an even larger product vision.

The decision: Prepare and pitch a more strategic product roadmap that could accommodate a broader range of business conversations.

The product roadmap continues to be my go-to asset for constructing full and lively reports, especially with those unfamiliar with our business. I continuously tweak our roadmap, not just to reflect the evolving initiatives and priorities but also to help me tell better stories.

Every so often, I am able to produce a rendition of the roadmap that has just the right amount of fidelity. When that happens, I can communicate equally well with everyone from Engineers to Board members. This was one of those occasions where details about individual features or shorter-term enhancements would be folded into larger themes that stretch out for many months and clearly connect parallel product initiatives.

Plan of attack

Over the past year, I had been more tactical with my product plans, mostly with the intent of rebuilding credibility with the other departments in the organization. Now, I was focused on communicating our product direction to audiences outside the company.

Highlight product advancements to strategic partner

My first opportunity came in an early stage discussion with a new partner. This group was more familiar with the general domain, our specific problem space as well as our closest competitors. So there was no need for me to start all the way back at square one. They would understand how the pieces of our platform fit together, where our ongoing innovation was helping us take a leading position in the market, and how we were preparing to address weak spots in the product.

In covering the roadmap, I stepped through a number of the major past and future milestones to highlight where this partner could "plug in" and expand the value for our joint customers. This tailored view of our company's go-forward product plans ultimately helped them construct a companion roadmap for a strong joint offering. 

I found this conversation to be very productive as little time was wasted covering small details. Instead, we were able to focus on a series of touchpoints around which a mutual partnership could be developed. 

Communicate rate of progress to potential investors

anytime I find myself in front of investors, I try to emphasize the current product returns realized from past investments.

My next challenge was to use the same roadmap material to build a story that communicated how recent product advancements had directly contributed to the best year in the company's financial history.

The first part of that story was tying important customer victories to key product milestones in an attempt to prove some level of correlation. Indeed, we had prioritized some of our work over the past year to help advance large deals in the sales pipeline.

More than that perhaps, I wanted to communicate that we felt we had nailed the product-market fit and that customers were more regularly landing directly in our sweet spot.

And anytime I find myself in front of investors, I try to emphasize the current product returns realized from past investments. This audience, more than any other, responds well to proof around ROI.

Demonstrate domain expertise and solid product planning to an unacquainted party

The last test was to engage a new group that had no prior contact with our company and no exposure to our particular problem space. For this discussion, I chose to deliver an expedited product overview that highlighted achievements from the past year. My goal was to try to condense the past 12 months and past 5-10 years into a 45-minute presentation - without losing my audience.

Because I didn't know how long I would be able to hold their attention, I decided to focus on how good we had been (and would continue to be) at product planning. I wanted to show how well we understood our customers' problems and why we were confident that we hold our place as a leader in the market.

I was able to underscore this by calling attention to a few parallel development threads in the roadmap that had recently converged to deliver big payoffs for our customers.

The impact

I received positive feedback from participants in all three meetings over this week. Ultimately, I believe the outcomes were largely driven by the preparation time spent on the roadmap material itself. I have been able to get a great deal of mileage from my product roadmap by making sure that it clearly communicates product intentions, that it justifies product investments, and that it ties these investments back to actual customer needs.

Look for more reports from theProductPath around socializing roadmaps, product roadmap themes, and managing stakeholders here on PM Decisions.

More articles from our blog PM Decisions

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

Fire up the Sales team

Image source: https://www.flickr.com/photos/spacelion/3008520385

After being invited to participate in our mid-year, internal Sales team rally, I decided to deliver a rousing product presentation to get the troops pumped up.

Over the course of my career, I have spent months embedded with various Sales teams and I would recommend it for any aspiring Product Manager looking to better understand their stakeholders. Some of their customs, however, may still be a bit peculiar, at least to me. In particular, there is this practice of routinely gathering the entire Sales team for an entire day or two, typically somewhere away from the office with the intent of re-energizing everyone.

I know that the Sales team, like most other teams, have their own set of priorities and that they don't often stay as connected to the products as I would prefer. So I find it valuable to take advantage of occasions like this to better "align" myself and our products with the Sales team.

What drove this decision

We had recently hired some new folks into the Sales ranks over the past few months and the entire team had been focused on rolling out an updated sales process with our revamped Marketing team. This meant less bandwidth for absorbing the last few rounds of product updates.

Everyone in the company is invited to attend our monthly Release Previews of course but Sales attendance, in particular had been somewhat spotty for awhile.

Now, with this mostly captive audience, I had a chance to focus everyone's attention on our Products and to remind the team how much progress we have made in the last six months.

The decision: Weave together a powerful before/after story that relates the numerous product enhancements as well as our impressive rate of innovation to stir the team and inspire them to carry that message to our customers.

I can't blame our Sales reps for settling into a comfortable routine and sticking with a story that works for them. Asking them to change up their narrative every time we release new software is a little unrealistic. But I knew that the product improvements we had made over the past six months had been significant and would have a big positive impact on the way we all were engaging with our customers.

Our company had indeed devoted a great deal of time to understanding our customers' pain and I knew we could speak to that confidently. But I had sat in on enough product demos to know that there were plenty of rough spots - areas of the product that didn't show particularly well. Much of the Product effort in the first half of the year went to address these specific issues and our story needed to be refreshed to incorporate every one of those Product improvements.  

Plan of attack

They gave me 60 minutes to dazzle the troops.

They gave me 60 minutes to dazzle the troops. Even the best slides would not likely keep their collective attention for that long so I supplemented a PowerPoint presentation with live product demos and tantalizing prototypes to help keep them captivated.

The goal for me was to have everyone walk away with renewed pride in our company's product and more importantly, for each of them to feel even more confident that we were truly the best option for solving our customers' problems.

Create a backdrop for the main narrative

The first step was to set up a familiar context around which I could piece together the different elements of the story. As a framework for my slides, I decided to use a 1-page diagram I had created months earlier as a sales aid to help orient our prospects and drive productive sales discussions. I began by highlighting a number of improvements I had made in this iteration of the diagram to help me grab the team's attention at the very start.

My (abbreviated) presentation flow for the Sales team tells a before/after story using the familiar customer process as the backdrop

Show old screenshots highlighting the known bad spots

The next step was easy. I found old screenshots from the recent past and positioned them on top of the diagram. This had the intended effect of reminding everyone how hard it once was to brag about our solution. During the presentation, I intentionally exaggerated the struggles associated with this familiar but outdated description of our product - but concluded that this awesome team was still able to sell that version. The good news is that it wouldn't get any worse!

Replace with new screenshots

Then, one by one, I swapped in the new hotness. Gradually, I unfolded our updated story to the group showing how all our pain points had been (or would soon be) addressed. Even better, the Product team had introduced entirely new features that helped to strengthen our overall story. The resulting picture not only improved on the known problems but gave the Sales team even more talking points and would help them address customer issues that we might have dodged in the past.

Tease with early prototypes

But wait - there's more! Stacking up all the existing enhancements on a single slide was certainly effective but to really energize the crowd, I then switched gears and started demoing some of the new stuff that was just around the corner.

Using live code that was still working its way through QA along with fancy, clickable prototypes created by our UX team, I began to weave an even stronger narrative for our Sales team to use immediately with their prospects and customers.

The impact

My talk had the intended effect and I was certainly encouraged by all the positive feedback from the team. I do realize that the real payoff for the company will only come when they carry this updated story to the front lines. 

I remember days in recent past where Sales Engineers would brush past certain areas of the product or skip them entirely hoping that the prospect wouldn't notice. I also remember the collective cringe when a savvy customer would ask to explore the next level of detail behind a particularly well-manicured product demonstration.

With this presentation, I made it clear that we would no longer have to avoid those areas of our product. Instead, I urged our team to intentionally stop and even linger at certain points in the demo to prompt more productive conversations. I wanted our customers to ask those tough questions and engage further with us. We had even more reasons to be proud of our company's products and what's more, could now point to an impressive rate of product improvement over the past six months.

Look for more reports from theProductPath around product review, product culture, and socializing product roadmaps 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

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

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