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.

Practice humility in product pursuits

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

In recognizing that the string of recent product successes had (perhaps!) inflated my ego and that that might likely affect my judgment, I decided to devote some time to more sobering aspects of being a Product Manager.

It is easy to get swept up in your team's triumphs, to celebrate (even minor) victories, and to take excessive pleasure in the praise others shower on you when times are good. I am as guilty as anyone of basking in the glow of success. Hitting your goals is satisfying indeed and it is tempting to linger there awhile in that satisfaction.

But it can affect your judgment if you get too caught up in your own hype. I was starting to feel like that was happening to me and I wanted to course correct before I began making poor product decisions. Surely there were some facets of my job or details of the product that were not going so well. I wanted to make sure I wasn't ignoring or just glossing over them. One careless misstep could effectively evaporate all the admiration.

What drove this decision

Credibility is crucial in this role. Product Managers must find a way make forward progress with little to no authority and to do that effectively, we must establish ourselves as capable decision makers. The challenge, of course, is that it takes much longer to build credibility than it does to lose it.

I have found that it is often a long march to establish good standing for yourself in the organization. But you can't get there - or hope to stay there long - if you misrepresent yourself by glossing over the many mistakes you make along the way. You have to acknowledge failures to your stakeholders, to your teams and to yourself.

I did not want to lose any of the forward progress I had made and that meant coming down out of the clouds and remind myself that I was still fallible.

The decision: Balance out all the congratulatory feedback and even my own eternal optimism by purposefully exploring activities that would knock me down a notch.

It seemed to me that a good way to knock myself down from the pedestal would be to engage in the kind of activities where there was no actual way to win. I would, therefore, seek out situations that would test my confidence but where the outcomes were not likely to be favorable for me.

Plan of attack

I found good opportunities to help me reset my ego. During this particular week, I tried out some new ideas that would serve up some humility. I think part of what made these exercises effective for me was that they were somewhat disconnected from my role in the organization. I did intentionally seek out product-related activities, but I would not be taking advantage of my job title to affect the respective outcomes.

Taking a turn at being the interviewee

I volunteered to help a colleague who was running a set of user tests for a mobile application. Specifically, he wanted to interview me as a target user of the app. His product initiative was unrelated to my company which meant less personal risk for me. In fact, I convinced myself that, should there be any missteps, my blunders would only be exposed to one other person.

And boy did I have some blunders! Well, technically, it is hard to say that you can get anything wrong in a usability test. As my colleague reminded me, "we are testing the app, not you." I have used that exact phrase in trying to set proper expectations when leading my own experiments, but it is hard to shake the feeling that, as an interviewee, you're not performing adequately.

At one point in the exercise, I thought I had successfully completed the task although it took me longer than I thought it should have. Must be the app I thought. Then, when I was politely informed that I actually had NOT accomplished the task, I was truly embarrassed.

when I was politely informed that I actually had NOT accomplished the task, I was truly embarrassed.

Being on the other side of the table helped me better understand the anxiety that comes with being interviewed. In the long run, this experience will undoubtedly make me a better interviewer, but I will admit that it had the sobering effect that I was looking for.

Reeling from a wave of negative customer feedback

In this same week, I had started to receive some strong reactions from our customers about a recent feature overhaul and none of it was positive. I can't think of anything much more humbling to a Product Manager than hearing that you may have got it wrong: "Can we just go back to the way it was before?"

The feedback was being collected by and funneled through our internal Customer Success team and we took it very seriously. Of course, my instinct, shared by the entire Product team, was to talk directly to the customer. We had, in fact, been doing that throughout the entire product cycle and had already incorporated earlier feedback into the feature through incremental releases.

"Can we just go back to the way it was before?"

Immediately, we went back to review our notes from these previous conversations which included several sessions with one of the customers who was now griping the loudest. I will admit that it is difficult to keep a cool head when intense emotions are involved.

I found this to be the perfect opportunity to revisit my convictions as a Product Manager, to reflect on how much better I still needed to be, and to remind myself how this particular job really never gets easier.

Proceed over a panel in a roomful of peers

And just to pile on even more, I also volunteered to participate as a moderator in a panel discussion for a group of Product Managers from the local community. I had never been a panel moderator and had never worked with this organization or its members. 

Eleanor Roosevelt is credited with saying "Do one thing every day that scares you." Well if you are short on ideas, let me suggest trying your hand at moderating a panel of experts, most of whom are far more experienced than you, and guiding the conversation for a roomful of practitioners in your field.

