Sync up with Product Marketing

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

Over the past weeks, I had lost touch with my colleagues in Marketing, so I decided to take advantage of some mutual schedule alignment and catch up with our Product Marketing Manager.

“The product marketing team member is responsible for telling the world about the product, managing the external-facing product launch, providing tools for the sales channel to market and sell the product, and for leading key programs such as online marketing campaigns and influencer marketing programs.”

— Marty Cagan

On at least one previous occasion, I have mentioned how delightful it is to have a genuine Product Marketing Manager on the team. There is a distinct role for Product Marketing that sometimes doesn't manifest in product companies until they've reached a certain stage in their growth. Until then, those key activities and responsibilities will be carried out by people in other positions, who probably already have too much to do.

I was one of those people.

Our company had finally reached that growth stage and now had a full-time PMM who was in charge of tackling the myriad tasks associated with taking our products to market. 

What drove this decision

As you might expect, our new PMM became busy as well, dashing any aspirations I had of working side by side with her on a regular basis. We both still had many other priorities competing for our respective time.

But there had been some early achievements. Over the past few months, I was able to transition the Release Communication planning that accompanies each formal product release. Neither of us was ready to put those tasks on auto-pilot just yet and expected to do some additional tweaking. Beyond that, we were eager to tackle a whole host of new product-related activities that we would now be capable of performing. This would require more coordination.

The decision: Regroup with my counterpart in Product Marketing to get our collective and connected plans in order.

I will admit that, up until recently, my priorities and focus around go-to-market had always been more short-term in nature:

• How do we pull together and update all the product collateral for the upcoming product release?
• Who is writing the Release Notes, delivering the webinar, training the Sales Engineers?
• What needs to change on the marketing website, in the knowledge articles, in our sales presentations
• How are we communicating changes, if any, in our pricing or bundled offerings?
• Do we have customers that can help us with promotion via testimonials, reviews, or case studies? 

All these questions and more are now being fielded by our PMM but I still care very much about the answers and outcomes and, in many cases, am still on the hook for supplying some of the critical details.

Plan of attack

Weeks had passed with very infrequent contact between us so we had more than a few ducks to get in a row. We had to square away some short-term tasks and also finalize a few of our longer-term projects.

Revisit the Release Communication Plan

We had been executing well on the Communication Plan for the last few releases. It was now a familiar exercise but one that still requires coordination. Given that this was our last big push of the year, we were both hoping to finish strong.

Methodically, we walked through our checklist which included, among other things:

1. Creating the material, prepping, and rehearsing for the post-release webinar
2. Sending the series of teaser emails to customers to register for the webinar
3. Conducting brief user surveys before and after the release
4. Crafting a press release for one of the prominent new features
5. Refreshing the internal sales collateral to better communicate the enhanced product messaging
6. Updating the technical sales demos to reflect the product updates

Prep for upcoming talks with Analysts

In a few of our larger sales opportunities, we were painfully reminded of how important it was to have visibility with prominent industry analysts. In response, the company had launched an initiative to get us back on the industry analysts' collective radar and re-introducing them to our latest and greatest from the product side was a big part of that push.

Building on some introductions and (albeit brief) conversations we had had with analysts at a recent trade show, the PMM had set up some individual briefing calls to re-engage with these industry experts. She and I walked through the schedule and the best way to approach each call to maximize credibility with our larger customers and prospects.

Complete last steps of new product launch

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

One of the best things to happen this year for me was launching a brand new product to the market. It was my first since stepping into the new role and I was eager to see it take off.

The PMM and I had been executing a solid product rollout plan for several weeks now and we were nearing the end of the operation. The final steps were to get the new product listed in a prominent app store, and then begin a vigorous campaign with the Sales team to introduce and upsell the app to existing customers.

We confirmed that after testing the response from our core base, we would ramp up the product marketing efforts and make a much stronger push to the greater market.  

The impact

It is a satisfying feeling to get caught up when you feel behind. We both came away from our meetings this week more confident about our plans for the rest of the year. In my opinion, regular email-based discussions and ongoing status updates are often adequate but, for the critical matters, I'll take uninterrupted, face-to-face meetings any day of the week.

