Write the Release Notes

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

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

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

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

What drove this decision

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

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

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

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

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

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

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

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

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

Plan of attack

We generally organizes topics in our Release Notes like this:

TABLE OF CONTENTS

About the Release Notes

Release Overview

End of Life Announcements

Enhancements

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

Known Issues

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

Internal first, then external version

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

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

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

More than just an enhancement list

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

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

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

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

Updates to primary customer narrative

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

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

The impact

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

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

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

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

More articles from our blog PM Decisions

Sit with customers for product training

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

In yet another attempt to get out of the building and sit face to face with my customers, I decided to grab a seat in the next customer training session.

Product Managers, of any rank, need to get to know their end users. You don't get to hide behind a fancy senior-type title to avoid the difficult and often humbling experience of interacting with the people who buy and use your products.

But it can be more challenging for the Product Head Honcho to carve off blocks of time to sit with customers because the role has so many other responsibilities.

What drove this decision

In the back of my mind, I knew it had been too long since I had had any real interaction with our users. For months, I had been relying on solid, but second-hand input from my Product team to help drive roadmap decisions but I very much wanted to supplement that with my own data points.

Some weeks back I learned that the company had scheduled the next multi-day training class for customers and partners. I knew that would be a decent opportunity to step away from the office and spend some quality time with my target audience.

The decision: Spend most of the class in listen-only mode while also weaving in some interactive, product-focused discussions. 

Our customer training course is a week long affair and operates on a fairly tight schedule because of the range of functionality we cover to address a rather broad set of use cases. As such, I would not be able to carve off big blocks of time to do proper customer interviews. So rather than hijack the agenda, I looked for other windows of time for both formal and informal interactions with the attendees.

I made it my goal to bring back new product insights to my team and to learn as much as I could about both our existing and future product direction.

Plan of attack

You don't get to hide behind a fancy senior-type title to avoid the difficult and often humbling experience of interacting with the people who buy and use your products.

As I mentioned, the training agenda is tight so I would be squeezing in opportunities here and there to cover my own topics. To kick things off, I gave the standard welcome speech on the morning of the first day and wove in my parallel agenda as we covered the week's schedule.

I teased the audience by inviting them to attend a "working lunch" where I would deliver a live overview of new enhancements that were part of the major release that had just been pushed the week before.

I also proposed that we gather before class on one of the days to preview some of the exciting ideas we were brewing up in our Research Lab. This would be a unique opportunity for me to pick their collective brain and for them to help steer the products themselves.

And finally, I encouraged anyone looking for 1 on 1 time to track me down during the regular breaks to talk about any specific topics.

Emphasize the value of feedback from customers

View fullsize

Product roadmaps must balance inputs from many sources. (Click to enlarge)

In every interaction, I tried to stress how important it was for me and my team to hear from our users. I talked about the different options they could utilize for passing back their concerns, suggestions, and praise (ha!).

I was careful, however, not to set the expectation that we would act on every input. I showed a product-centric chart that I use to educate/remind both external and internal audiences of the complications of owning a product - specifically that the inputs are many and the available resources are finite. 

Spotlight product updates based on voice of the customer

To reinforce those messages, I queued up some of the new product features and enhancements we had delivered over the past few releases that were largely driven by customer feedback. I talked about how early interviews had revealed common pain points across customer implementations. And I showed how, through constant validation with end users, we had been able to advance the product to address their requirements.

Recruit end users and administrators for future R&D

Always be recruiting. That could be the slogan for our research team - and they never let me forget it. So I also put in a few plugs for our ongoing R&D initiatives. Passing out business cards is easy but somewhat impersonal so I also followed up with an email to all the participants.

The impact

I did gather some good product feedback from the group, some of it unsolicited and some of it through more formal discussions. I would recommend opportunities like this to other Product Managers looking to spend quality time with a captive audience.

The class participants seemed appreciative as well. They had positive reactions to the connections I made between customer feedback and product innovation. There also seemed to value having a direct line to the company's Head of Products, if only for a short period of time.

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

More articles from our blog PM Decisions

Unveil new product at company event

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

In recognizing the work that all the departmental teams had contributed to create this novel product, I decided to orchestrate a group presentation to roll out the new offering to the entire company.

I really enjoy our Release Previews. These are monthly get-togethers I created to have the Product team demonstrate, to the entire company, the latest, shippable product updates and enhancements. These meetings are intentionally distinct from the less formal Sprint Review, typically led by and targeted at Engineers.

That is not to say that Engineers are not part of the Release Preview - actually they are often featured as we are showing off their handiwork in most cases. But the broader messages we deliver to the company at the Release Preview are more value-driven, as in what value are these updates going to provide to our customers and to our own business?

We all know it takes a coordinated effort to build and release new products. During the Release Preview, I try to make sure we recognize everyone who contributes to our incremental progress and that goes well beyond Product and Engineering. But this was not our standard release.

This was the official launch of our new Reference App.

What drove this decision

This was a major achievement for our company and I wanted this particular Release Preview to stand out from the rest. After many months of planning, development, testing, and customer validation, we were ready to unveil a unique new offering that would differentiate our company - and it was important to me and the team that everyone in the company appreciate the collective accomplishment.

The decision: Preview the new product in a group setting where each department contributes to the larger story.