The impact

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

I certainly felt the impact from each of the activities. Any one of them might have been sufficient but combining them all in a single week certainly helped me achieve my goal. And even if you're not working toward the exact same objectives, I can still recommend following some of these pursuits:

• Literally put yourself in your buyer's/user's shoes to help you better develop empathy
• Prepare yourself and your teams for confronting product mistakes so you will know how to move forward
• Do something that scares you, especially around your peers

Look for more reports from theProductPath around product culture, credibility, and the PM role 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

Take time off to recharge

After an exhausting week filled with a product release, an out of town trade show, and more than a dozen meetings with customers, partners and analysts, I decided to disappear into the woods for awhile.

I don't take enough vacation time, probably less than half of what I'm allotted. I love what I do for a living but I also get stressed out every now and then and have had to get better at recognizing my own specific symptoms. It wouldn't take a trained professional to see that this particular week was going to be exhausting for me so I made sure to pad my travel plans with a few extra days of downtime.

What drove this decision

Right on the heels of another major (and successful!) product release, I hopped on a plane to spend a week on the West Coast as part of a larger team our company was sending to a significant industry expo. At the show, I gave a formal talk to announce a new product we had spent months building and validating with customers. The presentation went well and our new product was a hit with the attendees.

With all the right people gathered in one central place, we had also scheduled back-to-back meetings with customers and prospects, partners and integrators, as well as analysts and influencers. I was running almost non-stop from room to room trying to keep up. I do enjoy all the activity, even at the heightened pace but it is not sustainable and by the end of the week, I ran out of steam.

The decision: Leave the office, the job, and all the people behind and soak up some solace in solitude.

My particular form of relaxation is to head off into the woods, by myself on a very long hike. I realize this isn't for everyone - in fact, I haven't found too many people who share my preferences for spending hours or days embedded in nature.

But it really doesn't matter how you unwind and recharge. The trick is to find a way to unplug from the day to day schedule and fill the gaps with a different agenda - one that revitalizes you, stimulates your creativity, and boosts your spirit.

Plan of attack

One of the things I like most about hiking and camping is that is practically forces you off the grid. I always bring a cell phone but I find that I don't mind so much when the battery dies at the end of the 2nd day. If you're used to being connected 100 per cent of the time, then it will likely take longer for you to appreciate that your brain can find other things with which to occupy itself. It is often during these stretches that I get real inspiration.

Backpacking can be especially liberating. When you have to carry on your back everything you would need in order to sleep, cook, eat, drink, clean, clothe, bathe, entertain, and protect yourself for days at a time, you inevitably learn to value the art of keeping it simple. I try to recall that mindset whenever I'm staring down a large problem at work.

MVP = Minimally Visited Path

I am intentionally seeking solitude on trips like this. I want to be far enough away from human contact that I don't even have to bother with casual pleasantries. To achieve this, I have to retreat far from the parking lots, down the more primitive trails, and often near the edges of my own comfort zone. There is nothing that helps me turn my thoughts away from my typical daily routine than navigating unfamiliar back country paths on my own.

I'm no Daniel Boone but I do appreciate a spot deep in the woods where only the faint sound of an occasional overhead airplane interrupts the long stretches of silence. I can sit in a hammock for hours, staring up at the trees, resting my muscles and my brain.

Refer to the map often

I rely on a roadmap to guide my day to day activities as Product Manager. My team and I use the map to guide our activities and to communicate direction with our customers and stakeholders. It is not uncommon for me to carry around a portable version of the product roadmap for important or even impromptu discussions around the office.

When I'm away from all that, say hiking through unknown territory, I find that a good map offers the same comfort. I do occasionally take a wrong turn but I generally try to keep my bearings and have learned not to panic if things don't necessarily go according to plan.

In both cases, the map provides me with support and allows me to be more relaxed in my decision making. 

Log miles, not bugs

On a long, multi-day hike, about the only metric I pay attention to are the miles I've already walked and how much more I have to go. I just completed a 28-mile loop through a giant redwoods park in California and I can tell you the last thing on my mind was a list of software-related bugs. Your rhythm quickly adapts out there. You wake at sunrise and go to sleep when the sun goes down. Away from the short-term urgencies of features and enhancements, requirements and usability, bugs and regression testing, your mind can turn back to the larger product challenges, the real customer needs, and the decisions that will make your business successful.

