Build the prototype to aid in new product discovery

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

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

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

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

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

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

CLARIFY WIN-LOSS SPECULATION WITH POST-MORTEM INTERVIEWS

BUILD A QUICK PROOF OF CONCEPT

COMPLETE AN OPPORTUNITY ASSESSMENT FOR PROPOSED NEW PRODUCT

CALL IN REINFORCEMENTS TO ADVANCE PRODUCT INITIATIVES

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

What drove this decision

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

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

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

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

Plan of attack

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

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

Vet the feasibility of our technical approach with Engineering

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

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

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

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

Share the prototype with stakeholders inside the company

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

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

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

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

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

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

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

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

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

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

The impact

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

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

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

More articles from our blog PM Decisions

Brainstorm a product solution for customers

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

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

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

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

What drove this decision

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

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

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

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

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

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

Plan of attack

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

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

Prep ahead of time to streamline the conversation

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

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

Assemble a good quorum

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

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

Have open-ended questions ready

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

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

Stay on topic

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

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

The impact

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

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

Look for more reports from theProductPath around product strategy and product culture here on PM Decisions.

More articles from our blog PM Decisions

Initiate a few modest R&D projects

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

After getting our major roadmap items underway and finding our rhythm with smaller bugs and enhancement requests, I decided it was time to launch a series of background research tasks.

I don’t want to give the impression that we have tons of spare bandwidth. We are struggling with the same resource constraints that plague most Product teams but I believe there is value in prudent technical experimentation. In my experience, even the most ambitious Product Roadmaps are primarily designed to keep everyone going down the same path and they don’t afford much room for concurrent product exploration - and I’m not talking about unexpected wrong turns!

Sometimes you need to launch a few parallel pursuits to introduce new ideas and shake things up.

What drove this decision

I continue to be impressed with our entire technical team and am convinced that there is even more potential there that we can tap into through targeted endeavors. In this case, the team had been making favorable progress on several, in-motion product initiatives and that prompted me to think a little further out than I had been.

Several months back, we had embarked on a plan to upgrade some of the underlying technology in our core platform, partly on the promise that it would deliver advanced functionality above and beyond the legacy components it was replacing. We were now closing in on a major delivery milestone and had a sound plan for the upcoming transition. That inspired confidence and afforded me with some breathing room to further explore the features of this new technology.

Sometimes you need to launch a few parallel pursuits to introduce new ideas and shake things up.

Separately, in another work stream, we had been investing a great deal of resources into building a new data repository to capture information related to the user activity in every automated business process. The initial payoff would be the launch of a new mobile application which gives users unprecedented visibility into their own workflows.

The mobile app was now being rolled out to customers but that initial investment was always intended to yield more for us and for our users. This seemed like a good time to start work on the next phase of that product initiative.

The decision: Recruit uniquely qualified resources to kick off independent, well-scoped initiatives with a high potential to excite both customers and stakeholders.

R&D efforts are not always guaranteed to deliver positive or even actionable results. Still, I didn’t want my first ventures to fall flat as I intended to follow up with additional waves of experimentation. Ideally, the R&D projects would help to determine which ideas were feasibility and for those, what we should expect in terms of level-of-effort to implement, deliver and support them. This would help me assess how and when to fold them into the Product Roadmap.

I was also planning to share the results with the Management Team and our Board in order to show what we might be capable of delivering at the far end of the Roadmap. A secondary goal for me then was to demonstrate early success and improve the chances of funding future R&D work.

Plan of attack

These initial projects were trial balloons for me and the Product team. If we succeeded in producing positive results, we were likely to be encouraged to continue exploring and experimenting. To increase our chances of success, I took care to limit the scope of each effort, to pick the right team resources, and to schedule shorter term deliverables. 

Disclaimer: As R&D projects can be sensitive and can often impact a business' competitive advantage, I have chosen to sanitize and share just 2 of the projects here.

Project A explored the viability of an inverted search feature that enables an end user to determine if a given document matches one or more search terms. Our customers have shared use cases where they need to know if a modified document still contains one or more paragraphs, terms, etc. An inverted search could discern whether a given contract contained one more standard clauses for example.

