Well established frameworks, such as the Capability Maturity Model (CMM), help us measure software development process maturity in a standard way. But what makes the product functionality itself mature, and more importantly, how do we get there from “here”? Software product maturity (or lack thereof) can make or break your business, especially as your sales execution becomes more and more effective.
Software Product Maturity in a Nutshell
If you had to describe maturity itself in just one key phrase, it would sound something like “do what you say, and say what you do”. Of course there is more to it, especially for process, where continuous improvement and metrics are key, but this simple axiom is a great starting point. In product terms, you can further reduce this to one key element: Deployment. Think about it: no matter how good your product is, if your customer can’t use it, it’s almost worthless. In fact, it’s generally the difference between a product and a project. A real product is mature, while a project is an evolving, fluid technology that creates often elusive value. (Project in this case of course meaning code that is meant to be a product, not a statement of work-based project.) Measuring software product maturity is as simple as measuring how deployable it is.
Key Indicators of Lack of Maturity
- Services Attach Rate… While services can be a profitable upsell to go along with your product, if they are mandatory even for basic installation, then all you’re doing is slowing down the sales cycle and frustrating the customer prospect. In a presales situation, you generally can’t get away with charging a high enough rate for these services to even recover your resource costs. You should aim for deployment of basic functionality without services, then upsell advanced capabilities. (Your basic functionality should meet general market requirements already, otherwise you’re building solutions without problems.)
- Stated functionality is fragile or doesn’t work… This sounds very simple, but don’t advertise a feature unless you know for sure it works within the use cases you claim to support. If the customer or prospect is off testing exotic use cases without your knowledge, then you’re probably not maintaining technical sales discipline, which is a different maturity-related problem. But, if you are in fact setting expectations like you should be, then your product should deliver on them. Bugs are okay and expected. “Dead on arrival” situations are unacceptable.
- Upgrades are disastrous… Typically this is a result of rapid innovation that makes your technology resemble more of a project than a real product. While seamless upgrades are highly desirable, even complex upgrades should at least be deterministic. You absolutely want your customers on your latest stable code base as much as possible for many reasons, so make sure it’s not impossible for them to stay current.
There are dozens of other indicators, such as unstable APIs, etc., but these 3 are generally the most common and detrimental to your business.
The Path to Product Maturity
Here are 3 simple steps to achieving product maturity if you’re not already there:
- Simplify… Most likely, your product has too many advertised features. This is difficult to sustain and likely not necessary. Deemphasize anything that either doesn’t work or doesn’t provide core value. You can always leverage services for integration of exotic use cases, or build custom implementations for the exceptions.
- Speaking of use cases, make sure you define what works from a solution perspective. Remember, the customer buys your technology to solve problems, not because it’s cool. State the problems, and make sure you are building and testing to solve them. Of course you’ll likely need to put boundaries on the use cases, but if they are problem/solution oriented, chances are the “80%” will become obvious quickly. If you have use cases that don’t solve real market problems, get rid of them and the likely exotic functionality attached to them.
- Live, eat, and breathe deployment. Any feature you build must consider deployment and upgrades as part of its core functionality. This will also dictate your test cases and eliminate surprises once it gets in front of the customer or prospect. You should consider deployment as part of your Minimum Viable Product if you are a Lean Startup, otherwise you’re building a project instead.
Identifying and working toward software product maturity is no easy task, but it’s well within your reach if you stay focused on what really matters: Your customers’ collective ability to use what you build to solve their problems.