Pump the brakes on a customer 1-off request

Image source: https://www.flickr.com/photos/orijinal/5024019897

Having joined an in-progress Release with work related to a feature request from a single (but high-valued) customer, I decided to scale back the implementation and promotion of the team’s work.

The 1-off customer request is a familiar challenge for Product Managers. It often appears in tough times, like when the Sales team hits a rough patch and starts to relax the deal qualification criteria a bit. Or when the company's Customer Support team is at the end of their rope trying to rescue an unhappy customer. My predecessor had saddled me, in my new PM role, with the latter. When I stepped in, Engineering had already begun development on a feature request intended to satisfy a single customer in peril.

What drove this decision

As a rule, I don't release software to my customers that I haven't first validated with a set of sample users. And while I appreciate that a business needs to listen and respond to its customers, when I hear “we need to do xyz because this (big) customer needs it”, alarm bells go off in my head. As Product Managers, we know better than to respond with some hasty enhancement - especially if we know only one customer is likely to need or use it.

So when I sat down with the Developers to review this request, I realized that we were about to build (and later release!) some terrible software. It was fairly obvious that we had cut almost every corner to get it done quickly. We did not have sufficient insight into how we could properly address what was likely a more recurring customer issue. What was currently scoped was only narrowly solving this particular customer's current pain and on top of that, they had given the new feature a misleading name that would have created even more challenges down the road. 

The decision: Restrict the new, hastily built feature

Image source: https://www.flickr.com/photos/kewl/8393213472

In a single ruling, I effectively downgraded the feature for the current release and postponed its full arrival indefinitely pending additional customer input.

Rather than disappoint our customer by pulling the feature entirely, I re-scoped the development work to produce an adequate but scaled-down solution. Through subsequent testing, we confirmed that this indeed satisfied our customer's pain. But perhaps more importantly, we found a clean way to deploy the software so that it would NOT be accessible to any of our other customers.

Actually it took a few more steps to get us back on track.  

Plan of attack

As I mentioned earlier, this train had already left the station. I was joining the project mid-stream so I needed a way to unwind some of the activity that was already in motion.

Limited feature preview

Our company regularly shares the ongoing engineering progress with a larger audience. In order to limit exposure, I chose to pull the feature from any and all company-wide previews. Instead, we invited only our internal Account Reps who work directly with the customer to preview and validate the work. And with their approval, we moved forward with the customer who ultimately gave us a thumbs up and who completely understood our decision to pause any additional work until we could do more discovery around the greater problem.

Schedule additional discovery

Realizing that the team could use more time to research this feature with other customers, I assigned a Product Manager to work with our Customer Success team to identify other customers with similar needs. Having addressed the immediate pain of this first and only customer, we could now proceed with proper requirements gathering and look to build the product feature correctly.    

Bury the feature in the official Release

And finally, so that I could hide this premature feature from our other customers and even from our Marketing and Sales teams, I concealed the feature by leaving it out of the external facing Release Notes.

The impact

The outcome of this decision was favorable to all. We had effectively addressed a real pain for this customer - even if they were currently the only one who seemed so far to have the problem. Our Customer Support team who had prompted the work was... not unhappy and now had some homework to do to find more pain in the customer base. And the Engineering team, who tends to favor intentional and rational decisions, was pleased, if not impressed.

Look for more reports from theProductPath around feature scoping and the need for customer research 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

Jotting down the product path

Last month, as 2014 came to an end, we also celebrated the first full year of operating theProductPath. We are of course thankful for all of you who have helped us get off the ground and now look forward to the new year.

One of the new initiatives for 2015 is this blog, PM Decisions. Over this year, we will share excerpts from our own product-related travels and have committed to engaging other PMs on a variety of topics. Theses posts will primarily focus on notable decisions that helped drive the direction of one or more products. Starting here in January, we will begin capturing and organizing our PM decisions with the intent that some parts of the growing collection will help you with your own product decisions.

As you likely know, it takes a special kind of person to want to step into the disparate and often thankless role of a Product Manager. We understand that journey and invite you to join us as we begin jotting down theProductPath.