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.

Create a year-end Product progress report

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

In an attempt to summarize our collective accomplishments over the past 12 months, I decided to create a simple, 1-page chart that communicates the product advancements and highlights remaining product opportunities.

Many people look to the end of the calendar year as a good opportunity for reflection and this is as true in the professional world as it is in the personal one. Twelve consecutive months would seem to provide a sufficient review period for attempting to understand the overall impact of the team's more significant product decisions.

I have previously written here about why I feel the Product Manager has a more pronounced need to establish credibility than most other roles in the organization. It is easy to make grand, sweeping promises but ultimately, a PM and his/her team will be measured (continuously!) by the results they achieve. And even those small victories can be short-lived as the team is pushed to address the next round of challenges.

So, it seems fitting that I take a little time during the last week of the year to revisit those promises I had made and to fairly tally up the "scores".

What drove this decision

In the spirit of transparency, I wanted to conduct an honest assessment of how we did or did not advance the product portfolio and then share that with the entire company. I had established clear objectives at the beginning of the year and now felt an obligation to compare our actual results with those original goals.

I was also hoping to create a new artifact that might even help motivate the teams. Something that said, "Look how far we've come!"  If it turned out the way I thought it would, it could become a new collateral piece that gets the Sales all fired up, sending a clear message to them about how much easier it had become to tell and sell our story to customers.

Above all, I wanted to use this progress report as a reminder to the entire company that we have made great strides together along the very roadmap themes I laid out at the beginning of the year. It turned out that it was also useful for pointing out, even foreshadowing, where we'd likely be spending our time next year.

The decision: Use the familiar customer process as a backdrop for reporting finer-grained enhancements across the entire product suite.

View fullsize

Simplified customer business process

For the past few years, the Product team has been refining our understanding of our customers' core business process. We ultimately captured the process model in a single, clear diagram which we have been promoting and reinforcing with each major release so that, by now, everyone in the company was familiar with it.

This representation of the business process had been especially helpful in orienting the product team's efforts and now seemed to offer the ideal structure for lining up the various product initiatives from the past year. So I thought I would use it as the underlying structure for my progress report.

Plan of attack

Being a fan of 1-page artifacts, I set out to build a single chart that I could use to tell the story of the past year, one that would clearly illustrate our highs and our lows, our triumphs and defeats, our victories -- you get the picture.

Collapse the business process to create a familiar backdrop

View fullsize

Flatten the familiar process for context

I was confident that the process model we had been using for our own internal discussions - and which had been repeatedly validated by prospects and customers alike - would provide the right context for my new chart.

The original process diagram had filled the entire page. I tried to retain the familiar shape of the process but compressed it to fit in a much smaller vertical space. I removed the actor icons but kept the text labels for each step, moving them to the bottom of the new diagram to maintain the various transitions in the process.

Create a simple scale for relative comparisons

View fullsize

Horizontal lines set up a scale for comparisons

Next, I needed to create a way to compare the various product initiatives in a way that my audience could see the respective value of each project as it related to the customer's business process.

Ultimately I created a 3-point scale with the intentionally provocative labels "Poor", "Par", and "Premier." If I was going to use this chart to provide an honest report on how well we did over the past 12 months, I wanted to have a way to communicate where we had done well, where we had fallen flat, and where we were still struggling with mediocrity.

Plot trajectories for each product initiative

View fullsize

Plot each project as a trajectory

With these structural elements in place, I was now ready to add my data to the chart.

Instead of representing each initiative as single points on the graph, I chose to roll up the initiatives under more familiar customer-facing features and plot them as parallel vertical lines. Each feature had a bullet point to show where the feature would have been scored at the beginning of the year. I then extended an arrow from the bullet and the length of each line was meant to show how much we had improved the feature over the course of the past 12 months.

For some features, I stacked more than one arrow if we had taken several passes at it. Some features had no arrows which were meant to show a complete lack of improvement - even more meaningful when they appeared lower on the scale. It was absolutely my intention to highlight these features as ones that would require attention in the months ahead.

The impact

I had no prior experience creating a chart like this or even using a progress report to roll up the results of a year's worth of product roadmap initiatives. I will admit it that it was validating for me to see the results of our collective efforts captured in a single place though I recognize some obvious shortcomings with my approach:

• My chart only has upward pointing arrows - One might get the wrong impression that none of the work we did actually made things worse for our customers - ha!
• My chart ignores all the non-feature work - Anyone that did not work close with the Product or Tech teams might get the impression that this is all we accomplished when the truth is that so much more was done to support our growing customer base.
• My chart only exists because the story is mostly positive - I'm not sure I would have pursued this task if I thought it would have shown us in a bad light.

I'd like to think I'm not purposefully avoiding reporting on any negative outcomes but I knew that I would inevitably focus on those areas that made us look good. In the end, I think this is a fair report and have received similar confirmations from others in the company. I certainly achieved my goal of painting a clear picture for the company and my stakeholders around the improvements we've made from a year's worth of product investments.

Look for more reports from theProductPath around charts, evaluating product portfolios, and managing stakeholders here on PM Decisions.

More articles from our blog PM Decisions

Balance give and take, yes and no, push and pull with products

In a week that seemed to bring every form of product choice a PM can encounter, I decided to exhibit strong product leadership on every front.

Most Product Managers are continuously making choices about what goes into the product and what stays out. We use tools like the product roadmap to break down and convey these decisions over appropriately-sized release cycles.

Senior PMs also have to make choices about which Product Manager works on what parts of the overall puzzle and how best to coordinate dependencies across all the pieces to deliver the larger solution in a timely way.

We make difficult choices about what we feel comfortable promising to the Sales and Marketing teams who are busy prospecting for future customers that will bring in new revenue.

And Product Managers have to make critical choices about how to balance the perfectly usable product with what's feasible given the available technical resources as well as other constraints that are also in play.

It is rare, in my experience, that a Product Manager is faced with all these choices in the span of a single week. This was one of those rare weeks for me.

What drove these decisions

We are closing in on the end of the calendar year and that is affecting each department differently:

• Can we close these deals before the quarter ends? Our Sales team is a rush, scrambling more than normal to close their deals. Sales leadership is pushing everyone to go a little faster and be more aggressive with their prospects.
• What can I tell my customers who have "urgent" questions about next year's product developments? Our Professional Services and Support teams are trying to work with existing customers who can't seem to wait for the future product enhancements that might be just around the corner.
• How will we grow the Product and Tech teams to meet the demands of the business? Our senior management team is trying to lock down schedules and budgets in the planning for next year, hoping to align individual departmental recruiting and hiring plans.
• Did we get as far as we wanted? And of course, my own Product team is doing some reflecting on our efforts over the past year as we think about changes we want to make in the coming year.

As I said before, this is a unique time of the year where Product Management, like other departments, is feeling an increase in pressure to respond to our customers, our fellow employees, and our stakeholders. But I felt more impact during this particular week as I fielded product-related solicitations from every corner of our business. 

The decision: Use each and every opportunity to demonstrate solid product governance.

In a recent, rather insightful exchange with a PM peer, I was made even more aware of how broadly the Product team's decisions will radiate outward to the rest of the organization. For example, the product priorities can influence deals in the Sales pipeline, ideally in a positive way, as we build trust with prospects around the upcoming roadmap commitments.

The choices we make will also impact how the Professional Services team and the customers do or don't utilize our products to solve their problems. In too many situations, I have seen product/platform deficiencies spark some creative workarounds, many of which create even bigger complications for me as I inevitably roll out future product enhancements to address the feature gaps.

I was made even more aware of how broadly the Product team's decisions will radiate outward to the rest of the organization.

Our decisions can also lead to new technical debt (knowingly or unknowingly), that will someday impact downstream engineering work.

Like every Product Manager, I carefully weigh the impact of my decisions with exactly these outcomes in mind.

Plan of attack

While I was still intent on pushing forward with my own Product agenda, I tried to be conscious of the respective priorities and stresses of each department with whom I came in contact. In each circumstance, I looked for a way to balance the needs of all parties while still doing what I thought was best for the long-term health of our business.

Along the way, I also found opportunities to revisit and improve my own methods.

Give a product, take a product