Look for more reports from theProductPath around product releases, managing stakeholders, and product feedback 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

Call in reinforcements to advance product initiatives

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

In recognizing that my internal team members did not have the time and/or expertise to help with a few of our upcoming and impactful product initiatives, I decided to reach outside the company and use trusted resources to temporarily expand my team.

My team has been working at full capacity and is focused on the exact right priorities to continue delivering strong product releases to our customers. There is always more work to do though and sometimes business priorities stretch beyond the team's existing capacity.

There are also budget constraints that are preventing me from expanding my team in a way that would help me address the projects that have bubbled to the top of the company's wish list.

What drove this decision

Good problem solvers can find creative ways to get around roadblocks. I was grappling with a backlog that was starting to look increasingly daunting and could not rely on the familiar and dependable resources that were tied up with other important work.

So I took some time to review the most pressing items and determined that there were opportunities to make short-term progress that would relieve a bit of the pressure. We could find the resources just outside the company's borders and engage the expertise we needed to catch up.

The decision: Recruit available experts from the company's extended circle of trusted colleagues to help tackle a few pressing product engagements. 

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

We all know smart, dependable people and we try to hire them to permanently join our teams when we have the chance. But these are highly sought-after resources and it's not feasible to hire all of them - how many organizations need 5 senior-level specialists in given functional area? And besides, many of them have already been scooped up by other lucky companies and are happily employed in good positions.

But sometimes, you can catch these folks between gigs and if the stars are aligned, you will have the opportunity to pull them into your group, even if it's only for a brief period of time. I was fortunate enough to have several of those opportunities at the same time and decided to act so I could move forward with my product plans.

Plan of attack

I had been mentally cataloging important projects that were product-related but would not be easy to fold into the main product work stream. Most fell somewhere between must have and nice to have. So to improve my chances of being able to outsource these initiatives to interim resources, I adjusted the scope for each by decomposing larger efforts into smaller increments with shorter iterations to better accommodate less predictable schedules.

As I continued to network with smart product people outside my company I had been on the lookout for available resources with the specific projects in mind. This week, I was able to pull in some strong people to tackle a few of my projects. Coincidentally, each had recently switched into job hunting mode and were delighted to have some part-time assignments to fill the gaps between recruiting activities.

I seized the moment(s) and put them to work immediately to start these three projects:

Build a plan to move from proof-of-concept to prototype

There is a new product proposal that has been gnawing at me for the better part of a year now. I've written about it before (see here) as it continued to gain steam (see here) despite my attempts to slow it down (see here).

This is not the time to argue the merits of this particular proposal but in the spirit of compromise, I have agreed to take the next step in building a true working prototype from the previous proof-of-concept. I was prompted more by the additional learning we could achieve around the technical feasibility than I was in gathering important user insights from an interactive, UX prototype (that would most certainly come later).

I found a talented and credible Product Manager to lead this technical prototype project and paired him up with an expert from one of our technology partners as well as with one of our own Engineers. Collectively, we reviewed the project's scope and made only a few small tweaks to build a 30-day plan that was mostly likely to deliver the outcome.

Revamp product documentation

I don't think I'm stretching the truth when I say that the Product and Tech teams have collectively stepped up our game this year. In addition to reducing the duration of our release cycle to deliver more updates more frequently, we have also focused on pushing out more high priority feature enhancements that are based on direct customer feedback.

What we haven't done well is keep up with all the supplemental collateral that typically accompanies product releases.

What we haven't done well is keep up with all the supplemental collateral that typically accompanies product releases, most notably our official product documentation. There are, I'm ashamed to admit, deficiencies in our collection of knowledge articles with out of date material, flimsy coverage of major components, and complete documentation gaps around key new features.

So I asked a really smart person to help us out. She came in, took one look at our Knowledge Center and decided she would do more than just fill in some obvious gaps. I had asked for help in getting the team caught up - what I got was a proposal and estimate for overhauling the whole depot. Her plan was so impressive that it took me no time to get the entire project approved.

