Create a year-end Product progress report

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

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

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

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

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

What drove this decision

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

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

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

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

View fullsize

Simplified customer business process

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

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

Plan of attack

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

Collapse the business process to create a familiar backdrop

View fullsize

Flatten the familiar process for context

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

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

Create a simple scale for relative comparisons

View fullsize

Horizontal lines set up a scale for comparisons

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

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

Plot trajectories for each product initiative

View fullsize

Plot each project as a trajectory

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

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

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

The impact

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

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

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

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

More articles from our blog PM Decisions

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

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

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

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

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

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

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

What drove these decisions

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

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

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

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

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

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

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

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

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

Plan of attack

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

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

Give a product, take a product

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

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

Saying no and saying yes to customers

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

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

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

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

Push and Pull Priorities

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

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

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

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

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

The impact

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

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

More articles from our blog PM Decisions

Convey the Product Vision to outside influencers

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

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

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

What drove this decision

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

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

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

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

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

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

Plan of attack

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

Highlight product advancements to strategic partner

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

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

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

Communicate rate of progress to potential investors

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

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

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

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

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

Demonstrate domain expertise and solid product planning to an unacquainted party

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

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

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

The impact

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

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

More articles from our blog PM Decisions

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

Triage an almost bungled feature upgrade

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

In recognizing that our pre-deployment testing had raised unexpected alarms with some customers and our own Support staff, I decided to straighten out the mess by creating a better feature migration path.

We were winding down the days to our next major product release and I thought the planning had been going well. There are always a number of moving parts in a big deployment and it takes no small bit of coordination across teams to pull off a trouble-free rollout.

One of the big announcements this time around was how we had overhauled one of our more prominent features to make it easier to use. And while we had usage data that showed it wasn't exactly mission critical for our existing customers, we still wanted to ensure a smooth migration.

What drove this decision

The upgrade approach we had planned was simply swapping in the new feature in the place of the old one. Any account that was actively using the old feature would continue to work for the 30 days following the release but after that time, all accounts would be have been automatically switched over.

This seemed straightforward enough and indeed, our internal testing and QA efforts proved that this was a clean transition. Where we went wrong however, was not effectively communicating the plan, especially to our internal stakeholders.

The most obvious blunder was in the Release Notes (I wrote) that we circulate internally, weeks before the go-live date. I had made a copy/paste error using some outdated text and reported the exact opposite intent around this migration! As you might imagine, the Customer Success team freaked out when the old feature "suddenly just disappeared".

All fingers were rightfully pointing back to me and my Product Team. What I thought had been weeks of good planning and internal discussion were negated by what was now a small crisis. I needed a good plan to set things straight.

The decision: Instead of forcing a more immediate upgrade on our users, I would stretch out the feature deprecation period and give customers more time and more autonomy to make the transition.

It is worth clarifying that nothing was indeed broken in any customer account and nothing would break as a result of pushing the new feature in the upcoming release. Actually, I could have tried to smooth over the current unrest and push forward as we had originally planned. After all, no actual customer had experienced any problems in their accounts.

But in this case I chose a more cautious path. Even though it would be more work for our tech teams - actually, it would be re-work since we had already removed the old feature and now had to quickly retest the reverted code - I knew the extra effort to create an extended upgrade period would cost us a lot less than having to soothe any confused or disgruntled customers.

Plan of attack

Patience is a virtue - especially in times of crisis. When the voices are beginning to elevate, when email threads are growing exponentially in a matter of hours, and when emergency meetings are being scheduled first thing in the morning, it helps to be able to keep a calm head.

I would have to calibrate our response based on the actual size of the problem.

One of the things I wanted to make sure was that, in attempting to address the problem, we didn't make things any worse than they were already perceived to be. The key to that, in my opinion, was to properly scope the effort. In short, I would need to be able to calibrate our response based on the actual size of the problem.

Understand the full impact of the change

When we did assemble the interested parties in a meeting room and reviewed the situation, one of the first questions I asked was whether we knew the number of customers/accounts that would be affected by the deprecated feature. My own Product team had gathered some numbers weeks earlier but I wanted to know if we had been off in our estimates.

Because there wasn't enough certainty, I had the Engineers run a new set of exhaustive queries to get our hands around the total affected population. Early totals were supplemented by more thorough search results but all reports showed that the impact was far less significant than the recent hype would have suggested.

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

Call attention to the deprecated feature

With the Engineering team's help, I committed to reinstating the deprecated feature into the product to help affected customers with their inevitable migration. But in doing so, I insisted that we incorporate some blatant visual cues for the end user so they understood that some action was required.

