Conduct high-priority product research

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

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

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

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

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

What drove this decision

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

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

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

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

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

Plan of attack

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

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

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

Start with hypotheses and a good prototype

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

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

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

Recruit and track participants

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

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

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

Conduct and record the interviews

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

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

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

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

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

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

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

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

Our agenda for the interviews followed this path:

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

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

The impact

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

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

More articles from our blog PM Decisions

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

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

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

Publish and promote a more consumable product roadmap

Flickr image sources: http://tinyurl.com/otrq3r6, http://tinyurl.com/qyf68uo

As interest in the future capabilities of our products began to increase, I decided to invest more time in making the roadmap more accessible to all parties.

I could spend hours tinkering with a roadmap. There are so many variables to play with, dependencies to work through, customer feedback to fold in, unanticipated hiccups that challenge the schedule, new bugs that surface, and on and on. Without any prompting, I will frequently create several versions of the roadmap to emphasize different details or highlight specific risks. But the list of people that want or NEED to get that close to those details is quite short.

The roadmap can be an indispensable tool for communicating plans to those outside the product team. In my experience though, geeking out with the product roadmap is just not for everyone - most people just want the simple story.

What drove this decision

Over the past few months, I had been fielding a steady stream of inquiries from our Sales team who in turn, were being asked by our customers and prospects to share our product roadmap. These requests were prompted by a desire to see where the company were headed, product wise, especially when there was some set of requirements that would seem to stretch the current limits of our platform.

Most people just want the simple story.