More important than getting everyone up to speed on and pumped up about the new product, I wanted them to all to understand and appreciate the work that all of us had done to make it a reality. We had shown prototypes of the product many months ago and despite small, periodic updates, many in the company had all but forgotten about it.

In the reminder email I sent to the company days before the event, I emphasized how this particular Release Preview was going to be an extravaganza. Now it was time to put together a presentation that lived up to the hype.

Plan of attack

The highlight of our Release Previews are most certainly the product demonstrations. But as I mentioned before, we are very prudent about wrapping those demonstrations with stories about the value that is ultimately delivered to the end customer. This presentation would be no different but the story would be larger and all-inclusive.

Recount How we gOt here

To start things off, I asked our head of Research to provide the back story. This app came out of one of the best customer research initiatives we had ever run and I couldn't think of a better way to set the stage. Straight from our customers' mouths, we heard about the struggles they had been having with our platform. Over and over, we were told the same thing - you have to give us more visibility into what's going on.

We listened, we prototyped and we validated. The reason I felt so confident in this presentation - and in this new product - was because it was practically dictated to us by our end users. 

Get representatives from each department to contribute their parts of the story

Then, one by one, I had representatives from each department stand up and speak to other facets of the product.

Professional Services described the lengths they would go to just to provide a makeshift remedy to the customer's visibility problem.

Engineering and Ops took turns talking about the speed at which we would be able to deliver updates to the product and how much our entire deployment had improved as a result of launching this app.

UX gushed about how the new app leveraged a recently developed component library and how it help to launch a new UI paradigm for the company.

Sales and Marketing weighed in with the overwhelmingly positive response they were getting from the early previews we had been sharing with prospects and customers.

And so on. By assigning each of them a dedicated speaking role and by giving all the contributions equal weighting, I was able to relate a shared victory for everyone.

GET THE CEO TO WRAP IT ALL UP WITH A ROUSING FINISH

I would have been happy enough with just the departmental contributions, but to end on an even higher note, I asked our CEO to supply his own thoughts on our newest product. In a brief but stirring, unrehearsed speech, he shared his appreciation for all our hard work and for the company-wide commitment to product innovation.

It was well-received by all. 

The impact

To say the Release Preview went well would be an understatement. We had the largest employee turnout ever for an event like this and I received a great deal of positive feedback afterwards. One of the recurring messages was that we might want to reserve additional, spillover conference rooms in the future to accommodate more of our folks in the office!

I thanked all the speakers individually for their participation and gently reminded them that we still had more work to do to make the official launch a success. At the end of the day, with all the solidarity we generated, I couldn't help but feel that success was, if not inevitable, then certainly more attainable.

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

More articles from our blog PM Decisions

Clarify win-loss speculation with post-mortem interviews

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

After yet another desperate claim from an exasperated Sales team that we were losing deals because of presumed product gaps, I decided that I needed hear it first hand from the customers.

I look forward to the days when I can sit with our Sales team on a regular basis (at least quarterly) and formally walk through our wins and losses. I say this somewhat selfishly because I have seen our company overreact repeatedly to lost deals. There is a tendency to find scapegoats and Product is often an easy target.

I know we have sufficient features with clear benefits to close new deals (our win rate is actually pretty high) but it still stings when a customer chooses a competitor. Nobody likes to lose but we need to reflect on these events in a productive way. We need to be truthful with ourselves and learn from our losses.

What drove this decision

A battle was already brewing between Sales and Product around a set of "must-have features" that had been distracting me from the real roadmap priorities.

In fact, I had been cornered a number of times over the past few months, typically by a Sales manager stomping around the office, still sore after getting the bad news that we lost another opportunity.

But warning bells were going off for me after hearing what seemed like unfounded claims that the deal fell apart because our product fell short in a certain area. I was especially curious about one deal in particular which we apparently lost to a couple of vendors with whom we never compete.

Something didn't make sense about these claims and I wanted to reconcile my own hunches with those coming out of Sales.

The decision: Schedule discussions with the lost prospects to learn more about their exact decision criteria.

The Sales team has been winning and losing deals for a long time but aside from our Reps recording one of a dozen pre-defined "reasons" in our CRM, the team had never spent any cycles capturing the details of the sale - and certainly had not been sharing the broader stories in a broader venue.

Our best opportunity to circle back with a lost prospect would have to be soon after they told the bad news. We had 2 such losses in the past 2 weeks and I scrambled with the Sales team to set up separate calls with each prospect to get the rest of the story, from their own mouths.  

Plan of attack

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

My suspicion in both cases was that my Sales team had misinterpreted the customer's needs. In both cases, our folks had assumed that it had been a particular feature or set of related features that our competitor offers that had been the deciding factor. I was skeptical, but mostly because I didn't think our Sales team had a complete grasp of the other offering and were being hasty to find a scapegoat.

We scheduled conversations with each prospect and I had the Rep and their Sales manager sit in, mostly to listen. I shared my hypotheses with the Sales folks up front - specifically that I thought we would ultimately get feedback from the customer that was different from the conclusions they had drawn.

I also made it clear to them that I was motivated by a desire to learn and had no intention to lead our witnesses. 

Interview 1st prospect about competitor's tool