This week, I passed over the ownership of a new product to a very capable PM and was thrilled to see him deftly receive the hand off. It was a big relief for me to be able to move the effort safely off my plate, but it was even more satisfying to watch an experienced Product Manager run the entire exercise without any oversight. I am confident that this decision will help the company deliver the new product to customers according to the original plan.

During the same week, I pulled a separate product initiative away from a different PM on my team, partly because I needed him to focus on (and finish) a separate project. But I was also concerned that the initiative was not advancing at a good pace, which was going to negatively impact a large percentage of our customer base. This was the harder of the two product ownership decisions, but the needs of the customer ultimately prevailed.

Saying no and saying yes to customers

This week, Sales pulled me into two high-profile customer conversations where strategic outcomes were partially dependent on release dates outlined in my product roadmap. In the first case, I knew our teams were ahead of schedule which prompted me to confidently confirm to the customer, "yes, we will absolutely hit those dates for you."

The second conversation didn't go as well. I began the discussion by asking questions meant to help me discover exactly what this organization thought they needed. It didn't take long for me to recognize their request though, as it frequently shows up in competitive sales situations as an obvious land mine strategically placed by another prominent vendor.

My attempt to point out to the customer that they had been misled was not well received. They persisted by parroting their "needs" to us and pinned me down by asking if I had plans to deliver features to address their problem. I said, "No, we do not currently have such a feature and I have no plan to deliver that in the next year.  Specifically, it is not on the product roadmap."

After that call ended, I found myself in some heated discussions with our Sales team who was not altogether pleased that I had been so blunt with the customer. I reflected on this for some time and later came back to apologize and to say that I would try to soften my answers on future such calls. Indeed, I would need to learn better ways of saying "No."

Push and Pull Priorities

This week, I also sat with the CTO to have several talks about our product plans for next year. We agreed that the teams would need to spend more time on product deficit in the months ahead but recognized that it would impact our ability to keep up the pace of innovation in terms of customer-facing features.

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

In a simple whiteboard exercise, we were able to list more than 20 separate initiatives that needed prioritization and ultimately reorganized a number of the items on the product roadmap.   

Some of the short-term, scale-related items would ultimately pay off for all of our customers even if they couldn't be demoed in a webinar or training course. Many of these projects were overdue as parts of the underlying platform were in need of repair or rebuilding to handle the next wave of new users. 

I can appreciate the need for ongoing investment in the plumbing, in the supporting architecture and all the frameworks on which our products are built. I understand how the resulting performance of the applications contributes to a positive user experience. Still, it can be hard to sell that to the other stakeholders in the company who can't readily appreciate the improvements. Part of my job in the coming months would be to help extol the virtues of those investments to impatient parties who crave more visible features.  

The impact

I left out many of the other events of the week that included making some necessary personnel changes, planning for an upcoming office space shuffle, and recovering from the annual holiday party. But the net impact of the decisions I described above were ultimately positive for the company. I am confident that we will end the year strong and will have an even better, more productive product year ahead.

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

More articles from our blog PM Decisions

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

Evaluate the available data for making better product investment decisions

In recognizing that many of the decisions we had made over this past year were not driven by or supported with real evidence, I decided it was time to change how the Product team gathered and used data in our product development process.

Metrics and the related analysis are as important to Product teams as they are to any other department. But in my experience, it can be hard to nail down exactly what data your Product team should be monitoring. Because we interact with so many other parts of the organization, we may find ourselves gravitating toward (or flat out borrowing) directly from what other departments are (or should be) measuring. For example, it may seem obvious for us to latch on to customer conversion metrics from the Sales funnel. But then we also recognize that Customer Success is interacting directly with actual paying customers so maybe Net Promoter Score is something we should be tracking.

I have not found a single, universal measure that works for every Product team at every stage of its growth. I think good Product teams must continuously evaluate what data they need to help them make the best decisions. It is safe, if not self-evident, to start with metrics that ultimately tie back to and support the organization's high-level goals. But settling for superfluous or vanity metrics would seem to go against the prevailing wisdom which suggests adopting metrics that are truly actionable.

Product teams must continuously evaluate what data they need to help them make the best decisions.