I was also being pulled into discussions with other departments across the organization where, inevitably, the conversations were centered around how our products would (or wouldn't) address a variety of concerns. During these meetings, I often felt as if I should have been carrying a copy of the roadmap with me but the versions I had were too elaborate and were more likely to have generated more questions that it would have answered.

The decision: Socialize a lighter weight product roadmap for inside and outside audiences

Many of the questions I was answering were simple in nature and could be settled with a quick clarification or by referencing a feature in an upcoming release. Unfortunately, there was no accessible model or illustration to reference. I needed to create an alternative, more accessible artifact.

Plan of attack

You have different considerations when you produce a version of your primary artifact that is suitable for external audiences. Not only will you have the challenge of reducing the overall complexity of the content to make it more accessible to those with less context, but you may also need to put it within appropriate physical reach to accommodate the timeliness of their needs.

For me, this meant paring down the content to eliminate details that would only be needed or appreciated by the Product and Engineering teams. It also meant distributing the new artifacts to new channels that puts them within arm's reach and encouraged self-service (vs. disruptive, ad-hoc inquiries).  

Create an attractive artifact that's easy to follow

The first step was perhaps the most difficult for me. I started with the assumption that this extended audience would have a very limited attention span. They would not be that interested in exploring all the potential paths, dependencies and implementation details of the 12-month product roadmap. They were looking for quick answers to broad questions.

Image source: https://www.flickr.com/photos/freshwater2006/693945631

In an attempt to remove the "clutter", I focused on highlighting outcomes, specifically the key dates when they could reasonably expect the big ticket items to become available. I retained the high level  themes, the broad commitment dates and other key elements that go into creating a solid product roadmap. I also embellished this version a bit, altering the names of certain features to line up better with customer use cases. For example, instead of listing a simple "reminder" feature, I described how the reminders could be used to better support a particular business process lifecycle.

Finally, I included and emphasized disclaimers about the accuracy of the roadmap commitments to help set/adjust expectations. This was a bit more CYA than anything else as I want to be able to defend future product decisions that will inevitably conflict with any previous "promises".

Make it accessible for self-service

Not that I don't appreciate being pulled into product conversations but a great number of these do not require the Product Head Honcho. To help people answer their own questions, I took care to put the light weight Roadmap in easy-to-find places throughout the office and beyond:

• Outside my office - My own office is on a well-trafficked path making it convenient to post a copy of the Roadmap on the wall. Several times, when people have barged into my office, I have had to gently usher them outside to point out the "self-service" display. 
• On monitors - Our IT team has placed large, flat-screen monitors throughout the office. I have inserted an image of the new Roadmap into the standard rotation for these monitors to help keep it top of mind.
• Shared repository - I also found it useful to put a copy of the Roadmap artifact in the shared "folder". We have been coaching people to begin any new search there before emailing or picking up the phone.

Present early and often

Now that the distilled Roadmap was ready, I started to share it with the teams at every opportunity. At "all hands" meetings, at our monthly Release Preview, during weekly Sales and Marketing meetings, and at customer events, I would present the artifact to show incremental progress, update everyone on recent product decisions and even show sneak peaks of ongoing development initiatives. 

The impact

I am pleased to have stemmed the tide of inbound roadmap-related queries. And while it does take a few extra cycles for me to keep everyone up to date, I am confident that we have further empowered our Sales team and are helping them move past would-be obstacles with customers and prospects in the sales cycles.

The simpler, lighter weight rendition of the Product Roadmap is now a staple of our planning efforts. We will continue to produce and promote the roadmap through this artifact.

Look for more reports from theProductPath around product management tools, product roadmaps, and product culture 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

Create a shared space for departmental wish lists

In accepting a PM position with an organization that had no central place to capture and prioritize product-related requests generated from each department, I decided to pull together the lists from all the stakeholders into a common forum.

Of course departmental wish lists had been created over the years but were languishing as disparate spreadsheets, as bulleted lists in shared Google docs and as giant backlogs in our issue tracking software. These lists had not been kept current, were not being shared, and thus were impossible to synthesize for product planning.

What drove this decision

So what I really inherited was a bigger challenge and this was a known problem throughout the company. The lack of a central place to discuss product priorities had led to more than a few skirmishes and past product releases had been poorly received as various constituencies inevitably had begun to feel neglected or and complained that the Product Team simply misunderstood their needs.

I am now in charge of the Product Roadmap. As any Product Manager knows, this is a challenging assignment as it involves collecting, verifying, and prioritizing inputs from many stakeholders. To get started, I wanted to review any previous roadmaps and revisit the current backlog of requests from Sales, Customer Support, Operations, etc. The old roadmap was easy to locate but when I started asking around for the backlog, I was surprised to learn that there wasn’t one.

The decision: Introduce the team to Trello

I needed to (re-)create a forum where each department could list their own issues and make them visible to the other groups. It had to be conducive for collaboration and ultimately, allow stakeholders to collectively agree on the next set of priorities. But most of all, it had to be easy to use.

I decided we would begin planning high level product strategy using a shared Trello board. Trello is a flexible online tool that helps you organize lists and is very simple to use. 

• The free version would more than suffice for the size of our team and our limited needs
• Those who chose to invest more energy in capturing their requests would have ample means to do so using Description fields and other Trello features
• Each card would have its own comment thread to encourage and preserve group discussions 
• Users have the option to use card-level voting to avoid duplication and find common ground
• Plus, the good folks at Trello have made it work equally well in browsers, on tablets and on mobile phones

Plan of attack

I cannot share our company's product priorities here of course but you may adapt this approach for your company's own planning needs.

Build new board with a good name

I started by creating a new Trello board for our company and named it “Roadmap Priorities”. I chose the name intentionally as I knew I would need to push back on well-meaning folks who would get carried away creating cards that were important to them and the company, but ultimately unrelated to our product strategy. Instead, I encouraged them to create separate Trello boards for their own departments.

Create a list for the current release

To provide some perspective to the group, I created the first list on the board and backfilled it with cards that represented our current set of priorities, mostly to provide a model for what we would be aiming for in future strategy sessions. I made this the left-most list on the board so they would see it first and that proved helpful in on-boarding users who were new to Trello.

Prime the board with existing lists and examples

I created separate lists for each Department so that each would have a place to add their own set of cards. In an effort to prime the pump, I imported a few lists from existing spreadsheets that had been floating around some of the departments. For other groups, I created some sample cards to give them a starting point. In this way, I was able to accelerate the adoption of Trello and the roadmap planning discussions. 

Use colored labels for Each department

I used Trello’s colored Labels to assign a unique color to each department. This has made it easier to identify the originating department for each request and, as we move over cards to create a single “Release” list, has allowed us to see the relative priorities of each department. Even better, by combining multiple departmental labels on a single card, we were able to quickly find common ground among common requests. 

Invite collaborators to the board

I formally invited all the department heads to join the board. For some teams, it made sense to invite more than one person, especially where I anticipated some early, tool-related friction. Each collaborator received a friendly email invitation with a simple call to action to join the Trello board.

Onboard stakeholders

Even though Trello makes the sign-up process easy for new users, I expected and struggled with early engagement. As a precaution, I also schedule 15-minute meetings with each stakeholder to get them past the initial access challenge (e.g. logging in) and to provide a quick tour of Trello. The preparation (described above) went a long way to getting early buy-in. Stakeholders immediately identified with their department and were comforted to see familiar items in their own lists.

In explaining to the stakeholders how I would be using the board and the cards on each list, I also tried to motivate them by strongly implying that the best prepared departments would have a chance of seeing their priorities folded in to our roadmap.

The impact

The results for our company have been quite promising in these early weeks. Five of the six departments have been very active on our Roadmap Priorities board and that is making the planning for our next release much easier for the Product team. Trello deserves a great deal of the credit for providing such an amazing tool and we have witnessed its broader adoption throughout the company.

Look for more reports from theProductPath around Trello, roadmap planning, and working with stakeholders here on PM Decisions.

More articles from our blog PM Decisions