Project B looked to expand our company’s use of analytics to report on and ultimately improve document workflows. Customers were already investing heavily into our platform’s workflow features to automate their business processes and I wanted to be able to give them much more data to evaluate the people, process, and documents involved in those workflows.

Scope each effort

In my opinion, the most important factor for success was in how we defined the projects. Too broad and we might never see any results. Too small and they may be de-prioritized or even dismissed.

For the first project, I needed to show the general applicability of the inverted search and the relative effort to configure the function. We didn’t need to tackle complicated documents or complex search terms but we did need to stay relevant to our customers’ use cases. The goal for this project was to prove the feasibility of the technology - usability would be addressed in a separate effort.

The other project was quite different. Here I was looking to identify the overlap of actual customer inquiries and available analytic data. The goal of this project was to find as many good matches as possible between what our customer research had surfaced around visibility into workflow processes and the rich analytics we could be generating in the future.

Enlist Internal and External resources

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

To kick off Project A, I cornered one of our Software Architects and bribed him with pastries - a low-cost recruiting tool!  He is the resource who was primarily responsible for introducing the new technology to the Tech team and who had been overseeing its implementation during the past few months. I sat down with him and painted the picture of how we could use the advanced features of this technology to address real customer problems that were going unsolved. He understood the benefits and like me, recognized the large payoff of a relatively minor product investment. I had no trouble convincing him of the value of a proof-of-concept and promised to carve out time for him to explore this during the upcoming sprints.

For Project B, I went outside the company to find subject matter expertise. I had been introduced to a woman who specializes in all things data, metrics, analytics, and visualization. I had seen examples of her previous work where, given very little in terms of schemas or actual data, she produced some amazing and insightful dashboards. This was exactly the kind of impact I was looking to make with our own embryonic data store. After explaining what little I had to start with but where I was hoping to go, she presented a reasonable proposal that fit within my time and budget constraints. There were very few dependencies on our own internal resources and indeed most of the Tech team had little knowledge of the project. I did pull in our heads of Engineering and UX to help keep me honest and on track.

Timing the project deliverables

As part of the scoping effort, I created schedules for each project that would produce results in a meaningful timeframe. Our next major product release had already been scheduled to coincide with an upcoming industry event. We already had plans to show off the latest product improvements at the trade show but if some of these R&D projects panned out, we would have even more to entice customers and partners.

The impact

Based on this preparation, I was able to get my R&D projects approved, funded and launched successfully. The early evidence is mostly positive and we seem to be on track to deliver on the goals I set early on. Now I'm engaged in some early internal promotion around a few of the projects and have even started to leak some preliminary results to our CEO and our head of Sales to validate the intended ROI. I'll share more progress updates in the weeks ahead.    

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

Build a quick proof of concept

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

View fullsize

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

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

Assess the Product Portfolio

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

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

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

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

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

What drove this decision

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

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

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

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

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

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

Plan of attack

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

View fullsize

Simplified Product Portfolio Model

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

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

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

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

2 - Clarify the ratio of Products to Product Resources

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

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

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

3 - Future investment and product goals

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

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

The impact

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

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

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

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

More articles from our blog PM Decisions

Evaluate a product integration with a potential partner

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

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

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

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

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

What drove this decision

Sales was getting anxious - more anxious than usual

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

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

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

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

Diagrams help to communicate with a broader audience 

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

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

Plan of attack

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

HIGHLIGHT the origin of each integration point

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

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

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

Identify dependencies

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

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

View fullsize

Sample Integration Diagram

Identify alternatives for each Integration point

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

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

Distinguish between what's available now and in the future

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

The impact

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

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

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

More articles from our blog PM Decisions

Present a Product Roadmap to the Board using the 3 Horizons Model

Image source: https://www.flickr.com/photos/donkeyhotey/6143615821

In preparing to present the new Product Roadmap to the Board of Directors, I decided to employ a popular investment framework to organize our product decisions.

If your company has a Board of Directors or similar advisory group that helps guide the organization, chances are they will be curious about where the product is headed; however, more than the other stakeholders, this group is likely to view your ongoing product decisions as a series of investments. And, like any investment, yours are expected to deliver positive returns down the road.

