A few days ago I had lunch with the product team of a mid-sized software company, and one of the product managers had a conundrum:
“Sometimes I hear the same feature request over and over, but when we finally release it customers barely use it.”
Does that sound familiar? How can we as product managers avoid these dead weight features?
How can we determine whether to 1.) implement a feature exactly as customers request, 2.) defer it, or 3.) deliver something that is completely different than requested but solves the core problem?
In my experience, good product managers often combine all three (especially the deferring part). But for the features you decide to include on the roadmap, there is one practice that can help you make sure they will add value and get used:
I’m assuming you’ve already nailed the basics: You have a process for validating prototypes with customers, and once you release a feature, you have the metrics to measure the success of the feature.
“I need a feature called…”
Before ProductPlan I worked for a SaaS company developing business software for vertical markets. The software was complex, including accounting, CRM, and marketing. Every customer came to our solution from another solution, and they often came to us with a pre-conceived mindset about what features the software needed to have. We routinely got requests for features and reports that (surprise) mirrored exactly what they were using in their previous solution.
Sure, it would have probably satisfied the customers to simply add the button, feature, or report they asked for.
But through understanding the job they were trying to accomplish we were able to imagine solutions that they were not able to imagine themselves, and deliver features that completely revolutionized their workflow.
Case Study: Eliminating Hours of Work with a Few Clicks
With their previous solution, our customers would print out reports that needed to be produced every month. In some cases this process would last for days; printing hundreds of reports, collating them, attaching checks, and stuffing it all into manila envelopes to be mailed.
It was a cumbersome, horrible process. Some even had family and children join them for “stuffing parties” because it was so time consuming. But this was a part of their life and they expected our software to support this workflow with the appropriate reports, printing, and buttons, and so on.
Before building our solution, we spent hours onsite at the offices of our early prospects to understand their workflow, hear their pain points, see the stacks of paper on their desk, and internalize what they were really trying to accomplish. We watched over their shoulder, asked a lot of open-ended questions, shot hours of video, and ate (too many) donuts with them in the break room.
We thoroughly understood the job they needed to accomplish: delivering reliable information and payments to their customers (to be clear, the job was not printing reports and mailing checks). We envisioned how their life could be different by using the latest technology to optimize their workflow. We knew how it could improve their business and how much money they would be saving if we could shave hours off their process by moving the information and payments electronically. Once we understood that, we were able to release innovative features that our customers hadn’t considered or thought possible.
For our customers, what previously took hours or days could now be accomplished in a few clicks. The results were wildly successful features that contributed to our customers becoming huge promoters of the software.
Not every feature needs to be re-imagined. Sometimes there is low hanging fruit you can deliver that happens to match exactly what customers request. But there are often features that warrant further digging to really understand the job the customer is trying to accomplish, and get the right initiatives onto your product roadmap.