With minimal work, we were able to introduce a glaring design element intended to draw attention to the deprecated feature. This new call to action would be reinforced with other messaging inside the product and externally as well.

Broadcast (better) to internal and external users 

The steps required for a customer to move to the new, improved feature were straightforward and would likely only take a few minutes to complete. However, I have learned the hard way about underestimating users and so, to err on the side of caution, I committed to providing multiple migration artifacts.

I had the Product team scramble to develop new collateral including a 1-page cheat sheet and a short instructional video to help guide customers on the migration process. In both, we explained how the deprecated feature would be disappearing in the subsequent release to be replaced by the improved option available now and we included a recommended course of action to avoid any problems in their account.

The impact

In the post-mortem discussion, all the teams agreed that the new feature is a much better option for our end users - we had just stumbled a bit in our plan to roll it out to our customers. It was a good lesson for me and one that I'm happy to have tackled before the official release where it could really have escalated.

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

More articles from our blog PM Decisions

Complete an Opportunity Assessment for proposed new product

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

After disappointing results from my previous attempts to stall the momentum building around this "must-have" component, I decided it was time to break out the heavy artillery.

If you had read any of the articles leading up to this post, you might conclude that I have been fighting a losing battle. Indeed, I have been chronicling the story of my struggle with this new product idea over the past few months:

1. Head off a new product idea
2. Clarify win-loss speculation with post-mortem interviews
3. Build a quick proof-of-concept

Each of those product decisions was driven by healthy skepticism around my company's impulsive and in my opinion, short-sighted product recommendation to build an MS Office plug-In. For the record, I'm not against this product idea at all. The campaign I'm engaged in here has more to do with making good, long-term product investment decisions.

What drove this decision

New product decisions should not be driven by fear, such as the purported threat of some competitor's offering. Likewise, they should not be pursued just because the solution appears to be simple to build or is otherwise easily accessible. There are so many more factors that should be considered. And they should be considered together, holistically.

What I needed was a way to communicate the whole picture to my stakeholders. I wanted to engage in an open discussion around all the decision criteria. And I wanted to come into this conversation with the main talking points already distilled from a more thorough study and backed up where possible, by actual data from relevant research.

The decision: Use Cagan's Opportunity Assessment to approach this product decision with more rigor and less bias.

Marty Cagan's Opportunity Assessment is described in his book Inspired - How to create products customers love - a must read for Product Managers.

This product decision really had 2 parts. First, I knew that I wanted to use Marty Cagan's Opportunity Assessment, which is an excellent and straightforward framework for evaluating new product opportunities. I think it is one of the best tools a Product Manager can have in their "belt". I deploy it whenever I encounter exciting new ideas - my own or another's. The Opportunity Assessment helps you exert solid due diligence before a good sounding proposal gets too far along.

Second, I wanted to use the Multi-Tool, a PowerPoint-based tool created by the team at theProductPath for this exact scenario. The Opportunity Assessment Multi-Tool puts Cagan's framework into an easy-to-use PowerPoint structure where the user can capture, then distill, and finally present the Assessment all using the same tool. 

Plan of attack

In this particular instance, Cagan's framework lays out the "plan". I stepped through each of the questions of the Opportunity Assessment capturing my answers as best I could. Using the Multi-Tool, I was able to focus on each question in isolation, using the "scratch area" on each slide to record all my rough notes.

When I felt I had sufficient material for a given topic, I distilled a shorter version of the notes in the "summary area" on the left side of the slide (the Multi-Tool shows these boxes in presentation mode while hiding the draft notes). 

Below, I have included copies of my rough notes for my company's proposed Office plug-In product. At the end of the article, you will find the distilled version of the notes that I used for the stakeholder discussion.

View fullsize

1 - Value Proposition

I started the Opportunity Assessment by looking at the problem we are trying to solve - not the solution itself. Note that it can often be difficult to focus only on the pain and not talk about the way you or your customers would like to solve it. But here - and this is important - we are trying to assess the opportunity itself, so we can ultimately decide if it is worth solving.

In my case, I had spoken to enough customers and prospects to know that using a cloud-based content repository presented challenges to teams that traditionally work with desktop authoring tools like MS Word.

View fullsize

2 - Target Market

The next step in the Assessment is to clarify exactly who is struggling with the problem(s) identified in question 1. When you have answered these first two questions, you have the foundation of a solid Problem Hypothesis: we believe that [the target user] has problems with [specific task(s)].

I had been able to zero in on the Legal teams as the target users in our customers' organizations who were most struggling with accessing their cloud content from their desktop tools.

View fullsize