Analytics roadmap

Several weeks back, I had pulled in one of these same folks to help me think through an analytics-related offering. The response to that deliverable had been overwhelmingly positive, both internally and with customers. Based on that success, I reached out to her again and asked for assistance in mapping out a high-level plan to get us to the point where we could actually produce those results in a production environment for customers.

She was the domain expert and needed little support from me other than to know how best to position the final recommendation and how to apply the appropriate polish to effectively sell it to my stakeholders.

The impact

Eventually, I'd like to expand the Product team to be able to tackle even more of the "product backlog" but these short-term engagements have allowed me to make some good progress in the meantime. Outsourcing work can be a great tactic when time or skills are in short supply. My own experiences have been positive, but a great deal of that success is directly tied to finding and securing great resources, inside or outside the company.  

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

More articles from our blog PM Decisions

Celebrate product wins big and small

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

It's easy and obvious for everyone to come together and share in the company's larger victories like closing a big deal, but I decided to devote some time to acknowledge, if not revel in some of our minor triumphs too.

Last month, we executed the largest sale ever in the company's history. And while there was no small amount of boisterous high fiving going on over in Sales, it was a great opportunity to bring all the departments together and spend a few moments cheering as a single group.

A big product win too

I was celebrating of course but for a slightly different reason. I was particularly encouraged by this deal because of how it reflected on our current product. It would seem that we had met the customer's needs exactly. After concluding a long sales cycle (not uncommon for an enterprise software company), we signed a contract with the customer without having to promise any changes in the core product or adjustments to the roadmap (quite uncommon for an enterprise software company).

Rarely have I been able to avoid the uncomfortable product roadmap discussions with well-meaning prospects on one side and hovering, commission-obsessed sales reps on the other, trying to move the deal along by finding the right words that would address the urgent needs for "missing" features.

Product Managers dream of building the exact right product for their target customers and when a big one lands, you have to feel good about it.

So this was indeed a victory for Product and also for our dear friends in Product Marketing. Product Managers dream of building the exact right product for their target customers and when a big one lands, you have to feel good about it. But those victories can be short-lived as all eyes inevitably turn toward the next challenge.

What drove this decision

It is hard to say if or when we'll ever top this milestone, but it was another event that happened this past week that made me stop and think about the smaller accomplishments that also deserve recognition.

We had recently rolled out a new product which has been well-received by customers. One, in particular, an early and avid adopter, had recently become frustrated when a change to their own production environment temporarily "broke" our app. They called up and asked us to help remedy the problem because they couldn't go back to the way things were before using our app. 

I immediately thought of that great 1-question survey popularized by Sean Ellis that helps Product people test for this exact outcome: if enough users respond by saying that they would be "very disappointed" if they were not able to continue using your product, then you should feel confident that you are the right track.

We had experienced that exact outcome and even if it was only 1 customer, I still call that a victory! And I wanted to play up those wins with the troops too.

The decision: Recognize and applaud the lesser product successes too.

As a senior team member in the company, I have more visibility than most when it comes to departmental activity. I see the accomplishments being made every day and now I wanted to share those positive results with the appropriate parties who were not always directly connected to the action.

Plan of attack

My loose "plan" was simply to keep an eye out for opportunities where I could funnel reactions and reports back to the folks who would otherwise not hear of them. Along the way, I was a little curious to learn that there were not enough regular channels or venues for doing this and that sometimes, I had to get a little creative. 

Share glowing feedback from a significant product demo

Early in the week, I delivered a custom product demo for an important, external party who I would position somewhere between future business partner and potential investor. Several times during the demonstration, I received compliments including an amazing, unsolicited comment from one of the women who was "weeping a little," wishing she had had the chance to use our product while working for her previous company.

At the very next Engineering standup meeting, I relayed the flattering remarks with the team. Some rolled their eyes at the glowing hyperbole, but I could tell they appreciated the message. 

Appreciate engineering feats

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