I was interested in advancing my own organization's capabilities around gathering and using product data. In this article, I will share what came out of the exploratory discussions I initiated with members from the Product, UX, Engineering, Operations, and Data Analytics teams. In a companion article, I will report on how this analysis led to the next set of decisions to improve our overall proficiency.

What drove this decision

If you were to ask me to defend any of the decisions I've made with the teams over the past 10-12 months, I would not be able to reach for charts or graphs that clearly show one or more metrics trending up or down over time. In fact, if pressed, I might rattle off mostly anecdotal evidence like:

• We've experienced little to no push back from internal stakeholders about this past year's product roadmap
• There has been a noticeable absence of customer complaints around this year's product releases
• The Product team and I collectively lack any real regrets in our decisions so far (i.e. no major screw-ups)

Oh, and we closed two of the largest deals in the company's history this past year!

Had we been getting lucky by landing indifferent customers? Had the Product team simply taken the easy path or picked the low hanging fruit to avoid complexity or confrontation? I don't think so. I think the more likely story is that we had sensibly chosen to tackle the most pressing/glaring issues that were the highest priorities for all parties.

But it is not as though we were operating in a bubble. Along the way, we had certainly been talking directly with end users and also indirectly with the internal folks who themselves, talk with customers. But many times we pushed forward without adequate data and that hindered our ability to understand the impact of the changes we were making to the products.

I knew we could make better decisions if we had more information with which to work.

The decision: Confirm with the team exactly what data we were missing and what we would need to do to get our hands on it.

I want to be clear that this was an internal Product team endeavor driven by a desire to improve our own capabilities. Good or bad, the organization had not reached a point where my team was responsible for reporting KPIs or similar measures to our senior leadership or other internal stakeholders.

But before I could dream about some impressive analytics dashboard that might make Edward Tufte smile, I thought we could start small and work our way up from there.

Plan of attack

There was unanimous agreement that the Product team would benefit from collecting both qualitative and quantitative data. Thanks to an outstanding UX team, we had been making steady progress with capturing and evaluating qualitative data from customer interviews, surveys and the like. That work had indeed driven some major initiatives including the release of our new product earlier this year.

We determined that we would focus instead on complementing what we already had with more cold hard numbers from our own customer databases.

Focus on understanding feature usage to assess the impact of changes

The team concluded that the most obvious place to start would be to get a better grip on which customers were using what features and how. Much of our ongoing work would continue to revolve around revamping the existing platform components to provide a better user and administrative experience for our customers' primary use case.

Our challenge was knowing the size of the impact of making changes. Which customers would be affected? What migrations would be necessary? How much revenue would be at risk?

I shared the following, relevant story with the team to drive home the point:

Earlier this year, I had to push back on an anxious Customer Support team who was, as it turned out, overly worried about an upcoming feature migration I had scheduled for the entire customer base. Based on no real evidence, they had gotten themselves all worked up over what they believed would be a disruptive conversion. After running some simple reports, I concluded that less than 50 customers would be affected and most of them would barely notice as they had not really invested much in the (soon to be) legacy version of the feature. In the end, we pulled off the feature migration without a hitch and never received a single customer complaint.

Update our product hypotheses to include outcome-based metrics

The Product team had been getting better at creating problem hypotheses to help drive individual enhancements and sometimes, even entirely new products. The hypotheses helped us focus on real problems and generally followed this pattern:

We believe that [user persona] is struggling to [complete this task, achieve this outcome, ...]

I suggested to the team that we look to extend the hypothesis statement to incorporate a measurable result as suggested in this Medium article by Chris Abad:

“We believe if we provide [solution] to [customer], it will result in [outcome] as measured by [measurable success metric].”

If we could tie measurable outcomes to the problems we were attempting to solve, it would certainly give us some specific metrics to zero in on.

Help the team with product and design (re-)discovery

I am convinced that the 10-year-old software platform I inherited had accumulated much more code than was necessary to attract and retain customers. So in an attempt to reduce the size of the product set, I committed to devoting some time in every upcoming release to begin paring down the code base.

But we needed to be prudent about how to do this. As the teams looked to rebuild single pages or overhaul entire features, we desperately wanted to know what had to stay and what could be eliminated. We agreed that we would be able to draw good data from our existing customer base to help make smarter design decisions and prevent us from (re-)building stuff that is not needed.