For me, a really long walk is often the perfect opportunity to re-focus my thoughts. 

The impact

While I can't say that I am fully recharged, I did thoroughly enjoy the time away. Aside from receding into a truly awesome natural setting, I was also quite humbled having spent several days alone with gigantic trees that are more than 1,000 years old. I now return to the office surroundings and the familiar duties of my role. I have some new memories to keep me stimulated while I adjust back into business mode. It's time to plug in my phone, catch up on email and start working through all these new ideas. 

Look for more reports from theProductPath here on PM Decisions.

More articles from our blog PM Decisions

Speak on products in a public forum

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

As part of an effort to continuously hone my communication skills - an ability that is vital for all aspiring and incumbent Product Managers, I decided to seek out opportunities to deliver product messages to the outside world.

It took me many years to realize that a day full of nothing but constructive discussions across the various business units could indeed be considered a productive day.

It's not like I don't get the chance to talk about products or product development every day - on good days, that's all I do. To be an effective PM, you must develop methods of interacting with a diverse set of internal and external "customers" and to really succeed, you simply MUST be a solid communicator. This job is all about communication, with almost every part of the business (sorry Legal teams). We Product people are full-time arbitrators, back room mediators, and business-to-tech translators.

In fact, it took me many years to realize that a day full of nothing but constructive discussions across the various business units could indeed be considered a productive day.  

What drove this decision

I can't remember seeing a resume that didn't highlight "excellent communication skills". I would like to think I'm competent in expressing myself through company emails, in formal presentations to internal stakeholders, in one on one interactions with customers and even with online mediums like this year-in-the-life PM blog.

But the one area that I have a hard time leveling up on is public speaking. I love what I do and it always seems easier to talk about something you're passionate about so I set about finding opportunities to practice in front of a live audience.

The decision: Sign up for several public speaking engagements to resume exercising those stagnating muscles.

I've already stressed the importance of communication but I want to be clear that I don't consider public speaking to be mandatory for this role. However, I will propose that if you're delivering a certain type of presentation in a certain setting, that you will use the same physical and mental muscle groups. Having to convince groups of people that you understand their problems while proposing fresh and unique answers to those problems would be familiar territory and I wanted to find those experiences in a more formal (and formidable) environment.

Plan of attack

As it turned out, I didn't have to look very hard. Not only are there are readily available opportunities as part of the normal course of product development, but you're not likely to find many people competing hard to take on those assignments. In a relatively short period of time, I was able to schedule three very different speaking slots on my PM calendar.

Deliver product release webinar to customers

As a kind of "warmup exercise", I volunteered to deliver the public webinar for our next product release where I could extoll the virtues of the latest round of improvements to our products to a broad audience of customers, prospects, partners, and more. Using a virtual, web-based delivery format meant that I wouldn't be face-to-face with my audience but it was still a public forum where I would need to be poised, polished, and professional.

I was fortunate in this case to have an existing presentation template to use and of course I was intimately familiar with the material since my team had just spent the last few weeks working through the backlog. The content and accompanying script was new of course and I also wove in a few live product demos to increase the degree of difficulty.

With some rehearsals and an early dry run recording to be shared after the official webinar, I was ready to go. All the preparation paid off and the live event was a success. I had fewer jitters than if I had actually been on stage but I certainly experienced a bit of the same anxiety. 

Announce new product at industry event

The next venue was much more daunting. At a major trade show, I signed up to deliver a formal presentation where I would announce a new product for the company. The talk was promoted by our Marketing team and would likely attract a range of participants from the amiable (e.g. happy customers, supportive co-workers, and curious passers-by) to the slightly more surlier (competitors, disgruntled former employees, and grumpy show floor stalkers looking for free swag).

I would be condensing more than a year's worth of product discovery and delivery into a 20 minute presentation which would be hard enough.

For this talk, there was no template. I knew I would be condensing more than a year's worth of product discovery and delivery into a 20-minute presentation which would be hard enough. But it also had to be much more engaging as I would be competing with all the distractions of the surrounding event.

I sketched out the general flow of the talk, liberally borrowing techniques and best practices from everywhere could. Immediately afterword, I literally grabbed a few of our internal creative types (thanks creative types!) to help me create a beautiful presentation to support my narrative.