Later in the week, we reached what I called a golden spike moment, referring to the 19th-century achievement of connecting the two sections of the First Transcontinental Railroad. In our case, two Engineering teams had connected a major new feature with its corresponding new configuration page.

We were now able to demonstrate how to build a new configuration and then immediately use that to launch the end-user tool. Achieving this (long overdue) task meant that we could now address a key pain point for our customers. I celebrated by delivering artisanal pastries to the teams at the sprint planning meeting.

Join in the "New features" huddle

The Product team was very excited to have rolled out two new, high-profile features in the last major release. However, we knew to temper our enthusiasm as it often takes several weeks or even months before customers latch on to and begin utilizing them in any significant way. Such is the pace of B2B software.

But one early indicator of success is when our own internal implementation team picks up the new stuff and starts incorporating into their projects. During this same week, we were pleased to see our folks schedule a huddle to share some early tips and best practices with each other - a true indication that we had delivered something of value. 

I invited the Product team to listen in on the discussion and together we basked in the indirect validation as we heard stories about how the new features would ultimately make their jobs easier and deliver better value for our customers.

I celebrated the win with the Product team over a nice lunch (which I ultimately turned it into a working lunch to conduct a customer journey mapping exercise - ha!)

The impact

You don't need always need to celebrate with free food, but I have found that people do like to feel appreciated. Our teams have certainly responded to the positive reinforcement and I will continue to keep an eye out for opportunities to share good tidings.  

Look for more reports from theProductPath around product culture, product feedback, and validating products here on PM Decisions.

More articles from our blog PM Decisions

Brainstorm a product solution for customers

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

After collecting far too many stories about how customers had resorted to stitching together different parts of our product to solve the same problem, I decided to regroup with the extended product team to revisit how we might address the actual needs of our users. 

I can measure the age of some of our primary product components in terms of years. This has positive and negative implications. On the plus side, I have a wealth of real-world application to draw upon as generations of users have been recording feedback with us about what is and isn't working (it is not uncommon for us to work with multiple Administrators at the same company due to turnover). All this input gives the team and I a wealth of information to sift through to find patterns of use.

On the other hand, I now also have both a significantly hardened code base that is more difficult to change and a larger user base that would be affected by any serious product revisions.

What drove this decision

I first started seeing the patterns emerge when I was embedded with the Sales Engineering team. Customers were asking for a way to start the same business process from two different points. We had built a tool specifically to accommodate the first case but unfortunately, to address the other starting point, we and ultimately our customers, were forced to reach for an alternative component.

Administrators found that configuring this second approach was harder but what's worse is that the resulting activity provided a completely dissimilar end user experience!

When I spoke with our Professional Services team who often assist new customers with their initial implementation, I confirmed that this was a common scenario and there was indeed pent up demand for a better solution.

The decision: Go back to the drawing (white-) board to review this prominent customer use case and find a more suitable way to solve this for our users. 

I didn't feel like we needed to start with a blank page. After all, our customers had all found a way to make our software work and many of them had taken the exact same approach to get there. What was bothering me was that we hadn't given them an obvious solution path and more importantly, the end user experience was disjoint and reflected poorly on the product. 

By gathering in one place the sharpest minds from each relevant department in our company, I would have an opportunity to apply some good, creative thinking to the problem. But leading a group discussion like this, especially with multi-disciplinary lineup would require some planning and coordination.   

Plan of attack

I had been gathering details around this problem for months, and so I set about reviewing my notes to create some initial hypotheses. I poured through my notebooks, Jira stories, customer interviews, and related research to organize my thoughts.

In the end, I had some solid starting points for the discussion but stopped well short of outlining a final solution for fear of stifling the creative process.

Prep ahead of time to streamline the conversation

I had some presumptions for how I thought (hoped?) the brainstorming conversation would go. The day before, I stayed after work and put some initial thoughts on a big whiteboard. My intent was to use this as a backdrop for the dialogue.

In my experience, I have found that it is much easier to get people talking when they already have something to bounce ideas off of even if the starting material is somewhat inaccurate or incomplete. 