The impact

I felt a little deflated at the end of this week's exercise. In the back of my mind, I had known that we should be operating better but it did not truly hit home until we assessed our current situation. It was a more than a little frustrating that we had so little data to go on.

Ours was not the first Product team at the company and our predecessors apparently had tried similar efforts in the past. I tracked down a previous Head of Product and learned from him that this had been a struggle for him in the past as well.

I am not discouraged though and am prepared to lead the team through the next stage in this process. Look for the companion article that describes the results of our push to acquire the product data identified here.

Look for more reports from theProductPath around product data, metrics & analysis, and product culture here on PM Decisions.

More articles from our blog PM Decisions

Wind down current product initiatives before starting new ones

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

In recognizing that the Product team would not have the capacity to launch any new projects in the weeks ahead, I reassessed all the in-flight work to identify lower priority items that could be put on the back burner.

I believe that inside most successful Product Managers there is a solid Project Manager. After all, what's the point of being able to identify the right features to build if you can't then decompose and schedule the work in a realistic way?

I was certainly drawing from that particular skill set as I reviewed the list of projects that we currently had in motion. But instead of slotting in new tasks, I was focused on capacity planning and looking for ways to reduce the overall workload.

What drove this decision

There are any number of reasons why a team might take on more work than they should. Many of us will simply raise our hand to help when we hear about something that interests us. For example, an Engineer is easily tempted to spend time poking around with a cool, new technology. It is not uncommon for small research stories to grow as you uncover more details. Sometimes small projects get early traction and begin to snowball quickly. Then there are those urgent fires need that to be put out but which ultimately take you in unexpected directions.

I will take the lion's share of the blame for letting our teams get a little carried away over the past few months. Like the Engineer who latched on to it, I was also intrigued about one of the tech-related research projects. And like the Product Manager who had been working on an important feature, I was also curious about we could extend it beyond the original scope. I could argue that these, along with all the rest, were good-sounding and well-intentioned projects.

But, in thinking about the future, I knew I had to revisit the current project mix and better position us to take on the next round of work.

The decision: Find good stopping points for some of the projects in motion to clear the path for new initiatives.

The teams only have so much capacity and the calendar is still a fixed constraint so the next best option is to revisit scope. In some ways, though, this was an easy exercise.

Some of the projects had gotten long in the tooth and I could tell the enthusiasm had started to wane. Always conscious of team morale, I knew I could reassign those folks to different projects. In other cases, I needed to get straying efforts back on track or to achieve some closure, so I created some break points.

Plan of attack

I was looking for simple criteria that helped me pick new projects over existing projects. In most cases, that came down to determining when each initiative would like return value to the business. With each project I wrapped up, I was able to increase our capacity to tackle new stuff.

Complete a year-long drive to finally get over the goal line

I started by addressing a particularly problematic project that had stretched out for far too long. In fact, this particular enhancement had been stuck at 95% complete for almost an entire year and everyone was eager to see this finished.

Product and Engineering had completed their pieces many months ago but were now paused indefinitely as an absurd number of weeks had passed without any forward progress. The effort was blocked, waiting on our Operations team who had been struggling to prioritize the work. Unfortunately, I had no more control over the Operations department than any other and would need to be creative in how to apply pressure.

I tried using guilt mixed with a bit of positive motivation and even some old-fashioned horse-trading.

So I tried using guilt ("c'mon guys, this has been overdue for far too long") mixed with a bit of positive motivation ("our customers are really looking forward to this enhancement!") and even some old-fashioned horse-trading ("how's about I offer up some time in the schedule to tackle this other project you care about in exchange for knocking this out?"). In the end, I exhausted some personal capital to get this done but was happy to finally see it on a path to completion.

Scope back a feature enhancement that had expanded over time

In another scenario, I zeroed in on another feature enhancement that had experienced some scope creep. The PM had started out with good intentions but had augmented the work over time as he found more and more technical debt to tackle.

Now as we realized that the latest round of proposed changes would push us well into the new year, we culled the core improvements from the larger set of stories and chose to deliver a smaller, but still substantial upgrade to our customers. This decision contributed some breathing room to the roadmap, freeing up some Engineering resources to work on new work in the weeks ahead.