We had been hearing more and more about one particular competitor product in our sales cycles. They (the competitor) knew we didn't have an answer to it and wisely used their own product as a land mine to trip us up. I don't want to take anything away from our competitor but it was clear that they were intentionally guiding prospects to focus on this tool even when the prospect wasn't struggling with the set of problems it solved.

I've seen the tool and it does provide some attractive features. Until recently, we had been assuming that 1 feature in particular was winning over prospects. But the deal notes from our own Sales Rep on this opportunity pointed to something else.

We learned that our assumptions were wrong - the customer was struggling with a completely different problem.

In a 20-minute conversation with the prospect, we walked through their decision process and ultimately came to the competitor's offering. When prompted to identify the actual pain points and how well the competitor's tool matched up with those pain points, we learned that our assumptions were wrong - the customer was struggling with a completely different problem.

After thanking the prospect, I reviewed the outcome of the call, as gently as I could, with the Sales team to make sure they understood the real criteria of the customer's decision. The new information was indeed valuable and we would have to incorporate the findings into our own product strategy but it was also important to set expectations appropriately inside the company so as not to unnecessarily exaggerate our presumed product gaps. 

Interview 2nd prospect about broader needs

The second opportunity was apparently lost to vendors that we never see in our typical sales cycle. That seemed to me to point to a fundamental misunderstanding about what problems that customer is looking to solve.

We ran through a similar post-mortem conversation with this prospect who was all too happy to share their issues again. I find it easy to start conversations with decision makers around their pain and struggles. And even though our Sales team had just spent weeks courting them, they approached this new conversation with our Product team with unexpected enthusiasm.

Our Sales team had clearly wasted way too many cycles chasing an unqualified opportunity AND had drawn unnecessary attention to a presumed product gap.

Since this customer had not yet made a final decision, we steered the discussion to what had separated us from the remaining vendors. What I heard was at the same time validating and frustrating. The customer had legitimate needs but ones that would never be solved by the type of solution we had to offer.

The good news for me was that this lost deal was not going to impact our own ongoing product decisions. The bad news was that our Sales team had clearly wasted way too many cycles chasing an unqualified opportunity AND had drawn unnecessary attention to a presumed product gap.

The impact

Both prospects were not only willing to share with us but actually quite impressed that we would take the time to learn from our lost deals. I would like to think that this customer feedback will only accelerate our plans to formalize our win-loss analysis discussions in the months ahead.

I'm also hopeful that our Sales team will start to acknowledge that they sometimes misread the prospect's ultimate decision and will refrain from rushing to hasty conclusions. Perhaps only time and ultimately, more losses will tell.

Look for more reports from theProductPath around voice of the customer, competitive analysis, and managing stakeholders here on PM Decisions.

More articles from our blog PM Decisions

Recalibrate product priorities for the next 6 months

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

As we approached the half-year mark, I recognized that I needed to regroup with my internal stakeholders to make adjustments around what we would be delivering for the second half of the year.

You could argue that the half-way point through a calendar year is a somewhat arbitrary juncture, but nevertheless it provided me with a good checkpoint opportunity. Since the beginning of the year, my team had planned, built, tested and delivered product updates through several releases. Before we commenced with the next cycle, I wanted to revisit our priorities and review any significant changes in the business that would require some course correction in the product roadmap.

What drove this decision

I was confident that the Product team had been addressing the full range of demands and that we would continue to balance stakeholders' priorities as we were all committed to satisfying our end customers' needs.

We had already begun to carve out big plans for the next 6-9 months and some of them would require significant investment. I knew we were aligned with individual departments but over time, the various department heads had lost sight of what was most urgent for their peers. It would be more difficult for me to deliver and promote an updated product roadmap without some preliminary group consensus at the topmost level.

The decision: Organize and facilitate a product strategy summit with all the department leaders to revisit and rebalance priorities.

I will be the first to admit that the word "summit" sounds a bit lofty (pun intended) but I assure you this was not some trumped up, off site boondoggle - I'm saving that for my big end of year 1st Annual Product Strategy Retreat.

My goal was simply to get all the department VPs and some key Directors in the same room and run through a formal, Product-focused agenda. I wanted to use the time to review the roadmap choices we had made over the last 6 months (some good, some bad) and continue to push the company to pursue sound product investment decisions.

Balancing 3 related concerns: curb appeal, interior living space, and structural foundation 

In the many discussions I had been having with the different departments leading up to this summit, it became increasingly clear that there was a lack of mutual appreciation, if not basic understanding of what was driving the other departments' priorities. A number of the stakeholders were out of touch.

I wanted to share this insight with the invitees but in a way that didn't offend or alienate a particular group. In the summit invite, I offered the following apartment building metaphor to help explain the different, but complementary perspectives of each group:

Image sources: http://tinyurl.com/nbzkcoz, http://tinyurl.com/pno7n9f

• Sales wants the building to have massive curb appeal, to look good from the outside so as to increase the chances of attracting new customers.
• Customer Success wants all our new tenants to have a smooth move-in experience and to enjoy living in their new home for many years.
• Operations wants to make sure the building itself can safely support all the tenants and their various housing needs.

And of course everyone in the organization should be focused on increasing customer satisfaction as it will lead to renewals and referrals!

Plan of attack

Setting proper expectations: everybody wins! everyone loses!

