Build the prototype to aid in new product discovery
In recognizing that we were finally in a position to start gathering real requirements from a prime new customer, I decided to move forward with building a prototype for a new product offering.
The Product Decision: Complete a working prototype that we could use to drive productive conversations with customers around requirements.
Flickr image source: http://tinyurl.com/pfyguao
In recognizing that we were finally in a position to start gathering real requirements from a prime new customer, I decided to move forward with building a prototype for a new product offering.
The Product team had known for some time that we had a legitimate gap in our product portfolio around an MS Office 365 Plug-In but we were not overly anxious as it was clear that the gap was not preventing the company from winning new deals. Even though our main competitor would regularly raise the issue with prospects during the sales cycle, drawing attention to our "deficiency", it had never cost us a sale.
The MS Office 365 Plug-In saga continues to unfold...
You can review the entire story through my past Product Decisions:
HEAD OFF A NEW PRODUCT IDEA BEFORE IT GAINS ANY MORE STEAM
CLARIFY WIN-LOSS SPECULATION WITH POST-MORTEM INTERVIEWS
BUILD A QUICK PROOF OF CONCEPT
From the beginning, when this "urgent need" was first identified, I had been steadily pushing back on internal stakeholders (see sidebar). I knew we didn't have the available resources or bandwidth to tackle this and without a line of customers outside my "product door" clamouring to have the new feature, I was hesitant to even start conversations around the Plug-In.
What drove this decision
In the previous quarter, we had signed our biggest customer in the company's history and, in our lengthy discussions with them around their needs, we had identified the (missing) Plug-In as a key, must-have feature.
This one customer, when fully deployed, could have more than 2,000 people using the new Plug-In. Based on those numbers, it seemed reasonable to me that we now had a decent base of users from which we could start to gather some useful insights.
The decision: Complete a working prototype that we could use to drive productive conversations with customers around requirements
I was eager to start talking with and observing real users in the field but I didn't want to do that using the low fidelity and crudely fashioned proof-of-concept we had completed a few months back. It was time to build and start testing with a real, functioning prototype.
Plan of attack
We were still very early in the product cycle for this Plug-In and there was no pressure to cut corners or skip steps in our product discovery process. I wanted to make sure we used a disciplined approach.
In this first phase, we would create a prototype that would give our Tech team more confidence in what it would ultimately take to develop and support such an app AND that would give the Product Team enough material to have meaningful discussions with the first round of users.
Vet the feasibility of our technical approach with Engineering
Flickr image source: http://tinyurl.com/p65wgqb
I had some solid ideas for how to create an initial version of the Plug-In though it was fair to say that we would be forging into unfamiliar territory. The Tech team had never developed this kind of app but we knew we would be getting support from our friends at Microsoft who is one of our key technology partners.
The first step in building the prototype was making sure our team could nail down some of the technology challenges that we would face. For example, high on our list were questions about user authentication, API access, and deployment of the app to customers through Microsoft's "online store".
So, over the course of a few weeks, the team completed a functioning prototype that addressed these areas of concern. Now, more confident that we had cleared the most immediate technical hurdles, I proceeded with getting some internal validation.
Share the prototype with stakeholders inside the company
I very much wanted to show the prototype to our Sales Engineers. They had always been good product collaborators and certainly understood the broad use case for the Plug-In. I set up a meeting with them and the Product team and with the Engineers to get and record some early usability feedback.
On the way to that meeting, I made a small detour to give a brief demonstration to our CEO as a courtesy “first look". He had taken a keen interest in this initiative and had been stalking me for many weeks. And even though we had only addressed the most simple use case in this iteration, he was very impressed with our rapid progress. My only regret was letting an Engineer run the demo - who uses superheroes for their sample data? Ha!
I should have known not to let an Engineer run the demo - who uses superheroes for their sample data?
We then sat with the Sales Engineers and reviewed our current hypotheses with them. They see much more front-line action with prospects in the sales cycle and helped validate our approach, often tying back to their deals from the past weeks and months.
I then had each of them install the Plug-In on their own machines to test it out. The response was overwhelmingly positive and we could see them already thinking about how they might adjust their standard demo scenarios to incorporate this new component.
One of them suggested they start using the Plug-In immediately to help them with one of their own team activities and I offered to check back in with them in a few weeks to see how it worked for that additional use case.
Show it to the technology vendor on whose platform our prototype was built
We had invited representatives from our partner Microsoft into our office for a high-level meeting to talk about Office 365 integration among other things. The timing of their visit provided a perfect opportunity for a prototype demo and to show what we had achieved in the past few weeks, with some help from their own technical folks.
After setting up the customer scenario with the group, we walked them through the working prototype and talked through some of the challenges we had worked through to get to this point. The Microsoft team provided additional validation around our approach for the Plug-In and gave us some pointers for how we could move forward. Our remaining questions were captured and would be carried back to their teams to help get us the answers we would need before rolling this out, even to beta customers.
In the end, I was pleased to know that our partner was ready to help us with next steps. They also expressed interest in the upcoming deployment with our new customer as it would provide a great case study for both us and them.
The impact
With the Engineering team, I was able to work through a few of the big technical unknowns to build a working version of the Plug-In. By meeting with and showing off the Plug-In to a few internal resources, we were able to get some early, but solid validation. And in reviewing the finished work with the vendor on whose platform we had built the Plug-In, we confirmed that we were on the right track in how we were going to deploy and support the new product.
But none of this would be worth anything if we didn’t immediately start validating the Plug-In with actual users. That work would likely start the very next week and is lining up to be the next chapter in this series.
Look for more reports from theProductPath around product validation, feasibility, and product investments here on PM Decisions.
More articles from our blog PM Decisions
Call in reinforcements to advance product initiatives
In recognizing that my internal team members did not have the time and/or expertise to help with a few of our upcoming and impactful product initiatives, I decided to reach outside the company and use trusted resources to temporarily expand my team.
The Product Decision: Recruit available experts from the company's extended circle of trusted colleagues to help tackle a few pressing product engagements.
Flickr image source: http://tinyurl.com/o7u8mc2
In recognizing that my internal team members did not have the time and/or expertise to help with a few of our upcoming and impactful product initiatives, I decided to reach outside the company and use trusted resources to temporarily expand my team.
My team has been working at full capacity and is focused on the exact right priorities to continue delivering strong product releases to our customers. There is always more work to do though and sometimes business priorities stretch beyond the team's existing capacity.
There are also budget constraints that are preventing me from expanding my team in a way that would help me address the projects that have bubbled to the top of the company's wish list.
What drove this decision
Good problem solvers can find creative ways to get around roadblocks. I was grappling with a backlog that was starting to look increasingly daunting and could not rely on the familiar and dependable resources that were tied up with other important work.
So I took some time to review the most pressing items and determined that there were opportunities to make short-term progress that would relieve a bit of the pressure. We could find the resources just outside the company's borders and engage the expertise we needed to catch up.
The decision: Recruit available experts from the company's extended circle of trusted colleagues to help tackle a few pressing product engagements.
Flickr image source: http://tinyurl.com/p3nuhy6
We all know smart, dependable people and we try to hire them to permanently join our teams when we have the chance. But these are highly sought-after resources and it's not feasible to hire all of them - how many organizations need 5 senior-level specialists in given functional area? And besides, many of them have already been scooped up by other lucky companies and are happily employed in good positions.
But sometimes, you can catch these folks between gigs and if the stars are aligned, you will have the opportunity to pull them into your group, even if it's only for a brief period of time. I was fortunate enough to have several of those opportunities at the same time and decided to act so I could move forward with my product plans.
Plan of attack
I had been mentally cataloging important projects that were product-related but would not be easy to fold into the main product work stream. Most fell somewhere between must have and nice to have. So to improve my chances of being able to outsource these initiatives to interim resources, I adjusted the scope for each by decomposing larger efforts into smaller increments with shorter iterations to better accommodate less predictable schedules.
As I continued to network with smart product people outside my company I had been on the lookout for available resources with the specific projects in mind. This week, I was able to pull in some strong people to tackle a few of my projects. Coincidentally, each had recently switched into job hunting mode and were delighted to have some part-time assignments to fill the gaps between recruiting activities.
I seized the moment(s) and put them to work immediately to start these three projects:
Build a plan to move from proof-of-concept to prototype
There is a new product proposal that has been gnawing at me for the better part of a year now. I've written about it before (see here) as it continued to gain steam (see here) despite my attempts to slow it down (see here).
This is not the time to argue the merits of this particular proposal but in the spirit of compromise, I have agreed to take the next step in building a true working prototype from the previous proof-of-concept. I was prompted more by the additional learning we could achieve around the technical feasibility than I was in gathering important user insights from an interactive, UX prototype (that would most certainly come later).
I found a talented and credible Product Manager to lead this technical prototype project and paired him up with an expert from one of our technology partners as well as with one of our own Engineers. Collectively, we reviewed the project's scope and made only a few small tweaks to build a 30-day plan that was mostly likely to deliver the outcome.
Revamp product documentation
I don't think I'm stretching the truth when I say that the Product and Tech teams have collectively stepped up our game this year. In addition to reducing the duration of our release cycle to deliver more updates more frequently, we have also focused on pushing out more high priority feature enhancements that are based on direct customer feedback.
What we haven't done well is keep up with all the supplemental collateral that typically accompanies product releases.
What we haven't done well is keep up with all the supplemental collateral that typically accompanies product releases, most notably our official product documentation. There are, I'm ashamed to admit, deficiencies in our collection of knowledge articles with out of date material, flimsy coverage of major components, and complete documentation gaps around key new features.
So I asked a really smart person to help us out. She came in, took one look at our Knowledge Center and decided she would do more than just fill in some obvious gaps. I had asked for help in getting the team caught up - what I got was a proposal and estimate for overhauling the whole depot. Her plan was so impressive that it took me no time to get the entire project approved.
Analytics roadmap
Several weeks back, I had pulled in one of these same folks to help me think through an analytics-related offering. The response to that deliverable had been overwhelmingly positive, both internally and with customers. Based on that success, I reached out to her again and asked for assistance in mapping out a high-level plan to get us to the point where we could actually produce those results in a production environment for customers.
She was the domain expert and needed little support from me other than to know how best to position the final recommendation and how to apply the appropriate polish to effectively sell it to my stakeholders.
The impact
Eventually, I'd like to expand the Product team to be able to tackle even more of the "product backlog" but these short-term engagements have allowed me to make some good progress in the meantime. Outsourcing work can be a great tactic when time or skills are in short supply. My own experiences have been positive, but a great deal of that success is directly tied to finding and securing great resources, inside or outside the company.
Look for more reports from theProductPath around product teams, backlog grooming, and capacity planning here on PM Decisions.
More articles from our blog PM Decisions
Complete an Opportunity Assessment for proposed new product
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.
The Product Decision: Use Cagan's Opportunity Assessment to approach this product decision with more rigor and less bias.
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:
- Head off a new product idea
- Clarify win-loss speculation with post-mortem interviews
- 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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Build a quick proof of concept
After realizing that I had failed in my previous attempts to head off a questionable new product idea being advocated by our head of Sales, I decided to fabricate a bare bones working example to advance the conversation.
The Product Decision: Outsource a simple prototype to an overseas development partner to avoid disrupting the in-house Engineering team.
Flickr image source: http://tinyurl.com/o8lbm83
After realizing that I had failed in my previous attempts to head off a questionable new product idea being advocated by our head of Sales, I decided to fabricate a bare bones working example to advance the conversation.
To be honest, I was more than a little intrigued by the new product being proposed, not because I thought it would prevent us from losing deals to our competitors - to my knowledge, we hadn't lost any yet, at least not for this supposed product gap. And it wasn't because the technology was particular fascinating or exclusive - in fact, many of our customers could likely build a lightweight version of this on their own without much trouble.
I'd have to say my curiosity was driven by the opportunity to create something new.
Our company has been building a large software platform for over a decade and it increasingly becomes harder and harder to innovate when you're towing along such a hefty code base.
One of the classic mistakes companies can make is to blindly pursue building a new product just because it is feasible for them to do so.
But I wasn't going to let my own fascinations cloud my judgment. One of the classic mistakes companies make is to blindly pursue building a new product just because it is feasible for them to do so. I know better than that and I didn't want to carelessly lead my team down the wrong product path.
The next step then, was to find a way to better validate the claims coming from our own Sales team but to do so with the minimum amount of effort and investment.
What drove this decision
This is a simple chart I created to help drive more meaningful conversations with our Sales team. I have yet to get them to pin down all of these numbers for a given "missing feature" but in their defense, we don't really collect and track sufficient/suitable data in our sales process to drill down this far. Still, this model does help to frame product investment decisions.
Our Head of Sales was steadfast, still convinced that our product had to have this missing functionality, mostly because our chief competitor was flaunting their own version in front of our prospects. I had tried - and failed - to squash the idea before it gathered any more steam. It was becoming clear to me that I would have to dedicate more cycles to this product proposal even if the end result (i.e. not moving forward) was the outcome.
My chief problem, however, was that our Engineering team was booked solid for the next few sprints and I didn't want to distract them with a side project that was still a long way off from being productized.
I needed a way to make some incremental progress with the new product idea without impacting the team's current development velocity.
The decision: Outsource a simple prototype to an overseas development partner to avoid disrupting the in-house Engineering team.
Giving a new project to an external team can be tricky. My goals were to properly scope the work up front, produce the desired results quickly, and have a clear path forward when the project was complete.
Plan of attack
I was focused on reducing the size of the project to the point where I had what I needed to start validating the product with our end users and prospects. That meant more than just providing good requirements however. I also needed to give the remote team the support it would need to complete the job and deliver the goods.
Define basic requirements and allowable shortcuts
One nice thing about sharing early prototypes such as wireframes or mockups is that your intended audience will often be very forgiving. I have found that when provided with sufficient clarification, users will focus on what's there and not obsess about what's not yet there.
I wanted to make sure that the proof of concept had enough relevant functionality in place to confirm our initial hypotheses. I also wanted to identify places where we could safely skip over steps that would have to be part of the final solution. These include the compulsory but more technically challenging operations like installation and authentication.
I wrote and delivered the requirements to the remote team being careful to emphasize the elements that would have to perform accurately for the end user. I then highlighted the remaining elements that didn't contribute directly to the end user experience where I felt we were safe in taking time-saving shortcuts (i.e.. "just hardcode it for now").
PROVIDE TECHNICAL SUPPORT TO TROUBLESHOOT the remote work
Our remote development team had been working with the company for several years but some new faces were joining this project. To make sure they could ramp up quickly and avoid any first-time stumbling blocks, I recruited a few key internal, technical resources to help launch and support the effort.
As it turns out, the remote team did hit some stumbling blocks in their attempts to use our new API and in resolving those issues, we actually uncovered - and fixed - some problems with our own API deployment process!
Secure the POC artifacts for the next round
When the proof of concept was finished, I had the remote team demo it to a few folks from our Engineering and Product teams. We were all pleased to see the results and I felt confident that we now had a suitable working model to go back with our Sales team and begin engaging customers.
The impact
I had already expressed my doubts to the Sales team about the actual effects of adding a component like this to our product mix - specifically, that it would not significantly advance competitive deals that are in jeopardy. With a working proof of concept in our hands now, it would be easier for us to determine exactly what (would-be) customers were looking for and whether this would affect their buying decision.
I would still have much more work to do in building a truly shippable product if I was wrong and customers latched onto this proof of concept. But I am convinced that I made a good tactical decision at this point and that we would realize a good return on this particular product investment decision.
Look for more reports from theProductPath around product validation, feature prioritization, and managing stakeholders here on PM Decisions.
More articles from our blog PM Decisions
Clarify win-loss speculation with post-mortem interviews
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.
The Product Decision: Schedule discussions with the lost prospects to learn more about their exact decision criteria.
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
Head off a new product idea before it gains any more steam
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.
The Product Decision: Get the Exec team to back off their urgent new product ploy.
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!”
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
To address one of the most critical problem areas for customers using our software platform, I decided to roll up my sleeves and conduct the fieldwork myself.
The Product Decision: Enlist the help of our User Research expert to coordinate formal interviews with a suitable group of administrators and end users from our active customer base.