Assemble a good quorum

I was genuinely interested in securing multiple points of view, but I also wanted to cover my bases so that the outcome could be vetted by all interested stakeholders. To that end, I invited participants from Engineering, UX, and Product as well as from Sales and Professional Services.

The latter was crucial for validating and clarifying the customers' challenges. The former ultimately helped me discover a product solution that was feasible and usable.

Have open-ended questions ready

Brainstorming often works better when there is some amount of prompting involved. I had already planned to facilitate but in a larger group, it can take actual prodding to make sure everyone's voice is heard. I prepared questions, some technical and others around usefulness, to provide sufficient opportunities to participate.

Even if I had already known the answers to the questions, I would still have incorporated them as collaboration tactics to get the ideas flowing and to promote a healthy discourse.

Stay on topic

Brainstorm sessions are expected to wander a bit which can actually encourage involvement and inspiration. But I had scheduled a short meeting so I also had to make sure I got what I needed from the group to be able to move forward. The trick was to limit the number and scope of conversation topics.

I started with a clear topic outline and stated what I needed the group to help me achieve. A few times I had to gently steer the discussion to get it back on track or to park issues that would have derailed us or sapped valuable minutes.

The impact

My meeting of the minds was ultimately a success. We confirmed several of the core hypotheses and as a result, I was able to proceed with my product planning. I was also pleased to have several new ideas enter the mix as well. In fact, there was one outcome in particular that I did not anticipate and that ultimately proved to simplify the resulting solution.

The approach I described here is a more formal approach to brainstorming, but it worked well given my constraints. With a bit more preparation up front and some lightweight oversight for the actual discussion, I was able to achieve positive results in a relatively short period of time.

Look for more reports from theProductPath around product strategy and product culture 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

Conduct high-priority product research

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

To address one of the most critical problem areas for customers using our software platform, I decided to roll up my sleeves and conduct the fieldwork myself.

For many months, we had been recording feedback from our customers, some direct, some indirect around one particular area of the product. Everyone agreed that we had delivered really powerful features - the common challenge was in the setup and configuration. We had made it too complex to use this valuable piece of the product! 

I couldn’t agree more. I knew how hard it was, even for more technical users to configure the tools. I have a deep programming background but even I would struggle trying to ramp up on proprietary schemas with cryptic configuration syntax and poor documentation.

We had been attempting to compensate and even head off frustrated customers by offering to have our own Professional Services team help get customers up and running. But that only served to delay the inevitable as the complaints would then change to “even if you build it for me the first time, I’m not confident I can take it over and maintain it!"

What drove this decision

I had been anticipating a suitable window of time where we could focus on revisiting and rethinking these problems. The teams had been making good progress on some of the pre-requisite components that would be leveraged to rebuild this key feature of our platform. It was time to initiate a round of interviews with customers about how they use the current product, what (if anything) they liked about it and what (again, if anything) they could point to that causes problems for them or their end users.

I wanted to take full advantage of this opportunity to get out of the building, to speak directly to users and reinforce this important research activity with the members of my Product team. Mostly though, I wanted to improve our product and make our customers happy.

The decision: Enlist the help of our User Research expert to coordinate formal interviews with a suitable group of administrators and end users from our active customer base.  

I am fortunate to have a talented resource on our team who has raised the bar around user research for our entire company. She continues to guide us all on the finer points of interviewing users early on around product discovery and later on for product usefulness and usability. With her by my side, I felt very confident that we would get to the crux of the problems and ultimately, be able to prioritize the work to come.

While I was eager to get started and optimistic about what we would learn, I heeded my colleague’s advice and adhered to the plan we made to ensure a favorable outcome.

Plan of attack

It was so tempting to just start writing requirements. But I've been wrong before.

I have used our product internally and I have also demoed it hundreds of times to customers so I felt confident that I knew what was wrong and what would need to be fixed. It was so tempting to just start writing requirements.

But I’ve been wrong before. Let me say that again, I’ve been wrong before. I have felt strongly about how our product should work and went straight to the Engineers with requirements only to find out, after they had spent valuable time implementing the stories that there were no customers lined up to use the new enhancements.

