Deliver a more compelling product status update to the troops

Image source: http://tinyurl.com/p3cc4o6 (Flickr)

In recognizing that our periodic meetings to share our development progress were falling flat, I decided to revamp the company-wide Product Preview event.

For many years, our company had maintained a recurring "preview" meeting where all employees were invited to catch a glimpse of the most recent product developments. At each meeting, a rotating group of Engineers would take turns showing off their team's work, which frequently included partially finished features that often led to unproductive Q&A with the assembled audience.

I believe the original motivation for having these meetings was well intentioned. It can be difficult for other parts of the organization to appreciate the black box that is Engineering. By revealing to the larger group the fruits of all that labor in a product demonstration setting, all interested and affected parties have a better opportunity to stay in sync.

But in our organization, these regular updates from the tech side of the house were not working. It was difficult for non-Engineers to relate to the material. We needed more structure, more context, and a bit more sizzle than you might expect from those who spend the majority of their time with variables, algorithms, and debuggers.

What drove this decision

Image source: http://tinyurl.com/qyhp33b (Flickr)

Engineers seem to communicate best when they're speaking with other engineers. I don't think I'm inviting controversy by stating that Engineers are not the best orators. Public speaking is not necessarily a skill that helps them with career advancement, and perhaps part of what makes this particular field more attractive to them. Either way, a company-wide meeting with an exclusive Engineering agenda is going to have its challenges.

Engineers also tend to have a myopic view of their work. Even when you find a vibrant communicator, they will still struggle to connect their important contributions to the larger picture. To be sure, getting that new feature to work is a great accomplishment (especially when you factor in the additional challenges of having to upgrade to the latest, post-beta, open sourced, cross-platform, fault tolerant, minimal footprint, backward-compatible, mobile-optimized, ...)

But in a larger group setting like this that draws a cross-functional audience, there is an even greater need to tie the product-level work back to the higher-level company goals. I needed to find a way to continue to report on the great progress we were making but in a way that better catered to the entire company. 

The decision: Substitute the Engineering-led, tech-heavy, feature-level demos with a Product-led, value-driven, full on show-and-tell lineup

Image source: http://tinyurl.com/ntevbtd (Flickr)

To clarify, I still want the Engineers to join in. And the meetings would still center on product demonstrations - that is still the best way to share with the company the progress we're making on our products. What I wanted was to tell that broader story, where product innovation is ultimately tied to business value (ours and our customers'). More than anything, I was intent on having the entire organization understand our motivation, what drove our priorities and how we were validating our hypotheses.