3 - Market Size

When you are confident that you know who has what problem, your next task is to determine just how many of these users exist out there. This will give you a sense of your potential market size and should be a good early indicator of whether you're chasing a real opportunity or not.

As you might guess, some of the information in my particular Assessment is sensitive and I have further sanitized it for this article. As compensation, I have included an image of the draft version of the slide where you can see some of the assistance the Multi-Tool provides in the form of notes and pull-out tabs.

View fullsize

4 - Business Metrics / Revenue Strategy

The next topic forces you to think about how you will measure your success if you decide to proceed with the opportunity. I have found that too often, we push forward with new product development and even bring new products to market before we get agreement on exactly how that offering will help the business! That is exactly how we got into the situation I inherited where my company's product portfolio was bloated and unmanageable.  

For this assessment, I simply created some placeholders for the ensuing conversation with my stakeholders. I wanted them to be thinking about the revenue impact on our business for sure but also how our customers, our partners, and even industry analysts would ultimately measure our extended product portfolio offering against our competitors.

View fullsize

5 - Competitive Landscape

Now we come to the competitors, or more accurately, the competitive landscape. Because the truth is, you don't always lose deals to another vendor. Sometimes, it is inaction or the prospect's failure to make a decision. Other times, the customer just decides to live with the pain or finds some acceptable workaround.

In our case, I knew what customers had been doing to get by and we had a pretty good idea of what our primary competitor was offering. All the signs would seem to be pointing us toward building our own solution that was more attractive than both the existing alternatives.

View fullsize

6 - Our Differentiator

At this point in the Assessment, it is time to look within. In short, you need to determine, as honestly as you can, why you feel that your company is uniquely positioned to address this opportunity. Put simply, this question is, essentially "why you?"

I saw the customer's problem as a content-related one, and that was certainly within our wheelhouse. Compared to the broad range of functionality we already provide both in the browser and in other desktop applications, I felt that we would be confident in delivering a compelling solution here as well.

View fullsize

7 - Market Window

If the previous question was, "why us?", then this next one could be summed up as, "why now?" Even if all the previous answers had trended more positive than negative, you can still get hung up here.

For example, perhaps the overall market of your prospective users is known to be shrinking. Or perhaps the technology you need to build the product is still immature, giving you good reason to pause. Or maybe it is as simple as postponing this opportunity until after you complete other in-flight projects.

I think my company actually does have some urgency and that if we were indeed going to head up market, then we would need functionality like this to stay competitive. Even though I was still unconvinced that the entire opportunity was worth pursuing, I couldn't deny that the timing was right for us.

View fullsize

8 - Go To Market Strategy

All the white boarding and prototyping and story writing and development and QA and deployment won't amount to a hill of beans if you don't execute on your go to market plan. Think carefully about this topic as you consider how you will get your new product in front of your customers. Do you already have the channels in place or will you be exploring some unfamiliar territory?

This is another area where I have chosen to over-sanitize the material from my own Assessment. I would apologize but I'm sure you can appreciate the sensitivity of this information.

View fullsize

9 - Solution Requirements

If you've made it this far in your Assessment, congratulations - you're in the home stretch. This is where you sit with your top technical folks and have them spell out all the dependencies and unknowns that will affect your development plans. In my experience, this is often a sobering discussion. It's not that Engineers like to rain on parades, they are just blunt and frank by nature - but you need this information to help guide your decision making.

In our case, the list of requirements was quite long, especially considering that all the stakeholders had been assuming this would be an easy win. If I needed more ammunition to build the "no-go" case, then I could count on this laundry list to aid me.

The impact

Cagan's Opportunity Assessment actually has 10 questions. The first 9 essentially prepare you for the last 1: the go/no-go decision. Many times, when using the Assessment, I can stop well before I reach the end when I can see that the target market is not big enough or when the timing is wrong, or when I don't have an obvious go to market strategy. You might think that those are frustrating outcomes but actually, I am always pleased that I arrive at that conclusion before I waste a lot of energy chasing a bad opportunity.

I have yet to share the entire Opportunity Assessment with all my stakeholders but they know it's coming. I'm looking forward to reviewing the information with them and although I'm fairly certain where we will end up, I am genuinely open to the group's collective reasoning.

I mentioned earlier that the Multi-Tool is quite handy when you need to share your Assessment results with others. To demonstrate this, I have included the final Opportunity Assessment here, in presentation mode. Click through the slides to see how the Multi-Tool can also be used to create a beautiful presentation without any additional work. Just digest the best points from each question into the boxes on the left and start the slide show - that's it! 

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

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

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