Start with hypotheses and a good prototype

Because I was so familiar with this particular part of our platform, I was able to quickly compose a lengthy list of hypotheses of pain points where I would expect to hear complaints from both heavy and casual users:

• We believe Admins are struggling to initially configure a URL to set up a new instance of [tool] in environments like Salesforce.com.
• We believe end users are frustrated with the number of clicks required to complete the ... process, especially if only one document is necessary.
• We believe Admins are resisting adopting and expanding their use of [tool] because it lacks good error handling, is difficult to test, and has too few options for controlling its behavior for the end user.
• We believe end users struggle with scrolling and otherwise navigating through the different areas of the page, e.g. with long lists of templates or with very long data forms and may find it helpful to track incremental progress as they work through sections of a longer form.
• We believe end users are underwhelmed with the stark layout of the [tool] page, the lack of branding, and the lack of any help text.
• We believe end users struggle with using the [tool] with different browser window sizes, specifically when the buttons move around when the page is resized.
• ... 

I then had the UX team mock up a clickable prototype that addressed some of the primary concerns and that would allow us to better engage with our interviewees.  

Recruit and track participants

To build a list of participants, I first reviewed the customers who were already part of our formal “labs” program (always be recruiting!). Then, I put the word out to our Sales and Professional Services teams to identify other viable customers with whom we could talk. The resulting list was manageable enough for us to track using a shared spreadsheet that included contact information, interview dates, and miscellaneous notes.

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

Contact Names	Organization	Preferred Phone/Email	Participation	Last Contact Date	Future Participation	Primary Internal Contact	Notes
Nellie Bluth	The Bluth Company	nbluth@thebluths.com	Asked to be included in Fall research initiatives	7/12/15	Also willing to help with...	Maggie Lyes, Acct Mgr	Has been helpful in the past but admits to not being technical

Conduct and record the interviews

When we had accumulated a sufficient list of suitable users, I crafted and sent out an email invite along these lines:

“Hello Vincenzo, I would like to enlist your help for a product research initiative.

I head up the Product team and am leading an active project to learn more about how customers are using our tools. I am reaching out to you because your group is currently using [tool]. I believe you would be able to provide some great feedback on what is and isn’t working well.

If you are interested in participating, the next steps are easy:

1 - Reply to this email with some available interview times over the next 2-3 weeks.
For example, “Tuesday mornings are better”, “tomorrow”, “Wed/Thurs between 3-5pm Pacific”.

2 - Prepare to walk us through how you or your end users use [tool] today

This is a great opportunity to tell us about your successes with [tool] as well as things that would make it easier for you. The conversation should not take more than 45 minutes.”

Not surprisingly, our more fervent users responded immediately. With the others, it sometimes took a little more effort to secure the interviews. We mostly used virtual web meetings to conduct and record the interviews where the customer did most of the driving while we watched.

Our agenda for the interviews followed this path:

1. Show us how you use the product today [50% of the interview time was spent here]
2. As an [administrator, end user], what would you say if anything, are your favorite things about [tool]? [10%]
3. What, if anything causes you or your users problems when using [tool]? [20%]
4. Switching gears, we'd like to show you our ideas for a new design... [20%]

I had an intern transcribe notes from the recordings, putting all the material in a central repository so we could index it properly and share it with the rest of Product and Engineering.

The impact

The customer interviews went smoothly giving me exactly what I had hoped to obtain. There was plenty of validation around our current shortcomings, some surprises about certain attributes that users found valuable, and an abundance of constructive griping. The early prototype seemed to be a hit with users and gave me additional confidence to pursue that path.

I expect to deliver a first round of product improvements in the very next release and will continue to engage these customers to validate our efforts.  Look for more reports from theProductPath around customer research, product validation, and feature prioritization here on PM Decisions.

More articles from our blog PM Decisions

Respond to unhappy customers

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

To learn more about post-purchase sentiment, I decided to engage with our Customer Success team and become more aware of where our users were struggling.