Conclude a key product prototyping effort

Several months earlier, I had recruited a talented, external resource to build a data analytics prototype that would enable us to conduct some product discovery work with our customer base. In doing so, we secured a trial license to a third-party business intelligence tool which would expire in the next week. That provided a natural stopping point and a good motivation for wrapping up that initiative.

I worked with the contractor to put some final polish around the prototype and together, we delivered a final presentation to my CEO and to an influential external party. After those successful demonstrations, we put the prototype on the shelf with the expectation that we would be able to bring it back at any time, as our needs (and budgets) changed.

Pause the team on new research proposals

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

I am a big fan of continuous research and development and we are not short on new areas to explore. It is entirely possible, though, that I let us get ahead of ourselves by encouraging folks to come up with new product and technology ideas to research, with the thought of being productive during those holiday weeks at the end of the year.

Now, I had to reset expectations a bit. As gently as I could, I conveyed my appreciation for everyone's enthusiasm and commitment while at the same time explaining that we would have to table some of the research proposals for the time being.

The impact

There is nothing particularly special about cleaning up projects at the end of the year, but the cumulative slow down in many areas of the business provided me with a great excuse to pare down our workload. I made sure we did not simply abandon projects mid-stream. I also did not want to give anyone the impression that we had simply become distracted by something more exciting. I tried to help the teams recognize that priorities were always changing while at the same time, emphasized the value of achieving closure.

The net effect of these decisions is that I had fewer projects in motion and more Product and Engineering capacity to head into the new year.

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

Build the prototype to aid in new product discovery

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

In recognizing that we were finally in a position to start gathering real requirements from a prime new customer, I decided to move forward with building a prototype for a new product offering.

The Product team had known for some time that we had a legitimate gap in our product portfolio around an MS Office 365 Plug-In but we were not overly anxious as it was clear that the gap was not preventing the company from winning new deals. Even though our main competitor would regularly raise the issue with prospects during the sales cycle, drawing attention to our "deficiency", it had never cost us a sale.

The MS Office 365 Plug-In saga continues to unfold...

You can review the entire story through my past Product Decisions:

HEAD OFF A NEW PRODUCT IDEA BEFORE IT GAINS ANY MORE STEAM

CLARIFY WIN-LOSS SPECULATION WITH POST-MORTEM INTERVIEWS

BUILD A QUICK PROOF OF CONCEPT

COMPLETE AN OPPORTUNITY ASSESSMENT FOR PROPOSED NEW PRODUCT

CALL IN REINFORCEMENTS TO ADVANCE PRODUCT INITIATIVES

From the beginning, when this "urgent need" was first identified, I had been steadily pushing back on internal stakeholders (see sidebar). I knew we didn't have the available resources or bandwidth to tackle this and without a line of customers outside my "product door" clamouring to have the new feature, I was hesitant to even start conversations around the Plug-In.

What drove this decision

In the previous quarter, we had signed our biggest customer in the company's history and, in our lengthy discussions with them around their needs, we had identified the (missing) Plug-In as a key, must-have feature.

This one customer, when fully deployed, could have more than 2,000 people using the new Plug-In. Based on those numbers, it seemed reasonable to me that we now had a decent base of users from which we could start to gather some useful insights.

The decision: Complete a working prototype that we could use to drive productive conversations with customers around requirements

I was eager to start talking with and observing real users in the field but I didn't want to do that using the low fidelity and crudely fashioned proof-of-concept we had completed a few months back. It was time to build and start testing with a real, functioning prototype.

Plan of attack

We were still very early in the product cycle for this Plug-In and there was no pressure to cut corners or skip steps in our product discovery process. I wanted to make sure we used a disciplined approach.

In this first phase, we would create a prototype that would give our Tech team more confidence in what it would ultimately take to develop and support such an app AND that would give the Product Team enough material to have meaningful discussions with the first round of users.  

Vet the feasibility of our technical approach with Engineering

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

I had some solid ideas for how to create an initial version of the Plug-In though it was fair to say that we would be forging into unfamiliar territory. The Tech team had never developed this kind of app but we knew we would be getting support from our friends at Microsoft who is one of our key technology partners.