I started the meeting by setting expectations for the group - which largely meant telling them that no one was going to get everything they wanted. The summit was an exercise rooted in compromise. I told them that it was equally important for them to defend their own priorities as it was to become more aware of what the other departments were struggling with.

The bulk of our time in the summit was spent prioritizing a lengthy list of wish list items. To kick things off, though, I offered an assessment of the past six months to remind everyone why we built the things we did and to get some feedback.

Review the roadmap themes for the year

I first presented the product strategy I had introduced at the beginning of the year that outlined how I would be making decisions for the next 12 months. Specifically, I highlighted the roadmap themes that were established back then and verified with the group that we were still confident in those decision-making guidelines.   

Review 1st six months

Building on the initial validation from the group, I proceeded to show how the recent product decisions we had made were in line with the roadmap themes. This brief, high level review of the advancements we had made in our product portfolio over the past 6 months provided an ideal opportunity to explore queries such as:

• How accurate was the original plan and how close did we come to hitting our targets/metrics?
• Are the major initiatives still on track or have there been new insights that require us to adjust our course?
• What have we learned about estimating work, about dependencies, about our ability to accurately respond to customer demand?

I was certainly pleased to hear the group confirm that the first half of the year was largely productive and that we had been made solid product investment decisions.

First pass at prioritization

From the Trello board I created to capture individual wish lists for the different departments, I pulled the top 30-40 cards to start the prioritization exercise. The first step was to bucket the items into either one of only two lists: High Priority or Low Priority.

This first pass proved to be relatively easy for the group. I was pleased to see the Low Priority list ultimately accumulate many more cards which meant the final pass would be that much easier.

Overall, it was a constructive discussion. None of the participants were particularly unreasonable and did not fight excessively for their own items.  I did occasionally use the following prompt when we seemed to be getting stuck: "Can we get through the second half of the year without spending any time on this item?" That was often the only nudging that was required to properly bucket the topic.     

Crash course on product constraints

I had prepared a break in the summit schedule in case we needed a cooling off period - and intentionally scheduled the catered lunch to arrive during the break. It turned out there hadn't been that much contention so I instead used the break to revisit some of our constraints and to remind the group about why the next half of the exercise was going to be frustrating for all. Specifically, I talked briefly about the following topics:

• Our true development capacity - what we should really expect from the current size and skill level of our Engineering teams. Read more about setting expectations around Engineering capacity here.
• Software's total cost of ownership - how each line of code we add requires more of our company's resources from Product, Engineering and QA all the way through documentation, support, and training.
• Opportunity costs - each time we agree to start building something new, we must recognize how that will limit our ability to respond to the next "must have" requirement (yeah Sales, I'm talking to you!)

I can't be sure if all the messages landed on point with the entire group but it was my meeting and I was going to take advantage of this ideal product soapbox opportunity.  

Final pass at prioritization

In the home stretch, the group now turned its attention to reviewing the much shorter High Priority list (14 items, down from 40). One by one, I went around the table to get individual input. I guided the group by having each of them select 1 primary item and 1-2 backup items.

When we had finished the final pass, we had arrived at a prioritization list that had mutual support from all departments. And I had a clear indication of how I would be adjusting the Product Roadmap for the second half of the year.

The impact

Not only did we finish the full exercise (on time no less) with a shared prioritization list but I was told afterwards by the group members that it was one of the more amicable and productive meetings around product direction in which they had participated in recent memory.

I made it clear to the group that the summit was not designed to immediately produce a new or updated roadmap. It would take me more time to work through the items on the High Priority list and factor everything into the Product Roadmap for the second half of the year. Still, I would like to believe the outcome of the summit extended beyond achieving consensus around particular product priorities. I think it represented a milestone for advancing inter-departmental agreement. Maybe next time, I'll refer to it as a Product Peace Accord.

Look for more reports from theProductPath around feature prioritization, product strategy, and managing stakeholders here on PM Decisions.

More articles from our blog PM Decisions

Cut down the scope of the initial product by 20%

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

After receiving push back from users in the first rounds of testing, this startup decided to eliminate a significant portion of its product offering.

For the past year, I have been observing the early stages of new business, started here in Chicago. The technical co-founder, a close friend, has also been serving as the Head of Product, not uncommon for small companies. I have been keenly interested to watch how this team would bring their vision to market and all the twists and turns that path would take.

One interesting development occurred after they put their initial version of the product in front of their target users. The feedback was immediate and in my opinion, quite sobering. The team would seem to have gone too far in one direction and was now facing a critical decision to scale back the initial scope of its product.   

What drove this decision

“This is too hard. I don’t want to create more work for myself or my client.”

— Early prospects

The originally envisioned product was intended to utilize a 3-step process. Users would complete a high-level questionnaire followed by a more detailed assessment to produce a curated product catalog where they could then make purchases in a familiar e-commerce scenario.

After developing a reasonable first pass at each of these components, the team put the product in front of a sample set of target users. The feedback was prompt and to the point: this is too hard.

The team had to make a change.

The decision: Drop an entire section of the user workflow

The (initial) users had spoken. The workflow had to change. It had to be simpler to complete. This startup team needed to step back and review the customer flow.

Plan of attack

The team ultimately decided to refactor the 3 step process and eliminate 1 of the questionnaires. After that, it would be time to test again:

• How would the new process change the results?
• Was there still a clear path to the purchase?
• What would the users find challenging about the new workflow?

Rethink the customer flow

The refactoring exercise began by decomposing the workflow process into finer grained steps, then exploring alternative paths for leading the user to the product registry at the end. The team focused on keeping what was needed most and trimming away the rest.

Redeploy the process with 1 fewer components

Having established the revised flow, the team proceeded to put the pieces back together to create a more streamlined activity for the users. The objective: a simpler process with fewer steps that produced the desired outcome.

Image source: https://www.flickr.com/photos/mmetcalfe/3874486791

Retest with users

Armed with an updated and improved product, the team scheduled the next round of user testing to validate their work.

The impact

Ultimately the team verified that their users could successfully complete the process without the extra steps. It takes courage to put an unfinished product in front of your customers and even more guts to go back to the drawing board when you get frank criticism.

Removing working code from a brand new product can be hard, especially if you look at the work required to build that code as having been wasteful. But I would argue that learning early leads to less waste. I applaud the startup team and encourage all product-minded people to follow their lead.

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

More articles from our blog PM Decisions

Find a good stopping point for a postponed feature

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

After the principal customer backed off a requested new feature, I decided to quickly wrap up our discovery work.

Large feature requests require more time to plan and necessitate more resources. Collecting and sorting through customer requirements may stretch out over weeks or even months. And once these initiatives get going, they can gather momentum making it more difficult to shelve everything when the team's priorities change.

What drove this decision

One of our largest customer had asked us to help them with a problem that was tied to how they were using our software. It was a new problem for us but one that we felt would likely benefit other customers.

We had acquired a solid list of initial requirements but we knew better than to rely on only 1 source. So the Product team started researching the similar needs of other customers to begin the work of scoping out a new feature.

Not long into this effort, the original customer reprioritized some of its own, internal initiatives. The urgency around this problem diminished and the feature request dropped much further down the list. 

The decision: Suspend ongoing product discovery and shore up the current state of requirements.

I wanted to make sure that if and when the feature came back around, we could resume quickly and regain some of our initial velocity. We had made good headway and I needed to preserve as much of that as I could, especially if a different team would be picking up the feature next time.

Plan of attack

I was confident that the next team to work on the feature should not have to start from scratch. 

Requirements change, technology changes, and priorities certainly change. And I was sure that if we restarted this effort even 2-3 months down the road, we would have to revisit our assumptions. Still, I felt confident that we had been on the right track and wanted to preserve our progress as best I could.

Review the current hypotheses

I started by capturing the hypotheses I had developed around the proposed feature. I made sure to describe the thinking that went into the current hypotheses, to highlight assumptions I was in the middle of testing, and to list some of the ideas I had already ruled out.

Obviously some of these assumptions would - and should - be revisited but the next group would certainly benefit from the validation work I had done for the parts around which I had more confidence. For example, rather than build an entirely new scheduling tool to orchestrate and run a proposed background process, I had intended to leverage one we already had, even if it didn't completely accommodate all of the new requirements.

Create a list of next steps

I was forced to pause in the middle of the feature discovery but I had been working through a rough plan that would have resulted in a path forward. I felt it was important to document that plan, showing where I had left off and where the next team might pick it up and continue. I tried to anticipate and answer questions they might have such as:

• How far into this effort did the previous team get?
• How would they have scoped the work, knowing what they knew at the time?
• What were the dependencies if any that would guide the order of the proposed work?
• Did they identify technology limitations that would have dictated what was feasible at the time?

Preserve the notes in a convenient, accessible place

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

An obvious measure perhaps but I did not want to make it hard for the next team to find my notes. At the moment, our team uses Confluence for capturing early product discovery work. It is hard to believe that we would have moved on to another tool but anything is possible. So I made sure to create prominent links to the repository from Trello, the tool I use to corral Executive input; from Slack, the new tool of choice for our Dev Ops and Customer Support teams;  and in the primary email thread we had been using to communicate with the original customer.

The impact

Part of me feels that there was some wasted effort both in the original work and the steps to wrap it up for a future phase. But that feeling is not as strong as the one that is happy not to have invested even more time building a feature that may have been excessive or unneeded.

With a pay-it-forward mindset, I tried to think about helping the next PM to inherit this feature as I went through these steps. I know I would appreciate someone doing the same for me. And if it is me that opens the product feature time capsule down the road, I promise to be kind to my former self when writing up that experience.

Look for more reports from theProductPath around product teams, feature prioritization, and product investments here on PM Decisions.

More articles from our blog PM Decisions

Head off a new product idea before it gains any more steam

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

In recognizing that a few, excitable executives were intent on charging ahead with plans to build an "answer" to a competitor's product, I stepped in to introduce some rational thought.

I love exploring new product ideas, and that's especially true if those ideas and products are likely to help my company grow while delighting my customers. Brainstorming with other groups in the organization is healthy and I relish deep dive opportunities to learn more about their own struggles. Indeed, we have made some fantastic product breakthroughs over the past few years by collaborating across departments, thinking creatively and rationally about how to improve the business.

This was not lining up to be one of those situations.

As our organization was looking to head up market and seek out larger customer deals, we inevitably began to run into a new set of established vendors. One of these vendors seemed to be getting good traction in the sales process with a distinct feature that was noticeably absent in our own offering. And we quickly became fixated on that feature gap. And by "we" of course, I mean "Sales".

What drove this decision

“We’re getting our butts kicked!”

— Sales team armed with a single-digit data point and still smarting from a recently lost opportunity

Our Sales team was anxious about a particular competitor and quickly became convinced that we had been losing deals - and would continue to lose deals because we lacked a comparable feature in our offering.

What was really missing was actual data to back up these arguments. It is fascinating to watch how quickly a Sales team can work themselves into a frenzy and then how other internal decision makers can get caught up in the hype culminating in an escalating product emergency.

At first, I thought I could just let the frenzy flame out on its own. For surely, if there really was strong customer demand, then I would begin to see more and more frantic sales people banging on my office door. Unfortunately, neither scenario came to pass and so, with not even a little reluctance, I was forced to contain (and ultimately smother) the flames by helping the Sales leaders more formally assess the actual opportunity.

The decision: Get the Exec team to back off their urgent new product ploy

To be clear, I try to never dismiss a product proposal outright and indeed, this particular suggestion seemed to have real merit. What I refuse to do is barrel down a "new product" path without having first made the solid case that the investment has a good chance of producing returns.

You can learn more about the Multi-Tool here. 

At this point, I have to give a big nod to Marty Cagan who in my opinion, best summarized the technique for validating product opportunities in his book Inspired: How to Build Products Customer's Love. I feel so strongly about Cagan's Opportunity Assessment approach that I spent 6 months building a tool that helps Product Managers (and others) both develop and pitch Assessments to stakeholders.

My plan here was to use a simplified version of the Opportunity Assessment to push back on this most recent mania while at the same time, improve the way our management team approaches product decisions.

Plan of attack

My original idea of simply waiting it out and hoping the idea would die on its own, was failing. This became very clear when one of the execs unexpectedly called for a meeting where in just a few hours, we could "hash it out, create some wireframes/mockups that we could then outsource to an external development team". He made it sound so simple but what really concerned me was that no one seemed ready to question the approach. Inaction wasn't working - I needed a new approach.

A PM always has a few tricks up the sleeve to shut down a discussion like this. For example, you could go with "we don't have enough people", or "there are missing dependencies", or "the technology is not ready", etc. But these are short-term tactics. I had to make sure this type of request wouldn't pop up again in some whack-a-mole-style product game.

So, in the spirit of cooperation, I suggested that the assembled team be prepared to start that "hash it out" meeting with the responses to these points.

First make sure we understand the Pain

It all starts with a problem. You have to identify a particular pain you are trying to address and zero in on it. The pain can't be "our competitors have a feature we don't have" - it has to be customer-focused. We are in the business of identifying problems that customers have and will pay us to solve for them. 

Let me start by saying this is harder than it appears. To do this well, you need to be able to separate particular actors from the problem. So instead of saying "Customers want to use their phones to check the status of their transaction", you downplay the user to better highlight the problem: "it is difficult to verify the status of a funds transfer when away from a computer."

Then make sure we understand who has the pain

Note in most cases, you will address the first two points at the same time. I have found it more useful to keep these separate so that you can independently verify that you understand the problem and that you can find the users that struggle with it.

After you've identified the problem, you then nail down exactly who has that problem. Is it college students? Is it college students between the ages of 18 & 20 that live on campus and whose parents deposit money once a month...before the weekend?

The closer you get to identifying a specific persona, the better off you'll be. It will not benefit your team's opportunity assessment if you define your target customer in terms that are too broad, as you will see in the next section.

Is there a real market for a product that solves this 

If I could get the team to first agree on the problem(s) and then, who we believe has that particular problem or problems, then it's all downhill from there. Well, sorta. But we certainly can start to size the available market based on that persona. Sometimes it is easy to back off of an idea early on if you can determine that there really are not enough people to sell the product to. Or that you'll have a very hard time reaching them. Or that the customer's buying process is incompatible with your own sales cycle. And so on. 

Really what I'm hoping to discover of course is whether or not there would be a positive revenue impact as a result of pursuing this product or enhancement. After all, we are asking the company to make a product investment. And smart business leaders should know better than to make investment decisions without some level of due diligence.

The impact

In this particular situation, I was certain that the answers to these (and any remaining) questions would lead to the conclusion that the new product idea was ill-founded. Indeed, we shut down the discussion in short order and went back to more productive work. But the bigger win for me and the Product team was that we had introduced a new tool that would ideally lead to better decision making, at least when it came to new products. 

There are more questions to answer in the Opportunity Assessment (10 questions in Cagan's version) and certainly more than one sequence through the questions. I like starting with the plan outlined above because it is an efficient way to filter out premature and unfeasible product ideas early on.

But is can be used at any time in a product's lifecycle. In taking on the the "Head of Products" role, I inherited a product portfolio that I felt was too much for a company our size to manage. I have since begun the arduous process of reviewing each of our existing products and using the Assessment framework to defend or defeat each one. 

Look for more reports from theProductPath around opportunity assessments, product strategy, and managing stakeholders here on PM Decisions.

More articles from our blog PM Decisions

Assess the Product Portfolio

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

After recognizing that our development team would remain inundated with far too many product requests, I decided to examine our entire collection of products with an eye toward slowing or reversing ongoing product investments.

Like any Product team, we are never in short supply of feature requests, product suggestions, looming technical debt, must-have components, urgent customer pain points, etc. And we do our best to stay on top of the things, trying to keep all parties happy-ish. But over the past few months, I had started to see important product enhancements slipping from each release and was able to attribute those slips to other competing product priorities.

Because there are quite a few moving parts in a typical software development shop, there are any number of places you could start the analysis. Our problems could be related to bad grooming practices, poor scoping efforts, or even an understaffed engineering team. But I know the problems we were having were not limited to a single product or any one PM. It was simply proving too difficult to keep all our balls in the air.

We had launched a generous number of products over the past decade but poking around at the ground level was likely to be an unproductive exercise. I needed a model to help me and our team evaluate decisions across our entire portfolio.

What drove this decision

I was getting anxious about the number of product-related discussions the Management team was having and becoming convinced that they had lost some perspective on what we had already committed to. In fact, there were signs that the company's entire product strategy might be in need of a refresh so I scheduled a mid-year strategy meeting with the management team to do just that. But I felt there was a need to connect the day-to-day challenges we were having with each product release to the product discussions that were happening (at an increasing rate) at the executive level.

I needed to create a backdrop for our high-level product investment decisions that would also drive real benefits at the troop level.

The decision: Create a model for evaluating current and future product portfolio decisions

Over the past decade or so, we had made decisions to create new products and not all of them turned out to be winners - no real surprise I guess. The bigger problem was that we had managed to sell each product to some subset of our customer base so we had an obligation to support it through troubleshooting, bug fixing and occasionally, even enhancement-ing. This obligation grew non-linearly with each new product. 

I knew the customer usage patterns were irregular and more importantly, the revenue we derived per product was inconsistent and unpredictable. Despite this, we had no plans to sunset any of the products thus perpetuating our dilemma indefinitely.

I needed to spark some productive conversation. I needed to shed some light on the impact of our past decisions and try to head off some questionable proposals that were brewing in the company.

Plan of attack

The diagram that I built only needed to be as complex as the audience I was targeting. I felt I could communicate a great deal with coarse-grained data elements, where conclusions could be drawn (no pun intended) by counting boxes or showing the relative size or positioning of boxes. I ended up with something along these lines (pun fully intended):  

View fullsize

Simplified Product Portfolio Model

1 - Plot the products on a simple graph based on revenue vs. customer use

I strongly recommend that you organize your graphs so that the most desirable position is in the top right corner. Both X and Y axes should go from low to high, least to most, etc.

I started by placing each product on the chart based on how much customers were using it and how much revenue it generated. In using these axes, I was hoping my products would be stacked up and to the right. If plotted accurately, it should be easy to defend ongoing and future product investment decisions with this simple graph.

In an attempt to communicate more information with fewer charts, I decided to use the relative size of the product "boxes" as an indicator of our current investments. Without aiming for exactness, I was able to quickly explain where our resources are being deployed. A slightly more complex approach would have been to use other graphical elements to break down the current investment by Product, Engineering, Operations and Support.

2 - Clarify the ratio of Products to Product Resources

Our company currently has more than 15 products in our portfolio and I'm sad to report, not nearly enough Engineers and PMs to manage a portfolio of that size. We have found ourselves in this situation after years of adding new products because at the time, we believed they were crucial to our company's success.

But like many eager, young software companies, we never seem to plan well for the long-term maintenance and support of each new product. I can't help but make the comparison to the decision of adding a new baby to your family.  Everyone thinks it a wonderful idea at first but after spending a number of grueling months bringing it into the world, you find yourself responsible for taking care of another living thing for the rest of your life (or your life at the company at least).

With a few, carefully placed text overlays, I listed on the diagram, the relative sizes of our current teams which revealed the stark truth about our current staffing situation. This helped set the stage for a productive conversation about acquiring more Product/Engineering resources or reducing the size of the product portfolio or both.

3 - Future investment and product goals

I used the same model to spell out some of our short and long term product strategy. With the boxes already arranged on the chart, I added arrows to indicate where we would expect to see movement in the months ahead. Specifically, I predicted the movement of various products over the next 6-12 months in terms of increased/decreased usage and increased/decreased revenue.

By adding a few crude marks over some of the product boxes, I was able to show which products in which I intended to reduce our investment and even more, which I thought we should retire in the months ahead. 

The impact

There are more messages that can be highlighted and communicated in a chart like this. Seeing all the products intelligently placed next to each other on a single page inevitably invites more strategic conversations like:

• Why are we still supporting this product if the usage rate is that low? It's time to retire it.
• When is the last time we updated the technology behind those products? They're due for a refresh.
• How long has it been since we last sold this product? Let's try lowering the price.

Armed with this new model, I was able to drive a strong Product-focused agenda at the Strategy Summit and was even able to successfully head off some premature ideas that could have led us further down the wrong path.

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

More articles from our blog PM Decisions

Evaluate a product integration with a potential partner

Image source: https://www.flickr.com/photos/emanuelec/5869072769

After some considerable prodding from the Sales team to help advance the largest deal in the pipeline, I decided to formally assess the key vendor integration options that could help us win the business.

It is rare that any single product can wholly satisfy a customer's needs and quite common that multiple products will be used in concert to get the job done. Cloud-based products for example, like the one my company offers, are often combined to accomplish set of use cases. Think of opening your Dropbox files in Microsoft Office 365 to make changes. Or pulling Flickr photos into a Slack channel to help the team troubleshoot a problem.

Through an investment in both SOAP and REST APIs, we have made our cloud product open to integration as well. We often point partners (and customers!) to these full-featured web services when we encounter requests for functionality that hasn’t been productized. But since it may be necessary to initiate the integration from our end, we also provide hooks in the platform for outbound calls.

I’ve always been intrigued with software integrations. Part of that interest is derived from exploring the forethought that goes into making any software product extensible and the rest is observing how the combination of two or more products results in a new creation that may never have been seen before.

What drove this decision

Sales was getting anxious - more anxious than usual

We had been salivating over a large opportunity in the sales funnel, a big deal in the hopper - a hit-your-quota kind of transaction. For weeks, the Sales team had been working hard to address the prospect’s long list of requirements and to zero in on the areas where there was lingering concern.

This particular prospect was asking for more functionality than we could - or would ever likely provide. The Sales team was eager to determine whether another vendor could be introduced into the deal (always a risky proposition) to fill the functional gaps.

It was now my job to confirm whether or not this was technically feasible and if so, how it would be done. But in order to have all the parties understand the proposed solution which would likely be unfamiliar and quite technical, I was going to need to explain it with some pretty pictures.

The decision: Create a graphical model highlighting the integration points for the customer's use cases to help validate a new partnership

Diagrams help to communicate with a broader audience 

Joining the conversation late, I needed to orient myself to better understand the other vendor's product. I set up a few phone calls with both the vendor and the prospect, had some internal discussions with the Sales team, and scribbled a lot of notes. When I thought I had a good, initial model, something worth sharing, I polled each of the groups again, passing around a 1-page diagram where I had squeezed some boxes and lines together to create a crude chart.

These early rounds of validation prompted some tweaks to the diagram and I was able to tighten down the overall integration story. What also became clear was that, to make this happen, some non-trivial product investment would be involved on both sides. I knew we would soon be having a number of internal and external “business case” or ROI-type discussions and that the crude chart would not suffice. I decided to step it up and invest in a more robust model.

Plan of attack

My goal with this improved model was to capture and communicate the concepts that would best help with the downstream decision making. This meant not just determining the number of integration points to fulfill the customer's use cases but the relative complexity and level of effort of each, as well. Clarifying to all parties which use cases required which integration scenarios meant that we could better prioritize the relative work involved.

HIGHLIGHT the origin of each integration point

As I reviewed the use cases, I looked for places where the functionality of one of the products ended and where it needed to be picked up in the other product. This made it easy to determine which of the products would initiate a new integration scenario. On the diagram then, I drew uni-directional arrows between systems that are themselves, usually represented as fancy boxes.

I usually label the arrows with numbers or text to help direct the reader to the start of the flow. I also find it valuable to identify the “trigger” itself. For example, “a user clicks the upload button to start the process” or “the process is initiated when a user is added to the address book” or “each new PDF document added to the folder will initiate a call to the other system."

When more than one back and forth call is required to accomplish a particular scenario, the diagram get more interesting. Does the calling application wait for an immediate response (synchronously) or will the reply come back some time later (asynchronously)? What happens when the response never comes back - which party is responsible for resolving the loose ends?

Identify dependencies

In identifying the origins of each integration point, I’ve invariably highlighted new dependencies between the products. Dependencies must be evaluated carefully because changes to the callee’s interface will affect all callers. It is common for Product Teams to update their interfaces (we do it with our own web service interfaces) and must consider backward compatibility to minimize the impact on existing integrations.

For the sake of simplicity and because these would start to clutter up the sample diagram, I’ll skip over the security considerations, the deployment models (e.g. desktop, on premise, private/public cloud, etc.) and any differences in how each company licenses their products.

View fullsize

Sample Integration Diagram

Identify alternatives for each Integration point

As the saying goes, there is more than one way to skin a cat. This can apply to product integrations as well. I always look to indicate any possible alternatives that I discover so that the decision makers can better evaluate the full range of possibilities - even if the alternatives seem less practical at first.

For each alternative, I try to include the relative levels of effort, costs, etc. I usually have a good reason for choosing the primary option so I spell out that rationale for my first choice. Included in the rationale could be viability concerns about the integration technology choices, the types of connection(s) required, overall speed/performance, error handling, etc.

Distinguish between what's available now and in the future

In this particular effort, I learned that some of the integrations would be dependent on features that the other vendor had yet to release. To highlight that important variable, I made special, prominent notes about what would be feasible today vs what was yet to be built to support the integration.

The impact

I delivered the updated, more formal integration model to the teams and continued to participate in the partner discussion for a few more weeks. After both vendors had settled on a viable approach, we jointly presented to the prospect. The additional work to provide an integrated solution was spelled out along with the additional cost, some of which would be subsidized by the vendors. The final proposal, that included a modified version of my diagram, was well-received.

I often create and share models like this to weigh important decisions. I find it easier to grasp the complexity of a proposed solution when you are able to visualize the number of boxes and lines. Unfortunately, a diagram can't always communicate the longer term return on investment of a product integration. It doesn't tell you how many customers will use it or when you can expect sufficient revenue to cover the implementation costs. But that's another article....

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

More articles from our blog PM Decisions