We ultimately landed on a simple, but effective style that needed fewer words on the screen and incorporated a bit of audience participation. The noisy venue wasn't necessarily ideal and truthfully the product practically sells itself (thanks Product!) but I'll take a small bit of the credit for what was a captivating, if not compelling presentation.

Lecture about product management to college class

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

My final challenge was to be the most trepidatious. Many of us can identify with the general anxiety of public speaking but when you combine that with that recurring nightmare we all have about finding ourselves back in school completely unprepared for some assignment, you can appreciate my plight.

I had done a similar session as a guest lecture at this same university earlier in the year and was now being invited back to speak to a new class both on the broader topic of Product Management as well as its strong connection to UX. In this instance, I would be able to step away from my day-to-day work with my own company's products and talk about product-related topics about which I am more passionate.

The impact

I'm not exactly sure how to measure the impact of these speaking opportunities but I'll confess that is better to have them behind me. I am satisfied with having pushed myself outside my normal comfort zone and will likely do so again. Most Product Managers I know already have enough stress in their daily routine and would not willingly introduce more. One small tip I can share from this exercise is that compared to public speaking, facing down a rude customer or talking a hot-headed CEO off the ledge or feuding with a belligerent Engineer all seem like walks in the park!

Look for more reports from theProductPath here on PM Decisions.

Showcase roadmap to advance a large deal

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

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

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

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

What drove this decision

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

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

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

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

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

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

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

Plan of attack

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

Demonstrate A working version of an early prototype 

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

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

Preview unreleased features

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

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

Share detailed roadmap of prospect's most requested feature

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

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

Unveil results of relevant internal research efforts

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

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

The impact

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

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

More articles from our blog PM Decisions

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

Write the Release Notes

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

After realizing my goto resource would be on vacation during the next big deployment, I decided to step in and take the lead on producing the key product documentation.

Our company publishes Release Notes for every major product upgrade. We create this formal documentation for existing customers mostly, as we look to highlight improvements and bug fixes to our software products and any changes in how we deploy, license, or support those products.

I have regularly contributed to this document but have never owned the task of generating and assembling the Release Notes for our product deployments. With each major product release, I have also looked for opportunities to incrementally improve the structure and details of this important piece of product collateral.  

What drove this decision

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

One of my Product Managers had scheduled some time off of work for a much-needed (but poorly timed:-) family vacation. Up until this time, the Product Team had leaned on him to lead the effort of producing the Release Notes. And he had always come through.

Each time of course, it had been a team effort as each Product Manager was ultimately responsible for capturing and communicating their team's respective work. But "Vacation Guy" had been the one to pull it all together and ultimately deliver it to the eager masses.

His absence would put us in a tough spot - but it also presented a good opportunity for me to pitch in.

The decision: Roll up my sleeves, dust off the technical writing skills and crank out the next iteration of our product release notes.

I was confident about writing the document itself and fully aware of the entire scope of the upcoming release. But beyond the heads-down task of cranking out the words and pictures, I wanted to use this occasion to advance the state of the product communication we use with our stakeholders.

Our new Product Marketing Manager has been pushing my product team to better connect the dots around product/feature positioning.

On a related note, the company had recently hired our first, full-time Product Marketing Manager (a great move) who among other things, is helping us with the many tasks associated with a product release. For example, she has taken over the Release Communication Plan that is used to orchestrate most of the customer-facing tasks like email notifications, blog posts and related content marketing activities, and promoting the post-release webinars. And much of what she requires for this Plan is derived from the initial draft of our Release Notes.

Among the many improvements she has ushered in has been pushing my product team to better connect the dots around product/feature positioning. For example, the work we do to create testable hypotheses further upstream in the product discovery and early development process were all but lost by the time we delivered the working solution. But that is valuable information that needs to be communicated to customers and end users.

Plan of attack

We generally organizes topics in our Release Notes like this:

TABLE OF CONTENTS

About the Release Notes

Release Overview

End of Life Announcements

Enhancements

• Major enhancement
  • Customer facing notes
  • Content-marketing fodder
  • Internal-only messaging
• Major enhancement
• ...
• Other enhancements
• Fixes

Known Issues

Getting started was not quite as easy as "Save as, Search-and-Replace" but we had developed a reusable structure for the document that made it easier to produce each new iteration. 

Internal first, then external version

I began by creating an internal-only version that contains more information than what was necessary for customers. This initial version provides a diversity of details around each topic and was meant to give our Professional Services and Support teams a better understanding of the impacts, if any for customers.