Our organization happens to be following an Agile software methodology, but I want to be clear that the show-and-tell meeting I'm describing here should not be confused with the Scrum Sprint Review. There is great value in having Product and Engineering conduct a meeting to share progress, review what was and was not accomplished in the most recent sprint, troubleshoot issues, and critique each team's work (see here for more information on Scrum's sprint preview). In fact, it would not be uncommon to also invite the same audience to the Sprint Reviews.

Plan of attack

After a quick poll of the other department heads, I confirmed the approach and verified that I would not be disrupting any dependencies they had that would have stemmed from the original meeting. And, as soon as I felt confident that the Product team was prepared and ready to take the lead, I cancelled the old recurring meeting, then created a new meeting invitation with a revamped agenda based on these goals.

Review Customer Success from Past Releases

I am intimately familiar with large product efforts that were, at one time, deemed high-priority or "must-haves". But I've also observed that, too often the very next big feature quickly distracts us so that we lose track of what happened with the last one.

I wanted to start each meeting with a brief update about the last release, and specifically what we could report from our customer base. We had been improving the tools we use to help us better measure customer uptake. The Product team would continue to refine these reports to help communicate the return on our past product investments. 

Did we hit the mark on the last release?

• Who was using the new features?
• Who wasn't?
• Were the bug fixes received well? 
• Is the product more stable, less glitchy, and scaling well?
• What else did we learn?

DEMO NEW PRODUCT DEVELOPMENTS AHEAD OF the UPCOMING RELEASE

Image source: http://tinyurl.com/nkk7cpb (Flickr)

For most attendees, the draw of these meetings was still the shiny new features and we certainly wanted to use the opportunity to spotlight all the great work accomplished since the last release/meeting. But the switch to having the Product team members present the updates meant that they were more likely to hear how individual enhancements fit into the larger end user stories, how the updates might affect the configuration and pricing of the products - even how we might alter our product positioning in the market.

We also want to illustrate how the latest changes were building on previous rounds of investment rather than just demoing individual features in apparent isolation.

The Product team is always collecting feedback to validate our efforts but this would not have been the first time the other departments would have seen these product updates. At these Product Release Preview meetings, our intent is to show off features that are complete and already scheduled in the very next product release.

REVIEW THE CURRENT PRODUCT ROADMAP

The Product team has been putting more energy into the roadmap planning process itself and worrying less about adhering to any particular iteration of the roadmap. These meetings proved to be an ideal opportunity to update the company on any significant changes we had made to the roadmap since the last gathering. I intentionally scheduled this topic toward the end of the meeting to time box help keep the interactive conversation focused and productive. 

At this time, the Product team has not committed to publishing a refreshed Product Roadmap at each meeting.

RECRUIT CUSTOMERS FOR PRODUCT RESEARCH

We close each meeting with our continued plea to get everyone's help in recruiting customers (and prospects) for our ongoing product research initiatives. We have found that our calls for help tend to yield more fruit in the larger group setting, especially after delivering a rousing product demonstration. 

The impact

Part of the motivation for these changes was to stir up some excitement around all the great product work that goes on behind the scenes. Celebrating your accomplishments and sharing them with the entire organization is healthy for any team and can really boost company morale. And we certainly achieved that with the new format.

With the changes I made to the agenda for this "preview" meeting, I also helped distinguish these Product show-and-tells from the Engineering (Scrum) sprint reviews. And based on the informal feedback I received, our Engineers were actually relieved that they would not have to present to the group and that they would be excused from even attending the meetings - although many of them still show up and participate!

I consider this particular decision a great success and will share more about the impacts in future posts. 

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

More articles from our blog PM Decisions

Network with other Product Managers

Image source: http://www.freeimages.com/photo/509114

Prompted by my search to find a new PM team member, I decided to reconnect with my local peers to converse on products, recruiting and more.

I had been so heads down for the past few months, getting up to speed as the new Product Head Honcho, that I had put any and all contact with external Product Managers way down on the priority list. Where would I fit that into the schedule? It had been challenging enough for me to carve out extra time to meet with our existing customers - and I knew I certainly couldn't defer that activity.

The invites to catch up over lunch and coffee had begun to pile up as I made excuse after excuse for why it was never a convenient time for me. But the truth is, I had been increasingly isolating myself from my peers. And these were colleagues who could help me validate some of my recent Product Decisions and provide significant insight into many of my current challenges.  

What drove this decision

In a previous Product Decision, I had chosen to replace one the PMs on my team, which immediately shifted me into recruiting mode (typically an exhausting exercise). In an effort to minimize recruiting fees, I began my search by reaching out to my own network of Product Managers. This provided me with a great opportunity to reconnect with old friends, and through them, new contacts. 

The decision: Use my pressing PM search as a motive for networking with other Product Managers

Image source: http://www.freeimages.com/photo/644967

I have found that most people like to feel helpful and are often flattered when asked for their opinions or for assistance with a particular problem. And, if talking shop over coffee isn't incentive enough, many professionals will gladly take time out of their schedule to help out a colleague, especially if the appeal is specific and reasonable.

In this particular case, I was hoping to identify suitable candidates to join my Product Team. By using my contacts to tap into the larger talent pool, I was confident I could accelerate my recruiting efforts. But I would also use the valuable face time to review a few of my past and future product decisions with these specialists.

Plan of attack

My first rule of professional networking is to make sure the meetings are productive for both parties. I began this post by declaring that I had very little spare time to spend outside my company. With that in mind, I began every meeting request with the assumption that my counterpart would likely be in the same position and would need some assurance that I would not be wasting his or her time.

So, aside from showing simple courtesy like confirming the meeting, arriving on time and choosing locations that would be convenient, I took extra care to make sure I was prepared for each discussion. 

Provide a Job Description

The primary goal for these meetings was to cast a wider recruiting net and to identify viable candidates for my open Product Manager position. I tried to make that clear in the invitation in the hopes of prompting some early reflection. But because the PM role can be different in each company, I wanted to further clarify the exact type of applicant I was seeking.

I had chosen to defer posting the PM job description on our web site until we had exhausted other available channels so there was no link I could share with my colleagues. But rather than send along some "pre-requisite reading assignment" ahead of our meeting, I chose instead to bring along and share a hard copy of the job description. The physical document, as a take away from the meeting, was meant to keep my appeal for help top of mind - for at least a few hours afterwards.

Prepare a List of Topics for Gathering Feedback

As I mentioned earlier, Product people like to talk shop as much as the next person and truly, I was no different. Once we had moved past the initial pleasantries and discussed the open PM position at my company, I switched gears to pick their brains on any of a number of subjects that I had recently encountered.

I truly wanted feedback and advice on my own projects so in an attempt to make the discussions more productive, I formalized my thoughts and even created some specific questions on each topic - because as a PM, you should never miss a chance to improve your interviewing skills!

Offer Assistance in Return

Besides paying for the coffee or meal, which always goes over well, I also made sure to save time at the end of the meeting to switch the flow and turn the conversation around. I wanted to give my colleague the opportunity to share with me what was happening on their end. What product-related problems were they wrestling with? How was their team performing? Did they have some big product developments happening in the next few weeks? 

And it never hurt to ask whether they were happy in their current job - sometimes you can get lucky and find a candidate in your immediate network.

“Let’s talk about you? Are you happy in your current job? Are they treating you well?”

Whenever the conversation turned to a problem or opportunity that I genuinely felt I could help with, I offered my assistance. And I made sure I followed up with any action items in my thank-you email.  

The impact

I am pleased to report that through this PM networking activity, I did indeed identify several viable candidates and that accelerated our hiring efforts. But more than that, I was able to reconnect with and renew important relationships with many of my peers. I collected valuable, relevant insight from these professionals that helped me validate or in some cases, adjust some of the product decisions I was making. I was able to expand my own network a bit, a typical but always welcome side effect. And then of course, there was all the great coffee!

Look for more reports from theProductPath around the recruiting for the PM role and professional networking here on PM Decisions.

More articles from our blog PM Decisions

Upgrade the Product...team

Image source: https://www.flickr.com/photos/drewmaughan/8685770869

In recognizing one of our Product Managers had failed to establish credibility with his peers and colleagues, I decided to refactor the Product team

The Product Manager role is a precarious one. What makes it particularly challenging is that to be successful, you must find ways of influencing other teams in the organization without having any direct authority over them. This is most critical of course when working with software developers or engineers who are the ones building your product.

Credibility is everything. In my experience, you must look to establish credibility quickly after joining a team and then continue to reinforce that with every new initiative. While there are many measures you can use to evaluate a Product Manager's performance, without a solid reputation, there is no foundation for success.    

What drove this decision

I had been monitoring my team's progress for several months and was noticing that one of the Product Managers was struggling with their assignments. I had been supporting the PM privately through one-on-one coaching and also more conspicuously with peers and colleagues. I was looking for evidence that this person could turn things around. The PM needed to build rapport with other Product team members and more importantly, with the Engineers that were taking their direction from the PM.

After many weeks, it was very clear to me that the situation was not going to improve, that the Engineers had run out of patience and that this person was damaging the integrity of the Product team itself.

The decision: Remove the ineffective Product Manager and use the new vacancy to update the entire Product operation

Firing an employee is never easy. I don't like the stress it brings although I have learned some effective techniques that can make the whole exercise less painful for both parties. We do not have a large Product Team so losing even one resource would have a significant negative impact on productivity in the short term. In particular, the other PMs would be taking on additional work to keep our product plans moving forward.

In the past when I have had to make these personnel decisions, I have always struggled with immediate risks to the current project(s). There is a voice in my head asking, "How can we afford to lose a team member now?"  But I have found it helpful to stay focused on the long term benefits and how an upgraded team would more than compensate for any short term momentum loss.

Plan of attack

Knowing about an impending personnel change ahead of time gives you an opportunity to better plan for the disruption. I don't know of any textbook method for tackling this but there are a few best practices I can share with others facing this same situation.

Communicate First to Stakeholders

As I mentioned previously, the Product Manager is a very visible role within the organization. Because the PM must make frequent rounds with Sales, Customer Support, Operations, and Marketing to stay up to date and also to communicate ongoing progress, they are often treated as honorary team members.

So the sudden absence of a team member, even an unofficial one can be unsettling for some groups. Removing the Product Manager from a Sales, Marketing or Support team can mean severing an important link to the products themselves. The PM often serves to bridge informational gaps throughout the organization. It was important to me to keep those connections open and productive during the period while we looked for a replacement.

To minimize disruption, I spoke with all the respective team leads prior to letting the PM go and those gestures were well received. I promised that my team and I would do our best to cover for any deficits and was pleased to hear corresponding messages from the other side of the table.

Image source: https://www.flickr.com/photos/funnyglowingsmurf/7625470418

SHORE UP IN-PROGRESS TASKS

There never seems to be a good time for orchestrating a smooth handoff, especially if the exiting party is unaware of the upcoming transition. I wanted to keep the in-motion product initiatives moving forward and that meant digging a little deeper into this PM's stories and tasks than I would normally have to.

And because this particular PM had been struggling over the past few months, I had even more to do to assess the deficiencies of the latest rounds of work. It took a few days to get a good feel for the situation and what I would need to do to redistribute the work during the interim while we were recruiting a replacement PM.

HEad Off Office Gossip

In most offices above a certain size, there is inevitably going to be some water cooler chatter about personnel changes. This is especially true when an employee is asked to leave versus choosing to make that decision on his or her own.

I prefer to handle the former with very little fanfare and save the goodbye lunches for the latter. To keep the whispers and rumors to a minimum, I spoke briefly to each department about the exiting PM and focused the conversation on our plans to bring on and ramp up a new, stronger resource to reinforce our commitment to the company.

The impact

You may have recently come across some prevailing advice that recommends young, fast moving companies fire fast and hire slow (see here and here for example). And while there is room for healthy debate about the idea of taking your time to find the right next employee, there seems to be near universal agreement about getting rid of dead weight as soon as possible.

I knew I had made the right decision but the lack of any real surprise from the rest of the organization made me wonder if I had acted soon enough. Nevertheless, there is general consensus that the company is now better off and we collectively looking forward to a new PM to strengthen the team and help move the product forward.

Look for more reports from theProductPath around PM credibility and managing product teams here on PM Decisions.

More articles from our blog PM Decisions

Create an in-person event to engage your customers

Image source: https://www.flickr.com/photos/highwaysagency/5997001123/

In realizing I had not spoken directly with our customers in some time, I decided it was time to get out of the building.

With a major software release right around the corner and being short a Product Manager due to a recent exit, the team was justifiably busy. There was plenty to do with making sure the upcoming deployment went smoothly while also firming up our plans for the very next release. And then there were the myriad other tasks that were on our plate, making it easy to rationalize that there simply was no time in the schedule to step away to talk to our customers.

But let's be honest here. By not making the time to engage your customers, all your other product plans are likely to fail.

What drove this decision

I was starting to get that gnaw in my stomach, the one that comes from making too many uninformed decisions. Because, no matter how confident you may be in setting the direction of your product(s), there is nothing more validating than getting direct feedback from your customer base.

Our Product team had been fairly diligent about reaching out to our users on a regular basis but many of those conversations are virtual and there is often a communication gap with phone calls and web-based meetings. I was eager to get some good face-to-face interaction with our target customers, to hear what they liked about our software, to learn what we could do to help them accomplish more, and to share where we were headed with our new roadmap. 

Image source: https://www.flickr.com/photos/mdd/9890924226

The decision: Leave the building (and the city) and spend some quality face time with a group of customers representing a good cross section of our users. 

As hesitant as I was about disappearing from the office for a few days, I knew the in-person discussions would more than compensate. And the plan for this particular trip was to spend a half-day with more than just 1 or 2 customers, so I knew I would return with a good assortment of responses to share with the team.

Plan of attack

Our Customer Success team is in the (good) habit of reaching out to new and existing customers in order to follow up with ongoing implementation initiatives and also to promote the Art of the Possible. We decided to make this event a twofer, extending their standard agenda with a short, product-specific program.

Build Simple Customer Profiles

Before "leaving the building", the first order of business was to gather some intel about the attendees with whom I would be meeting. Together with our Sales and Professional Services teams, I put together some brief customer profiles, paying specific attention to their specific use case and, as a crude gauge of their comfort level with the product, how long they had been users of our system.

This gave me some good, initial context for the level of discussion I would likely be having and helped me refine the scope of the topics I could cover. 

Create an Engaging Presentation

I know that very few people look forward to watching a PowerPoint presentation but, when done well, a good slide deck can be an ideal way to communicate ideas with a large audience.

For this event, I pulled together a series of slides that I thought would keep their attention and, more specifically, prompt some honest discussion among the group. For example, I included in the deck:

• A high-level, vendor's perspective of their business problem, showing how the company views their particular customer scenarios and intended to trigger dialog around exceptions and edge cases;
• Annotated screenshots of recently-introduced product features that they may not have had a chance to play with but would take too much time to demo completely, meant to spark conversation around additional exploration and use of the product;
• And a 1-page Product Roadmap that communicated, in broad strokes and without specific dates, the priority of particular product initiatives related to their use cases, designed to stimulate feedback and confirm we were on the right track. 

Days before the event, I reviewed the material with my team, incorporating some great, internal feedback while also rehearsing the presentation flow.

Demo, Survey, Preview, Recruit

There was a lot to squeeze into the time slot we had carved out for my Product talk. I wanted to promote the current state of the product and explain how and where we were looking to make enhancements. I had brought along some early, high fidelity prototypes in case we hit on a particularly popular or sensitive topic. I also was hoping to conduct a brief survey to get feedback on a number of our product roadmap intentions. And finally, I had hoped to recruit some of the customers into our more formal "labs" program so we could follow up with more intense analysis.

Other than a few weather-related, last minute cancellations, the meeting went off without a hitch. The participants seemed pleased with having direct access to the Product organization and appreciated the brief glimpse into the company's product strategy. Many of them have since enrolled in the more structured labs program and have indicated a strong preference to stay engaged with us.

Share Results With the Product Team

I returned to the office the next week eager to review the notes with the Product team. And while it seems there is never sufficient time to fully digest results of customer interviews and surveys, I was able to share a synopsis of the event and fold much of the feedback into our (still crude) research database.  

The impact

The good news is that the majority of the feedback validated our current product plans, at least for the next few major releases. It is certainly helpful to hear from your own customers that the product is indeed solving their needs. There were some familiar "hot spots" and valid complaints from the group and this has led to some re-prioritization work on our side that might not have been prompted by an interview with a single customer.

I strongly suspect there will be more such events in our future and that, as we continue to strengthen our outreach efforts, we will find it increasingly easier to get out of the building.   

Look for more reports from theProductPath around customer research, product validation, and voice of the customer 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

Make Product Decisions Like Cagan

Image sources: https://www.flickr.com/photos/68751915@N05/6848823919, https://www.flickr.com/photos/nataliedowne/6446884983, https://www.flickr.com/photos/norue/9625271288

In what many Product Managers might consider an average week, I made three classic product decisions that would make Marty Cagan smile.

After spending more than 10 years in the Product Manager role, I can't actually recall an average week. Perhaps we are attracted to the role for that reason - because it is unpredictable. If it's not changing requirements at one end, then it might be new technology "insights" at the other. The cast of characters we will work with week to week is variable too as new customer prospects enter the picture and compete for attention with existing customers that have their own unending wish lists.

To be successful, Product Managers must be able to navigate these challenges week to week. Good mental frameworks are essential to making sound decisions and to maintaining credibility over time. When you are feeling overwhelmed, however, you may find it helpful to confront the tough product decisions with this deceptively simple approach.

Inspired - How to Create Products Customers Love by Marty Cagan

What drove these decisions

Most Product Managers have run across Marty Cagan’s book Inspired - How to Create Products Customers Love. I consider it a must read for anyone in the general vicinity of Product Management.

Among the many gems in this book, Cagan identifies three fundamentals ways to validate your product decisions: determine what's valuable for your customers, what is usable by your users (not always the same personas as the actual buyer), and what is feasible given the resources you have at your disposal.

These are not mutually exclusive. Whether you're early in your product discovery or tackling a thorny issue for customer 10,001, you need to land on a resolution that best balances these three forces in order to move forward.

Over time, with practice, this starts to become instinctual and woven into your daily PM routine. You may even be surprised, as I was, in reflecting back on an "average" week that there is a very valid reason for why many of your product decisions had turned out so well. 

The Three Product Decisions: Determine what was most valuable for our customers, what was most usable by our end users, and what was most feasible according to our Engineering team.

In this particular week, I made and can highlight three, separate decisions for our product and ultimately, for the future success of our company.  What makes these particular decisions stand out from the dozens I made is that each was particularly punctuated by one of Cagan's three principles. 

Plan of attack

Decision 1 - What’s MOST Valuable

The team had been exploring how we could redesign an existing product feature and was driving that discussion using input we had gathered from rounds of customer testing. As we unwound the different pieces of the story, we revealed the true underlying complexity and ultimately determined that it was too big to tackle all at once.

I decided to break up the larger story into 3 smaller, discrete pieces and sequence the resulting work to deliver incremental improvements over time - a common problem solving approach. But this decision made it much easier for the team to single out which piece would ultimately provide the most value to our customers and, all other dependencies aside, which we would schedule first.

Decision 2 - What’s MOST Usable

In a separate thread, the team was reviewing feedback we received after showing a proposed new design to some of our end users. We had been planning to introduce a completely new design to address some known usability problems with a particularly popular feature.

Few things are more influential for a Product Manager than hearing end users describe how they use, or would use your product to do their job. It was precisely this feedback, straight from our users' mouths, that prompted me to scale back the new design. It turns out that we had been overthinking the problem and could actually deliver a more usable solution with fewer changes (i.e. less work on our end).

Decision 3 - What’s MOST Feasible

Software Engineers like to explore new technology. I know this from having spent the first 10 years of my career as an enterprise software developer. In this current company, I had been having conversations with the Engineering team about how we would tackle a large, scale-related challenge deep in the bowels of the platform (not customer facing). The team had fully researched and had achieved some early success with an alternative technology that seemed applicable for this particular problem.

So, in this very same week, we had come to a point where I needed to make the call on whether to schedule the scale-related work for an upcoming release. And while the Engineering team was convinced the technology would ultimately solve our challenge, we were not jointly confident in our collective ability to proceed safely. Because of this uncertainty around technical feasibility, I swapped out the work from the release, postponing it for a later date after more research and experimentation could be done.

The impact

As I mentioned at the start, these types of decisions are commonplace in a Product Manager's average week: problem decomposition to help reveal customer value, user testing to help reveal usability concerns, and ongoing engineering R&D to help reveal feasibility limitations. Still, it never hurts to return to some of the core product principles to remind us all why we are here. And thank you Marty Cagan for all your contributions, and for inspiring me.  

Look for more reports from theProductPath around Product Feasibility, Usability, and Value here on PM Decisions.

More articles from our blog PM Decisions

Repave the road...map

Image source: https://www.flickr.com/photos/willemvanbergen/4498186500

After inheriting a weathered product roadmap whose years of wear and tear had been the source of chronic problems for our company, I decided to fortify its very foundation.   

Like many early stage companies, we had been struggling with product direction, with making and keeping promises to customers, and with overall Engineering churn. The source of many of these problems was a Product Roadmap that frequently over committed and that failed to adhere to any consistent vision.

What drove this decision

It's fair to say that no one expects every promise to come true. And that holds for product roadmaps as well. Roadmaps are simply a plan that drives towards some future state of your product and as Eisenhower famously said, "Plans are nothing, planning is everything".

Some Product Managers get into trouble when they get too specific about future plans and end up prematurely commit to features and dates in their roadmaps. This was a perpetual problem at my company and over the years, our credibility with customers and prospects as well as with internal sales & support teams had deteriorated.

The change in leadership on the Product team presented me with an opportunity to address the problem head on but that would require some real road(map) construction work.

Image source: https://www.flickr.com/photos/seattlemunicipalarchives/3749710569

The decision: Repair the roadmap infrastructure

There are quite a few good sources on the Internet that describe proven techniques for constructing sound product roadmaps and bolstering product planning efforts. Indeed, the tactics described here are not fundamentally revolutionary. What is novel perhaps, is how, with a few straightforward changes to how we built and socialized our product roadmap, we were able to directly address and ultimately improve the Product team's credibility.

Plan of attack

We identified and committed to three changes (at least in this first phase of construction) that would yield the most value for our stakeholders. They are not mutually dependent and could be done in any order.

Use 3/6/12 months increments

We immediately dropped the former convention of spelling out exact release dates in the roadmap. Instead of prematurely committing to specific monthly releases, for example, we create a 3/6/12 month plan. Because our confidence was much higher in the short term feature enhancements, we described these in more detail on the roadmap. And we decreased the level of detail around features as we moved into the six- and 12-month phases.

This change shifted the focus away from specific dates and to the prioritization and staging of the work itself.

“We use high-level themes because it makes communication simpler and allows us to keep uncertain details vague. It also helps to limit scope creep – if a request for a new feature doesn’t align with the agreed themes then it’s easy to push back. The use of themes, combined with broad delivery windows as we move into the future, helps us to be more confident that we can deliver what’s on the roadmap.”

— Roadmap issue of the Product Management Journal, vol 9, pg 7.

Create themes for prioritizing product decisions

Roadmaps that stretch out for months or years can be complicated and unwieldy for the newcomer. It is difficult to capture all the finer points of a Roadmap in a high-level, visual chart or to communicate all the thinking that went into developing it.

To make our Roadmap easier for others outside the Product team to consume, we introduced and described a few themes. These themes helped to visually connect different units of work so that the causal observer could find order in the abundance of features.

The themes helped our audience to better understand our decision process. For instance, we could show how when a particular feature on the roadmap aligned with multiple themes it was given higher priority over other features. 

Separate commitments from candidates

There is another simple technique that roadmappers can employ to avoid making explicit promises, especially when facing increased uncertainty about the ability to deliver features far down the road.

On any/all external facing versions of your roadmap, you include a graph that has two opposite endpoints: Commitments and Candidates. The features about which you feel more confident, likely the ones you will tackle sooner, will appear on the Commitment end of the graph. The features that are further out in the future will inevitably be designated as Candidates on the graph.

While this tactic might seem obvious to you and your Product team, it will help to set the proper expectations with your stakeholders and help you stave off unproductive conversations around future roadmap commitments. 

The impact

I published the updated Product Roadmap at the beginning of the year with these three improvements: 3/6/12 month timelines, high-level themes, and a commitment/candidate graph. And, while the changes were relatively simple, the outcome was significant. Product conversations with internal and external audiences were more focused. Our team spent less time explaining or defending our decisions and more time engaging stakeholders in productive dialogue about solving important customer challenges. 

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

More articles from our blog PM Decisions

Create a reference application for our software platform

Image source: https://www.flickr.com/photos/kovah/15518650302

Looking to better promote our full-featured software platform to external developers, I decided we should lead by example.

After investing a great deal of energy in overhauling the publicly available programming interface to our cloud-based platform, our company was ready to release it to the masses. Our marketing team was developing a campaign to promote our revamped REST API but I felt that something was missing.    

What drove this decision

Our original, SOAP-based programming interface, while feature-rich, was considered outdated and had truly lost favor with external software developers. It was time to embrace the new RESTful paradigm and we knew that we had some work to do to reengage this audience.

So, in tandem with the launch of the new REST API itself, the company was erecting a developer-focused, community-style web site to include a full set of method-level documentation and source code examples. We also planned to highlight a few partners and customers that had invested in the new API and who had built their own integrations to our platform. 

But to really show off the power of this new API, to lead by example, we needed to do even more.

Image sources: https://www.flickr.com/photos/76886703@N00/6094026942, https://www.flickr.com/photos/sometoast/1405380577

The decision: Build our own API-based application as a reference model for the developer community

Several months before this decision, our Product team had started plans to deliver a lightweight, mobile-friendly application that would help our customers gain insight into the business processes that they were automating with our platform. However, we had not landed on the specific architecture we would use to build this new application.

This decision to create a reference app for the REST interface helped us connect a few important dots. We now had a path forward that would showcase the new API while also delivering value to our customer base. 

Plan of attack

To pull this off, we first had to put ourselves in the mindset of the external developer - which was a bit harder than we expected. We would build our new mobile application as if we were operating entirely from outside the organization. We would try to limit our use of any internal tools or frameworks to artificially accelerate development or to negotiate deployment shortcuts. Only after we went through what our target audience would experience would we truly appreciate the effort involved.

The details of our implementation, which covers everything from negotiating API keys, session authentication and runtime usage governors to UX library components, responsive design, and error handling are beyond the scope of this post. What is more interesting perhaps is that we decided to chronicle the entire experience and share it publicly on the developer community site.  

The impact

The greatest impact of this decision was a delay in getting our new mobile application to market. Choosing to go the full API route resulted in more time being spent configuring and troubleshooting the code for our mobile application - AND debugging the API itself.

There were up front costs and delays while we developed a parallel release environment and deployment schedule, separate from our primary code base; however, this ultimately helped us deliver iterations of the mobile application much more frequently as it could evolve independently without any direct dependencies on the underlying platform.

In the end, we would deliver our mobile application to happy customers who were completely unaware of our internal implementation decisions. But the payoff was magnified as we also delivered a complete application blueprint to external developers looking to embrace the platform. 

Look for more reports from theProductPath around product investments, go to market choices, and software platform promotion here on PM Decisions.

More articles from our blog PM Decisions

Reset expectations around Engineering capacity

In recognizing that many of our company's developers had been committed to important engineering tasks unrelated to advancing product features, I decided to clearly illustrate our true capacity for product innovation.

The pressure on a Product Manager can be intense at times. On the one hand, you are responsible for answering the deceptively simple question, "what are we planning to do next?" All eyes are turned to you for long term product strategy and the product roadmap. And as the owner of the product roadmap, you will have no shortage of helpful suggestions streaming in, from many strong voices, constantly weighing in on what they think should be done.

Perhaps just as stressful though, is having to address the related but more nagging question, "why can't we get more done?" This was a recurring question in my company as many stakeholders were eager to see us move faster. 

“Why can’t we move faster?”
”Why can’t we get more done?”

These are fair questions from well-meaning people but it didn't take long for me to realize that there was a fundamental misunderstanding at the senior leadership level about our true capacity for product development. 

What drove this decision

If you are not directly attached in some way to the software development machinery in your company, then chances are you don't have a good appreciation for all that goes into building solid product features. The decisions that are made by Designers, Engineers, QA, and Operations are just as foreign to other groups as the inner workings of Sales, Marketing, and Finance are to us software types. In our company, though, there was growing frustration with the lack of progress being made on the product side.

The software team I joined had indeed struggled, missing targets, dropping features right before a big release, and generally falling victim to interruptions and emergencies. We have a strong Engineering team but a good number of them were being assigned to tasks that, while important to the company, were not contributing to product innovation.

In my new role as PM, I had a plan to begin a new chapter for product development at our company. Success would depend on building credibility early with stakeholders and a big part of that meant resetting some expectations. Specifically, I would need to explain why I would not be able to achieve as much as they had been expecting. I would have to justify why we weren’t able to accomplish more.

Image source: https://www.flickr.com/photos/jurvetson/2292656889

The decision: Publish a straightforward model that would clarify our actual capacity.

Through a number of internal meetings, I learned that members of our talented engineering team had been assigned to work on internal projects such as scaling our core software platform and optimizing our development process. Other team members were allocated to team management or committed to rotating assignments with Customer Support.

The net impact was that the size of our Engineering team had been reduced. The remaining developers were available to work with my Product team on new features but would also have to address bugs that cropped up. Then there were research tasks that did not directly yield new software but would certainly benefit future development. And finally, we had to plan around holidays, vacation days, sick days, and any scheduled technical training.

All in all, there are far fewer available cycles in a Release than one might think.

To clarify our true output capacity to our senior management team, I built a simple scoreboard of sorts for each release that showed how many FTEs were available for product development.

Plan of attack

Normally, I'd relish an opportunity to build some elaborate model but in this case there was no need for fancy diagrams. Instead, I created a simple picture using PowerPoint, similar to the image at the top of this post.

I started by using squares to represent each engineering resource making it easy to visually determine the total number of Engineers on staff. Then, using different colors for each bucket, I identified how many engineers were being assigned to non-product initiatives and labeled each initiative appropriately. I chose to omit specific names in the diagram, even when it was obvious (e.g. team leads).

The result? A clear model that illustrated our company's actual product development capacity.  

The impact

You could disparage this approach and claim that I had prematurely adopted a defensive posture or taken a pre-emptive CYA step. But our senior leadership team was overdue for a reset. In the weeks that followed, in conversation after conversation I used the diagram to remind everyone exactly why we could NOT move faster.

This led to more productive discussions about resource allocation, hiring decisions, and generally rearranging priorities. And to me, those are the right kind of questions to debate.

Look for more reports from theProductPath around capacity planning, communicating with charts, and working with stakeholders here on PM Decisions.

More articles from our blog PM Decisions

Campaign for early Product Roadmap support

Image source: https://www.flickr.com/photos/amycgx/3119640267

To increase the chances that the new Product Roadmap (and my first here) would win favor throughout the company, I decided to conduct a campaign to build early support for the Roadmap itself.

As the new guy now leading the Product team, I had my hands full getting up to speed in the first few weeks. My immediate concern was keeping the current Release on track but the greater challenge was creating a new Product Roadmap for the upcoming year and rapidly drumming up support within the company.

What drove this decision

Taking over a Product team at the beginning of a calendar year has some additional pressures as you might expect. Many internal and external parties are looking for clear indications of the overall product direction, the most concrete of which is the Product Roadmap.

Our company likes to kick off the new year with a rousing, all-hands pep rally for the entire company and one of the meeting's big agenda topics is the presentation of the refreshed Product Roadmap. A big reveal from me that early on would be risky as I hadn't built up sufficient credibility by that point. And with just a few weeks into this PM role, I really hadn’t hadn't been able to speak with as many departments as I had hoped. To pull this off, I needed to build a groundswell of support by having the various department weigh in on, or at least preview the Roadmap before I tried to broadcast it to the masses.

Image source: https://www.flickr.com/photos/israel-mfa/14616944000

The decision: Build support for the new Product Roadmap in stages

My ultimate goal was to present my new Product Roadmap to a room full of supporters. To improve my chances, I started a somewhat calculated crusade to win friends and influence people all around the company.

Plan of attack

There is no one, obvious way to plan a campaign like this but the strategy I recommend is to start small and with people whose opinions you value and push them to poke holes in your product strategy before moving to the next group. I have outlined the approach I took which proved successful.

Start with just the Product team

I began the exercise with my own Product team, perhaps the most empathetic of the groups I would encounter. These folks were the most patient and, because their future paths were most closely linked to the Roadmap, the most eager to engage. With this group's help, I was able to get my initial story straight, confirm the overall themes, and plug some minor gaps in the strategy.

run the roadmap past the Sales Engineers

The next audience I sought, though discretely, was with the Sales Engineers. I had worked closely with this team in the past and knew they would be supportive. I trust their general feedback but it was also important for me to vet out some of the key product decisions with someone who interacted more frequently and directly with our prospects and customers.

pitch to the Key Stakeholders

With my confidence growing, I moved on, skipping over the individual departments to gather all the stakeholders in a room. As you might expect, this group of department heads, their bosses and our senior leadership team is composed of a great number of strong personalities. But when invited to sit alongside their peers, even the feistiest individuals will often tamp down their protests, yielding to and general supporting the views of the larger group. I found this to be the case with my Roadmap presentation and used the inferred approval from the group to launch into the home stretch.

present to Individual Departments

With support from the top, I proceeded to set up separate meetings with each major department including Engineering, Operations, QA, and Customer Support. In each meeting, I tried to highlight those parts of the Roadmap that I thought would appeal most to each group. This proved valuable later, in the larger setting when I was able to direct different topics to specific members of the audience, with the effect of making it seem as though they had already endorsed the individual ideas.

Announce to the Entire company

The final stop in the campaign of dreams was pitching the Roadmap to the entire company. At that point of course, through all my previous efforts, I had eliminated the element of surprise. I had effectively planted sympathetic individuals in the crowd who consciously or not, were giving me the nods of support I needed.

And, while there was no thunderous applause at the end of my presentation, I did get relatively high marks for a "new guy". In fact, a number of people approached me afterwards with positive feedback and great suggestions about how to further socialize the Roadmap internally. For example, we decided to start using the many monitors hung on the walls throughout our office to track our Roadmap progress over the coming weeks & months. 

The impact

When I look back, it is obvious to me that this kind of approach to build internal support takes more cycles than one big reveal. Meeting with each team, one at a time and reviewing the Roadmap over and over was certainly more work in the short term but has paid off. I still have to demonstrate that we can achieve what was promised but I should not be spending as many cycles defending the Roadmap itself.

Look for more reports from theProductPath around product roadmaps, promoting product ideas and working with stakeholders here on PM Decisions.  

More articles from our blog PM Decisions