The first step in building the prototype was making sure our team could nail down some of the technology challenges that we would face. For example, high on our list were questions about user authentication, API access, and deployment of the app to customers through Microsoft's "online store".

So, over the course of a few weeks, the team completed a functioning prototype that addressed these areas of concern. Now, more confident that we had cleared the most immediate technical hurdles, I proceeded with getting some internal validation. 

Share the prototype with stakeholders inside the company

I very much wanted to show the prototype to our Sales Engineers. They had always been good product collaborators and certainly understood the broad use case for the Plug-In. I set up a meeting with them and the Product team and with the Engineers to get and record some early usability feedback.

On the way to that meeting, I made a small detour to give a brief demonstration to our CEO as a courtesy “first look". He had taken a keen interest in this initiative and had been stalking me for many weeks. And even though we had only addressed the most simple use case in this iteration, he was very impressed with our rapid progress. My only regret was letting an Engineer run the demo - who uses superheroes for their sample data? Ha!

I should have known not to let an Engineer run the demo - who uses superheroes for their sample data?

We then sat with the Sales Engineers and reviewed our current hypotheses with them. They see much more front-line action with prospects in the sales cycle and helped validate our approach, often tying back to their deals from the past weeks and months.

I then had each of them install the Plug-In on their own machines to test it out. The response was overwhelmingly positive and we could see them already thinking about how they might adjust their standard demo scenarios to incorporate this new component.

One of them suggested they start using the Plug-In immediately to help them with one of their own team activities and I offered to check back in with them in a few weeks to see how it worked for that additional use case. 

Show it to the technology vendor on whose platform our prototype was built

We had invited representatives from our partner Microsoft into our office for a high-level meeting to talk about Office 365 integration among other things. The timing of their visit provided a perfect opportunity for a prototype demo and to show what we had achieved in the past few weeks, with some help from their own technical folks.

After setting up the customer scenario with the group, we walked them through the working prototype and talked through some of the challenges we had worked through to get to this point. The Microsoft team provided additional validation around our approach for the Plug-In and gave us some pointers for how we could move forward. Our remaining questions were captured and would be carried back to their teams to help get us the answers we would need before rolling this out, even to beta customers. 

In the end, I was pleased to know that our partner was ready to help us with next steps. They also expressed interest in the upcoming deployment with our new customer as it would provide a great case study for both us and them.

The impact

With the Engineering team, I was able to work through a few of the big technical unknowns to build a working version of the Plug-In. By meeting with and showing off the Plug-In to a few internal resources, we were able to get some early, but solid validation. And in reviewing the finished work with the vendor on whose platform we had built the Plug-In, we confirmed that we were on the right track in how we were going to deploy and support the new product.

But none of this would be worth anything if we didn’t immediately start validating the Plug-In with actual users. That work would likely start the very next week and is lining up to be the next chapter in this series.

Look for more reports from theProductPath around product validation, feasibility, and product investments here on PM Decisions.

More articles from our blog PM Decisions

Product-ive roadmapping for the holiday slowdown

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

As we head into the end-of-year home stretch and the inevitably slower holiday period, I decided to make some roadmap adjustments to ensure we would finish the year strong.

It is difficult for any team to plan well for last few weeks of the year. Even if your business doesn't align with the traditional calendar year, you are likely to be working with customers, partners, and vendors who do scramble to wrap up their quarters and annual cycles at year's end.

On top of that, many of your employees are requesting time off from work leaving sizable gaps in the schedule. And you can just give up on trying to arrange any real business-related travel plans, e.g. to visit customers or to conduct on-site interviews.

With all the distractions that come with the holiday period, I began to ask myself how I could make the most of these remaining weeks of the year.

What drove this decision

We had been moving at a nice clip for the past few months. I was proud of the work being cranked out by the Product and Tech teams. We had achieved some good momentum and I was eager to preserve as much of that as I could. Many of the current projects would naturally extend into the early part of next year and I was determined to minimize any slow down around these particular initiatives.

We had achieved some good momentum and I was eager to preserve as much of that as I could.