For example, on the extreme end, I might thoroughly describe the migration steps for users that are transitioning from a deprecated feature to a new enhancement. On the other extreme, I may simply reference existing collateral such as public-facing knowledge articles that are affected by the release and would need to be updated.

I delivered a draft of the Release Notes to the Product Marketing Manager early on so she could start to build the Release Communication Plan. I also circulated it to the rest of the teams to get all the wheels turning for the upcoming release.

More than just an enhancement list

The bulk of the content in the document relates to the product enhancements. Customers (and Sales teams) tend to focus on the shiny new things. I try to accommodate by separating and highlighting the big stories from the much longer list of smaller enhancements.

For each major feature, I started by revisiting the existing customer pain that prompted the product work. Sometimes I even included relevant feedback we received before and during the development cycle.

In describing the solution, I outlined the way the feature is used and included screenshots where helpful. I try to provide at least 1 example to further help orient the user.

With all this information repeated for each big enhancement, the document can often get quite lengthy. To counter reader fatigue, I reuse a consistent layout throughout this part of the document and break up the text with subsections, internal links and generous whitespace to make it easier to consume.   

Updates to primary customer narrative

Along with the general description of the major and minor features included in the release, I also posted refinements around our main use case to help the Content Marketing Team rework their editorial calendar to fold in new blog posts, videos, and other collateral related to the release.

The internal notes and supplemental use case-related material is helpful for connecting the dots between customer needs and shippable products but is ultimately stripped from the final, external-facing version of the document. 

The impact

By most measures, my turn in the driver's seat did not negatively impact our process. I was happy to have made a few, incremental enhancements and as with most product efforts, will be looking for feedback and validation from all stakeholders in the days that follow.  

We will go through several internal iterations of authoring and review the Release Notes before we finally publish it externally to customers, concurrently with the release going live. Often, we will work to refine the Release Notes up until a day or two before the release as last minute details are being ironed out. The finished version is deployed on the company website with any number of links from within the product, from support documentation, from the marketing site, and from outbound promotional emails.

Customers have responded positively to the level of information we provide in our Release Notes. I suspect we will eventually move away from the traditional PDF document to a more fluid web/mobile publishing solution. Additionally, we are starting to favor short videos to introduce each major enhancement but they take longer to create and are more difficult to update if/when the screens/pages change.

Look for more reports from theProductPath around product releases, the PM role, and product culture here on PM Decisions.

More articles from our blog PM Decisions

Deliver a more compelling product status update to the troops

Image source: http://tinyurl.com/p3cc4o6 (Flickr)

In recognizing that our periodic meetings to share our development progress were falling flat, I decided to revamp the company-wide Product Preview event.

For many years, our company had maintained a recurring "preview" meeting where all employees were invited to catch a glimpse of the most recent product developments. At each meeting, a rotating group of Engineers would take turns showing off their team's work, which frequently included partially finished features that often led to unproductive Q&A with the assembled audience.

I believe the original motivation for having these meetings was well intentioned. It can be difficult for other parts of the organization to appreciate the black box that is Engineering. By revealing to the larger group the fruits of all that labor in a product demonstration setting, all interested and affected parties have a better opportunity to stay in sync.

But in our organization, these regular updates from the tech side of the house were not working. It was difficult for non-Engineers to relate to the material. We needed more structure, more context, and a bit more sizzle than you might expect from those who spend the majority of their time with variables, algorithms, and debuggers.

What drove this decision

Image source: http://tinyurl.com/qyhp33b (Flickr)

Engineers seem to communicate best when they're speaking with other engineers. I don't think I'm inviting controversy by stating that Engineers are not the best orators. Public speaking is not necessarily a skill that helps them with career advancement, and perhaps part of what makes this particular field more attractive to them. Either way, a company-wide meeting with an exclusive Engineering agenda is going to have its challenges.

Engineers also tend to have a myopic view of their work. Even when you find a vibrant communicator, they will still struggle to connect their important contributions to the larger picture. To be sure, getting that new feature to work is a great accomplishment (especially when you factor in the additional challenges of having to upgrade to the latest, post-beta, open sourced, cross-platform, fault tolerant, minimal footprint, backward-compatible, mobile-optimized, ...)

