This week Billtrust launched a major new version of our flagship product CustomerCare. CustomerCare is our online archiving and reporting tool that allows customers to easily view all of their billing activity in realtime. This tool has been a home run for our customers with thousands logging on every day to better serve their end customers. I'd like to say I had this grand vision of building this product from the beginning, but the reality is much different.
One of our first customers back in 2002 asked for copies of their bills burned to a CD for archiving purposes. Seemed like a good idea, they wanted a permanent record just in case they needed to get a copy of a bill. We charged them a little bit for our time and effort, everybody's happy.
I visited this client several months after they went live to check how they were doing. They proudly showed me their "CD Binder" that contained all the CDs we had sent them and told me how much easier things were now that they could grab copies off of the CD once they figured out which CD it was on. I asked how often they did this, and they replied "a couple dozen times per day". This was the light bulb moment for CustomerCare. Never did I imagine that they would be using these CDs regularly. I fell into the trap of giving them what they wanted instead of first asking what problem they were trying to solve.
CustomerCare started out as web version of the CD archive but has grown into all encompassing self service tool with reporting, resending, configuration, marketing and much more.
Figuring out what to put in a new release of a product is a bit of an art. A lot of people design software based on customer requests. This sounds good, who wouldn't want to give the customer what they want. The problem is that you wind up with a lot of "CD Archive" products that may solve the problem, but not in the best way.
We take a different approach. We of course listen to what our customers say. We have a formal Customer Advisory Council that gives us ideas, we periodically survey our entire customer base, and our sales people are always funneling in new requests. This is great stuff but is just one piece to the puzzle.
We break new release capabilities into 4 distinct areas
- Bug Fixes - yes, unfortunately sometimes bugs creep in
- Customer Requests - as described above, some of the best stuff comes from customers
- Continuous Innovations - these are advancements to a specific area of functionality that we have a good feeling customers would like, but they're just not asking for them
- Discontinuous Innovations - These are the most fun. Whole new areas of functionality that solve big business problems, and the customers don't even know they have the problem.
“Figuring out what to put in a new release of a product is a bit of an art. A lot of people design software based on customer requests. This sounds good, who wouldn't want to give the customer what they want. The problem is that you wind up with a lot of "CD Archive" products that may solve the problem, but not in the best way.”
Hallelujah!
One of my pet peeves and why I love competing against so called “customer focused” companies. Too many companies follow that rote process of doing exactly what their customers asked for. And they wonder why they end up rewriting the code when the customer isn’t happy with the solution!
The value and expertise a software company (or any other product company) brings to a customer is their knowledge of how to apply technical solutions to solve a business problem or opportunity. If my customer builds widgets, I expect them to be experts at their business and my job is to listen, learn their business as best I can through lots of questions and help discover their business problems that can be solved by my technology (oh and relate that to other customers so I have a market to sell to and not just one customer). After all, if they knew how to build software they’d be in the widgets and software business.
The other problem with this approach is you end up building features to support “the next big deal”. Driven by sales who say “I have to have this feature, this way and by this date to make the sale”. Too many software companies fall into this easy trap as well. While it may be a great and valuable idea, more often than not it isn’t (oh and by the way you would have made the sale anyway). Sometimes you do need it to make the one sale, but you’ve now diverted resources away from what you planned to build on your roadmap that would have driven ten sales. Other times you build it and it’s a one off solution only used by that one customer that you now have to support for the life of the product sucking resources needed by the larger market. What should be driving the product and whether or not a feature should be built and when is:
- Does this solve a common problem that my market (or a new market) has? If not, you’ve got better things to do.
- Does this address risks that my market faces (e.g. regulatory compliance, security)? Less sexy and fun, but absolutely necessary
- Is this enough of a problem that my market is willing to pay for that solution? Software isn’t built for free. There are lots of business problems out there but if it’s not enough of a pain for the customer or the solution is technically challenging and therefore costly to build that you won’t recoup your costs, time to drop that item off the enhancement list or bury it at the bottom.
At the risk of offending you, I have to slightly disagree with your list of release capabilities though. However, it may just be semantics. In my mind there are just two – fix the inevitable bugs and address market needs.
The semantics are I agree with the categorization but #2-4 really are (or should be) the same thing. In all cases, when deciding how to prioritize and commit precious resources it should all be based on market (not a singular customer – important distinction) needs.
The semantic difference is whether or not the customer has articulated the problem/opportunity and expects you to solve it or you’ve discovered it through your interaction and understanding of the market and solved it when they didn’t ask for it. In my mind, they are the same thing. As for #4, I know where your going but it unless your in the pharma business (restless leg syndrome comes to mind) you can’t make up problems your customer doesn’t know about. #4 is either the same as #3 or you’ve just built something that you can’t sell and you’re going in the “wrong direction”. But, I’m guessing your being a bit more nuanced than that. In that spirit, I agree they are the most fun. I’ve been fortunate enough to have done those a few times with products and extend them in unexpected ways. However, those game changers were always based on what I knew about my market and I could see how I could develop positioning and other sales materials so the value would be easily recognized by my customers as addressing known problems or let them see the possibilities for enhancing their mission.
Based on your blog, I see you’re into reading business books. I’d highly recommend you check out http://www.pragmaticmarketing.com/tunedin/tuned-in. Great read from the folks at Pragmatic Marketing (if your not familiar with them, their framework is the gold standard for software product management) that clearly and succinctly addresses this whole concept.
Posted by: The Unemployed Product Manager | March 16, 2010 at 06:40 PM
Very interesting comments. Sounds like we'll have to agree to disagree though.
For #4, I can think of numerous examples of customers not knowing they had a problem, or not knowing to ask. The Minivan is the classic case study example. Not many people were asking for a vehicle larger than a station wagon and smaller than a van. Nonetheless, when shown how this could address their needs, poof.
Posted by: Flint Lane | March 18, 2010 at 09:37 AM
Not sure we do disagree. As I said, may just be nuance and semantics.
Your example is a great one. Yes, customers couldn't conceive of the concept of a minivan and weren't asking for it. However, some product manager/auto designer did listen to his market and found out that station wagons conceived as a family car had issues (not enough room, getting kids in and out of the 3rd row, etc.) and that if they solved the problems station wagon buyers had with their current solution there would be a great opportunity.
Yes, the solution was new and unexpected. However, the solution was based on existing problems with what was available in the marketplace.
Those opportunities to build something new definitely are the most fun to discover and build (love that light bulb moment!) and a lot of times the most lucrative as well.
Posted by: The Unemployed Product Manager | March 20, 2010 at 01:28 PM