As the head honcho for the Product team, you are responsible for crafting a rendering of the product roadmap that gives them the appropriate level of detail. There a number of ways you can organize your product investments to maximize both short term and long term opportunities but communicating that plan to “The Board” can be a challenge.

What drove this decision

In refreshing our roadmap, the Product team had established high-level themes to guide decision making but these tend to be more appropriate for filtering and prioritizing work and less useful for calling out specific product initiatives.

The 3 Horizons model was first published in The Alchemy of Growth by Merhdad Baghai, Stephen Coley, and David White in 1999 and made popular by the likes of McKinsey, Geoffrey Moore, and others.

I knew our Board members would not have the patience or the necessary product-level knowledge to absorb a thorough presentation of our detailed product roadmap, filled with epics and stories. Plus it can be difficult to get a good sense of the overall product direction when sitting that close.

For this particular audience, I needed to use broad strokes. Specifically, I wanted to explain exactly where the investments were being made and how we expect them to pay off in the next 6, 12, and 24 months.

I first ran into the 3 Horizons model in a wonderful presentation entitled 10 Roadmap Tools created by Radiant Minds (now part of Atlassian, makers of Jira). They recommended using this tool to communicate a high-level product roadmap as a set of investments that extended the current business but that also created viable options for the future.

The decision: Use the 3 Horizons Model to present the Product Roadmap to the Board of Directors and show how we would balance short and long term investment opportunities. 

I recommend exploring the Radiant Minds presentation and perhaps even reviewing the original source material for additional insights. I found this model to be convenient for speaking to our Board members - so that rather than try to impress them with impressive-sounding technical jargon, we were able to spend time talking through how we would leverage the technology to drive real, positive outcomes for the business.

The 3 Horizons model can help you organize your thoughts so that you continue to capitalize on the current customer opportunities while carving out appropriate cycles for favorable market conditions in the future.

Plan of attack

It would be impossible and also inappropriate to provide the full details of my company’s product roadmap here so I have obfuscated much of what follows. I have included a few examples that should help to illustrate the thought process I used in adopting the 3 Horizons model for our Roadmap presentation.

Horizon 1

The first horizon in the model shows how 70% of your investment should go into existing technology that you currently use and in an existing market that you currently serve. This best positions you to defend your current business and capitalize on your company's existing resources.

For our company, we used Horizon 1 to outline the scheduled work in the roadmap that would build on the technology components already present in our core platform. For example, we planned to develop a new mobile application for our customers based on feedback we had been gathering for the past few months. I explained to the Board that, because we had built front-end and back-end software like this several times before (and were quite good at it), the business risk for this new application was fairly low.

Horizon 2

In the second horizon, you describe how 20% of your product investment will utilize existing technology currently not in use in your company to address an existing market that you do not currently serve. Adopting proven technology lowers the risk for your company as you look to serve customers in the new market.

Internally, our teams had been researching an alternative to our outdated reporting infrastructure and, in the months ahead, we were planning on dedicating resources to the effort of overhauling our reporting engine. The new technology would allow us to better aggregate the information our platform collects and build helpful data-driven dashboards. As I explained to the Board, the Horizon 2 product investments would allow us to deliver an analytics offering to new and existing customers, opening up additional revenue opportunities outside of the markets we serve today.

Horizon 3

The final horizon in the model is used to highlight the remaining 10% of your investment, which is where you target new technology with the intention of entering a new market. It is admittedly harder to aim for that third Horizon - which explains the proportional size of this set of investments.

Our team has set its sights on eventually moving away from relational databases entirely and the decisions we made in this iteration of the roadmap reflect that. We are looking to the next generation of database technologies to help our software platform scale that in turn could open up much larger customer opportunities. Over the next 12-24 months, we intend to incorporate new technology into the platform to better position the company to go up market and pursue larger customer opportunities. 

The impact

You will find that there are different audiences for your Product Roadmap and each audience may have different expectations - and different level of interest. Our Board responded positively to the overall roadmap presentation and was especially engaged in the investment-oriented nature of the product decisions based on the 3 Horizons model.

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

More articles from our blog PM Decisions