But in a larger group setting like this that draws a cross-functional audience, there is an even greater need to tie the product-level work back to the higher-level company goals. I needed to find a way to continue to report on the great progress we were making but in a way that better catered to the entire company. 

The decision: Substitute the Engineering-led, tech-heavy, feature-level demos with a Product-led, value-driven, full on show-and-tell lineup

Image source: http://tinyurl.com/ntevbtd (Flickr)

To clarify, I still want the Engineers to join in. And the meetings would still center on product demonstrations - that is still the best way to share with the company the progress we're making on our products. What I wanted was to tell that broader story, where product innovation is ultimately tied to business value (ours and our customers'). More than anything, I was intent on having the entire organization understand our motivation, what drove our priorities and how we were validating our hypotheses.

Our organization happens to be following an Agile software methodology, but I want to be clear that the show-and-tell meeting I'm describing here should not be confused with the Scrum Sprint Review. There is great value in having Product and Engineering conduct a meeting to share progress, review what was and was not accomplished in the most recent sprint, troubleshoot issues, and critique each team's work (see here for more information on Scrum's sprint preview). In fact, it would not be uncommon to also invite the same audience to the Sprint Reviews.

Plan of attack

After a quick poll of the other department heads, I confirmed the approach and verified that I would not be disrupting any dependencies they had that would have stemmed from the original meeting. And, as soon as I felt confident that the Product team was prepared and ready to take the lead, I cancelled the old recurring meeting, then created a new meeting invitation with a revamped agenda based on these goals.

Review Customer Success from Past Releases

I am intimately familiar with large product efforts that were, at one time, deemed high-priority or "must-haves". But I've also observed that, too often the very next big feature quickly distracts us so that we lose track of what happened with the last one.

I wanted to start each meeting with a brief update about the last release, and specifically what we could report from our customer base. We had been improving the tools we use to help us better measure customer uptake. The Product team would continue to refine these reports to help communicate the return on our past product investments. 

Did we hit the mark on the last release?

• Who was using the new features?
• Who wasn't?
• Were the bug fixes received well? 
• Is the product more stable, less glitchy, and scaling well?
• What else did we learn?

DEMO NEW PRODUCT DEVELOPMENTS AHEAD OF the UPCOMING RELEASE

Image source: http://tinyurl.com/nkk7cpb (Flickr)

For most attendees, the draw of these meetings was still the shiny new features and we certainly wanted to use the opportunity to spotlight all the great work accomplished since the last release/meeting. But the switch to having the Product team members present the updates meant that they were more likely to hear how individual enhancements fit into the larger end user stories, how the updates might affect the configuration and pricing of the products - even how we might alter our product positioning in the market.

We also want to illustrate how the latest changes were building on previous rounds of investment rather than just demoing individual features in apparent isolation.

The Product team is always collecting feedback to validate our efforts but this would not have been the first time the other departments would have seen these product updates. At these Product Release Preview meetings, our intent is to show off features that are complete and already scheduled in the very next product release.

REVIEW THE CURRENT PRODUCT ROADMAP

The Product team has been putting more energy into the roadmap planning process itself and worrying less about adhering to any particular iteration of the roadmap. These meetings proved to be an ideal opportunity to update the company on any significant changes we had made to the roadmap since the last gathering. I intentionally scheduled this topic toward the end of the meeting to time box help keep the interactive conversation focused and productive. 

At this time, the Product team has not committed to publishing a refreshed Product Roadmap at each meeting.

RECRUIT CUSTOMERS FOR PRODUCT RESEARCH

We close each meeting with our continued plea to get everyone's help in recruiting customers (and prospects) for our ongoing product research initiatives. We have found that our calls for help tend to yield more fruit in the larger group setting, especially after delivering a rousing product demonstration. 

The impact

Part of the motivation for these changes was to stir up some excitement around all the great product work that goes on behind the scenes. Celebrating your accomplishments and sharing them with the entire organization is healthy for any team and can really boost company morale. And we certainly achieved that with the new format.

With the changes I made to the agenda for this "preview" meeting, I also helped distinguish these Product show-and-tells from the Engineering (Scrum) sprint reviews. And based on the informal feedback I received, our Engineers were actually relieved that they would not have to present to the group and that they would be excused from even attending the meetings - although many of them still show up and participate!

I consider this particular decision a great success and will share more about the impacts in future posts. 

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

More articles from our blog PM Decisions

Network with other Product Managers

Image source: http://www.freeimages.com/photo/509114

Prompted by my search to find a new PM team member, I decided to reconnect with my local peers to converse on products, recruiting and more.

I had been so heads down for the past few months, getting up to speed as the new Product Head Honcho, that I had put any and all contact with external Product Managers way down on the priority list. Where would I fit that into the schedule? It had been challenging enough for me to carve out extra time to meet with our existing customers - and I knew I certainly couldn't defer that activity.

The invites to catch up over lunch and coffee had begun to pile up as I made excuse after excuse for why it was never a convenient time for me. But the truth is, I had been increasingly isolating myself from my peers. And these were colleagues who could help me validate some of my recent Product Decisions and provide significant insight into many of my current challenges.  

What drove this decision

In a previous Product Decision, I had chosen to replace one the PMs on my team, which immediately shifted me into recruiting mode (typically an exhausting exercise). In an effort to minimize recruiting fees, I began my search by reaching out to my own network of Product Managers. This provided me with a great opportunity to reconnect with old friends, and through them, new contacts. 

The decision: Use my pressing PM search as a motive for networking with other Product Managers

Image source: http://www.freeimages.com/photo/644967

I have found that most people like to feel helpful and are often flattered when asked for their opinions or for assistance with a particular problem. And, if talking shop over coffee isn't incentive enough, many professionals will gladly take time out of their schedule to help out a colleague, especially if the appeal is specific and reasonable.

In this particular case, I was hoping to identify suitable candidates to join my Product Team. By using my contacts to tap into the larger talent pool, I was confident I could accelerate my recruiting efforts. But I would also use the valuable face time to review a few of my past and future product decisions with these specialists.

Plan of attack

My first rule of professional networking is to make sure the meetings are productive for both parties. I began this post by declaring that I had very little spare time to spend outside my company. With that in mind, I began every meeting request with the assumption that my counterpart would likely be in the same position and would need some assurance that I would not be wasting his or her time.

So, aside from showing simple courtesy like confirming the meeting, arriving on time and choosing locations that would be convenient, I took extra care to make sure I was prepared for each discussion. 

Provide a Job Description

The primary goal for these meetings was to cast a wider recruiting net and to identify viable candidates for my open Product Manager position. I tried to make that clear in the invitation in the hopes of prompting some early reflection. But because the PM role can be different in each company, I wanted to further clarify the exact type of applicant I was seeking.

I had chosen to defer posting the PM job description on our web site until we had exhausted other available channels so there was no link I could share with my colleagues. But rather than send along some "pre-requisite reading assignment" ahead of our meeting, I chose instead to bring along and share a hard copy of the job description. The physical document, as a take away from the meeting, was meant to keep my appeal for help top of mind - for at least a few hours afterwards.

Prepare a List of Topics for Gathering Feedback

As I mentioned earlier, Product people like to talk shop as much as the next person and truly, I was no different. Once we had moved past the initial pleasantries and discussed the open PM position at my company, I switched gears to pick their brains on any of a number of subjects that I had recently encountered.

I truly wanted feedback and advice on my own projects so in an attempt to make the discussions more productive, I formalized my thoughts and even created some specific questions on each topic - because as a PM, you should never miss a chance to improve your interviewing skills!

Offer Assistance in Return

Besides paying for the coffee or meal, which always goes over well, I also made sure to save time at the end of the meeting to switch the flow and turn the conversation around. I wanted to give my colleague the opportunity to share with me what was happening on their end. What product-related problems were they wrestling with? How was their team performing? Did they have some big product developments happening in the next few weeks? 

And it never hurt to ask whether they were happy in their current job - sometimes you can get lucky and find a candidate in your immediate network.

“Let’s talk about you? Are you happy in your current job? Are they treating you well?”

Whenever the conversation turned to a problem or opportunity that I genuinely felt I could help with, I offered my assistance. And I made sure I followed up with any action items in my thank-you email.  

The impact

I am pleased to report that through this PM networking activity, I did indeed identify several viable candidates and that accelerated our hiring efforts. But more than that, I was able to reconnect with and renew important relationships with many of my peers. I collected valuable, relevant insight from these professionals that helped me validate or in some cases, adjust some of the product decisions I was making. I was able to expand my own network a bit, a typical but always welcome side effect. And then of course, there was all the great coffee!

Look for more reports from theProductPath around the recruiting for the PM role and professional networking here on PM Decisions.

More articles from our blog PM Decisions