I will admit that my Product team and I tend to spend more time interviewing and talking with amicable customers. That is not to say that we only approach our happy users; in fact, a fair number of the research-oriented conversations have been tempestuous. Indeed, through our collective research efforts over the past year, we have collected quite a bit of product feedback that would land well on the other side of "needs improvement".

But in this exercise, I wanted to turn my attention specifically to customers who were in peril. And I wanted to go straight to the front lines.

What drove this decision

In addition to what we were learning from the interviews we had been conducting with customers and prospects around new features and enhancements, I also wanted to know more about our product's pain points. And I thought that a great way to do that was to talk with customers who were currently lodging their complaints with our Support team.

The decision: Carve out time to listen to and understand some of the problems customers were having with our product and to help identify ways to address each distinct concern.

In span of a single week, I was able to participate in three separate support cases. I got a chance to hear, in some cases first-hand, from customers who had legitimate complaints about:

1. An unacceptable implementation scenario
2. An (unintentional) product feature gap
3. A grueling Administrator on-boarding experience

These scenarios afforded me with a good cross-section of problems to explore. One was griping about our product's inability to satisfy their complex security problem. Another had caught a change we had made in a recent release that legitimately "broke" one of their use cases. And a third was trudging through our formal training course and was beginning to grasp all that he would ultimately have to learn to support his own company's solution.

Plan of attack

I was intrigued to have three customers with three very different concerns. My process for each was similar however. I spoke with Customer Success person who was interfacing directly with the users, tried my best to assess the particular situation and made sure I understood each customer's own challenge. 

In the end, I helped to resolve each situation but with three very different outcomes.

Scenario 1 - "Fire" a customer for which there was truly no fit

My first conversation revolved around a newer customer who had been planning to go live with their implementation in the next few weeks. In working through their initial project, however, they had determined that they needed a much more sophisticated security scheme and were now struggling with that part of our platform.

It did not take me long to recognize we were at an impasse.

Somewhere along the way, we had clearly misled this particular customer. We had since exhausted all the obvious and even more creative options and I confirmed that we would not be otherwise enhancing the product to support their unique use case.

It did not take me long to recognize we were at an impasse. Looking to quickly resolve the situation, we made the tough decision to rip up the customer's contract and return their money.

Scenario 2 - Escalate a support ticket regarding a product oversight

My next conversation was much different. Here a long-time customer had submitted a complaint with our Support team about a small feature that was removed in a recent product release. It was clear to me that we screwed up.

It was clear to me that we had screwed up.

After hearing their scenario, I agreed and admitted that we had inadvertently taken away a small piece of functionality that they had been relying on. I recommended that we escalate the Support ticket to trigger a feature enhancement request that would bring back comparable functionality to help restore their solution.

Scenario 3 - Meet face-to-face with an overwrought Administrator

And finally, toward the end of the week, I was made aware of another new customer who had been floundering a bit. The designated "administrator" at this company, who was in charge of making it all work was currently enrolled in our (highly recommended) training class to learn the ins and outs of our software but was laboring under the breadth and depth of the course material.

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

In truth, the original implementation project was poorly scoped and was running over budget. It was clear that more time would be needed to complete the work. But the Administrator was becoming even more unsure about his ability to ultimately support his own company's users when the solution was finally deployed.

I scheduled an hour meeting with him after the training class (we actually talked for more than 90 minutes) and listened to his concerns. After some healthy venting, he ultimately agreed that none of his immediate doubts were tied to the platform itself. Instead we decided to revisit the original statement of work and work with Sales and Professional Services to properly expand the scope of the project to fit his organization's needs.

The impact

Looking back, I am not sure if my products are better off as a result of these interactions. At the end of the week, I had been engaged in three unique customer scenarios and delivered three different resolutions:

1. Defend the product, even if it meant losing revenue and risking our reputation
2. Admit our product mistakes and try to earn back the customer's trust
3. Reset a (new) customer's product expectations and help them find a successful path forward

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

More articles from our blog PM Decisions