But I also knew that it would be difficult for teams to coordinate larger tasks if their coworkers' schedules were inconsistent. With all that in mind, I took another look at the product roadmap to optimize our efforts for the last few sprints of the year.

The decision: Line up a collection of smaller stories, projects, and research to advance roadmap initiatives and to keep the teams productive.

I don't want to make it sound like the teams would otherwise be idle. We had just deployed our last major release of the year and I knew we would have some post-release work to tackle. For example, it was going to take some team coordination to gradually and prudently roll out some of the latest enhancements to the full customer base. Then there was the need to respond to users who would be wrestling with the most recent product changes. And of course, we are always prepared to deal with any bugs that may have slipped through.

The real challenge for me was to identify new product work that we could take on and to fit it into our irregular schedule.

Plan of attack

My goal was to maximize the collective team utilization and minimize any dead spots in the upcoming calendar. No one would be satisfied with blatant busy work and yet, it would be difficult to make much tangible progress on any new product initiative. I, more than anyone, wanted to feel like we had been productive during this time. 

I determined that no one solution was going to work so to increase my chances of success, I ended up using several different approaches simultaneously. In the end, I was able to surface a number of smaller-scale projects to accommodate the various gaps in the teams' schedules.

Lay the remaining groundwork for next year's new product offering

Over the last 8-10 months, we had been working on a number of smaller, separate initiatives that were intended to fit together to create a larger, cohesive feature set. However, unless you had been working closely with the Product team, it would be difficult to see how the individual building blocks we had been delivering over many releases were meant to come together. This was the time to explain the broader vision.

View fullsize

I began by updating the product roadmap to illustrate how we would piece together 4 or 5 of the individual initiatives to create a major new offering to be rolled out in the early part of next year. Then, I scheduled new stories that would ultimately combine the separate components into a new whole. I had already convinced myself that this was going to be a thing of beauty but of course, I have been wrong before!

After we had finished connecting the dots (and bytes) and had painted the whole picture, we would be able to move forward by putting it in front of our users. I would continue to validate the new offering by testing it with our internal stakeholders, with customers in our Labs program and finally with prospects in the Sales funnel.

Tee up a list of discretionary items to fill downtime

Without even looking closely at the calendar, I knew we would have a week or so before the start of January where the Engineering ranks would be somewhat thin. My counterpart overseeing Engineering agreed that we could declare a "free sprint" where the developers would have more latitude in how they spent their time in the office.

I had a decent backlog of research topics that I lined up in case the well of ideas ran dry but I was pretty sure the developers would surface their own pet projects to keep themselves occupied. We continue to see some forward-thinking proposals come up through Engineering and I certainly wanted to encourage more of that activity.

I was pretty sure the developers would surface their own pet projects to keep themselves occupied.

There were, in fact, a few out-of-band product initiatives that were already in motion, and all in different stages of completeness. Those Tech Team members that had expressed an interest in exploring extracurricular material had been encouraged to do so with the intention of tying the work back to short- and/or long-term customer value. Based on the success of those efforts, I could easily extend the initiatives and even stage a few more to follow.

Swap in some overdue projects to tackle technical debt

The company has had a banner year in terms of acquiring new customers. But the reality of growing your customer base and increasing the number of users/transactions on your platform is that scale-related challenges bubble to the top. Inevitably, I would need to schedule some cycles for the less glamorous housekeeping activities.

Every software company has technical debt and it requires discipline to stay on top of that debt. I am always grateful to find those few Engineers that appreciate the value of cleaning up and are quick to roll up their sleeves (can you roll up t-shirts sleeves?) and pitch in to help. We would use this end of the year time to tackle a few of these efforts as well.

The impact

It can be tricky for a Product Manager to figure out how to best utilize the weeks at the end of the calendar year. I looked for some small, but important projects that would move us forward but that had few, if any dependencies to avoid schedule impediments.

In using these three approaches: the free sprint, more "groundwork" stories needed to assemble the next product offering, and addressing technical debt, I was able to stock the upcoming sprints with productive work and reduce everyone's concerns about holiday dead time.

Look for more reports from theProductPath around capacity planning, roadmap planning, and managing product teams here on PM Decisions.

More articles from our blog PM Decisions

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