Pull a large MVP-less feature from the next release

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

In recognizing that an important but poorly scoped product initiative was slipping further behind, I decided to push it farther back on the roadmap.

I would argue that our organization is actually quite Agile-minded but we have more work to do before we can start scheduling product releases in units of weeks rather than months. In our current state, we have to treat releases with a bit more care as they don't come around that often. So when we target a major product initiative to be completed and deployed in a future release, it is critical that we drive toward the date. Any slip could delay the feature by a month or more and that can have significant customer implications.

I had recently given one of the PMs on my team a real juicy assignment. We had determined, through some solid customer research, that one of the core features of the platform was in need of an overhaul. In matching up usage data with anecdotal user feedback, we recognized that the problems would require more than a few simple enhancements. This was indeed a large product initiative and was lining up to be one of our strategic product achievements for this year. 

One of the core features of the platform was in need of an overhaul.

What drove this decision

We had been wrestling with all the usual challenges of developing a new product feature on a tight schedule. Some requirements required further clarification. Web page and email designs required rounds of tweaking and tuning. Plus the Engineers were being pulled away periodically to troubleshoot and fix other, non-related bugs. And then there was the Operations team who had planned a major infrastructure upgrade that created additional chaos, especially as we depended on those same resources to deploy the new feature.

I could go on, listing distractions and blaming other parties. But the number one reason for the slippage was simply subpar product planning. The PM had not done a good job in decomposing and staging the required work. After a few months, we had created some great new software but no shippable product. 

The decision: Drop the feature from the next major product release and reinvest in some proper scoping

About a month before the next big release, it had become increasingly clear that we would not finish developing the feature in time to validate it thoroughly with our users. In our culture, we place a high value on both sticking to our release dates and only shipping product features that are user tested. The first constraint often governs the second.

The decision to drop the feature at this point in the release schedule may have been a bit precarious. But it was really only the first step in a series of related actions that kept the Product and Engineering teams busy for some time. 

Plan of attack

As it turned out, our poor product planning had resulted in even more work than you might expect from what seems like a straightforward decision. We desperately needed to put this particular feature back on the right path but there were now some additional tasks that would enter the work stream.  

REVERT TO THE OLD FEATURE

So confident had we been in our ability to complete this feature (including functional, performance, and user testing) that the team had started dismantling the legacy functionality.

Now we had to re-mantle it. Or more specifically, we had to back out some of the new enhancements in order to restore the old feature. No self-respecting Engineer enjoys this kind of work and indeed it cost the Product Team dearly in terms of credibility.

ADD A FEATURE TOGGLE

In order to preserve the progress that had been made, we invested some additional time in creating a true feature toggle that would allow us to enable the new version for individual customers. This provided us with the option to conditionally test the new functionality, as soon as it was available, with some of our more curious and perhaps more forgiving users.

RE-SCOPE AND RE-PLAN THE FEATURE

The bulk of the work came from decomposing the originally planned feature into smaller stories and creating a revised, incremental delivery plan that would help us deliver a true MVP first and then, in subsequent iterations, a series of progressive improvements.

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

I will not use this report to describe the detailed process of scoping a product feature. There are many good discussions around discovering the Minimum Viable Product or MVP. To be sure, it takes practice to learn how to be ruthless. Good PMs find ways to whittle away at a product or feature until there are no nonessential elements remaining.

But it takes a different set of skills to then carefully plan the gradual introduction of those elements over time. It can be tempting to load up on enhancements, especially as product adoption increases among customers and users. Discipline and care are traits to be nurtured and celebrated in your Product Managers.

RESET EXPECTATIONS

As I mentioned earlier, this feature, when complete, is intended to make a big splash with customers. In making the decision to postpone its deployment, I now had the delicate task of resetting expectations with our Sales team, with Professional Services and Support teams, and with the few customers and prospects we had been engaging with for testing and research.

The impact

The existing customers and new prospects that were pining for this feature were disappointed with the decision to pull and postpone though I believe the blow was cushioned in two ways. First, we notified them of our product decision several weeks ahead of the release instead of only days before or even worse, after the release.

Second, we took care to explain that we did not feel comfortable pushing a significant new product feature without appropriate user testing. Not to say that this relieved all the anxiety but it is more difficult to argue with the choice of product quality over speed to market.

One final note. The Product team did consider moving ahead with a nearly complete version of the new feature and including it in the upcoming release. The thought was that we would have the ability to turn it on for a few, select customers in exchange for some heavy usability testing. I will publish more on that approach in a separate article.

Look for more reports from theProductPath around planning products and releases, MVPs, and product culture 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

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