At the core of every software product road map are two concepts. These are essential to all software product development. We may think of different things, and we may use different terms or even look at them from different angles but at the end, I am convinced that it boils down to only two things:
Capabilities and Adoption.
in my experience, every other thing we do when we build software is a component, or is connected to one of these concepts. I think often that what gets us screwed up, is that that we focus on the “every other thing” from some methodology, or some playbook, or some consultant, and lose the plot on the essentials.
What are software capabilities, really?
From one perspective, we think of the capabilities of a software product as the functions or features. I find that this is especially true from a developers perspective. As members of software development teams, we think of features as the “what” – as in What are we building in this sprint? But if we put on, for a moment, the customers’ perspective, it is the “why” – as in Why should I buy this thing? The essence of a software capability is the “usefulness” that the user gets when she use it. We buy it because it does something useful. From that perspective, the “what” is what it does, and the usefulness derives from the “how” – as in How does it do that so fast? If we switch back to the developers perspective, the “how” is more related to the tools that he uses, and the practices that he follows. My point in this is really to say that software capabilities need to be considered from both the users point of view and the developers point of view, and when you have a picture that addresses both perspectives, you can probably be successful.
A software capability may be as much what I am building, as it is what it allows the end user to do, which is why the customer buys it. How I build it must correlates with how it does the job, so that it and we all don’t lose the plot on how to get the most of what we want for the money we spend.
What is adoption, and why do we care?
Adoption of a software product, is reflected as the organic desire of end users to prefer to use this product over available alternatives. What is missing from this definition of software adoption is “context”. The context of software adoption in its simplest forms consists of the alternatives available to using the software, and the “incentives” or external forces compelling users to use the system. If the software is purchased or licensed, the context could be influenced by the way the software was installed or the data that is made available to it. The things that inhibit adoption, are thus, experienced by the end users as a lack of quality. The quality could be relative to the available alternatives. The quality could be an absolute – the system is down more than it is up. The quality could be relate to the data, or the overall user experience being intuitive or confusing. Or it could simply be that there aren’t enough capabilities that I care about to create a compelling case to use the product.
We care about adoption because of this really simple fact:
If people don’t use the software, it doesn’t matter how useful it may appear, the software isn’t useful.
This sounds really dumb, but it happens. Sometimes we have a “really successful project” – that delivered software according to the specs, on time, on budget, with “expected quality”, but for some reason, the users don’t like using the product. It doesn’t make sense to them, or more likely, it takes them longer to do their job, or they make more mistakes, or it just isn’t that much better than the old one. If you don’t force the issue, by taking away the old one, they won’t come. Its worse if the old one is a spreadsheet that they made – ‘cuz you can’t easily take that away. That, my friend, does not enhance the bottom line.
That is the thing about adoption, is that if you don’t get it, all else if for naught.
How do I reflect capabilities and adoption in my road map?
Capabilities should be expressed in a product road map in the customer’s why-what language. What it allows the end user to do, why that is an improvement over current state (of the enterprise, of the art). Capabilities should not be expressed in the developer what or customer how language. Never “what is the name of the feature I am building” or “how does the system allow the user to do something”.
Adoption should be expressed in a product road map in terms of:
- Improvements to existing capabilities in response to feedback from existing users, or from non-adopters.
- Stacking or blending capabilities so that the combined usefulness is greater than the sum of the parts.
- Changes to the context, that will remove obstacles or increase incentives to adoption.
- Improvements to experienced quality (bugs, data, performance, availability)
- Improvements to quality experience (navigation, consistency, labeling/naming, layout, visual aesthetic, simplicity)
What should we do about capabilities that are not adopted?
Most teams look at capabilities and usage reports and try to get feedback to improve features that reveal capabilities that are not very well adopted. The thing is, sometimes it just doesn’t work. We learn that the feature is “too” something. The reality is in most software, there are some subset of capabilities that are not used very much. The thing is, carrying those capabilities around, through release after release can slow the process down and make software delivery more expensive. If nothing else, it increases the cost of regression testing. At worst, you have to re-implement a feature nobody uses because of some unrelated change. As a best practice in product road map development, you should recommend periodically, features that need to be pruned. Don’t get invested, just react to the fact that your user community has spoken and do the right thing.
Capabilities in clusters
Inevitably, your users will want a capability that doesn’t really fit very well in your product. The usefulness is for a different user community or requires data that is not closely related to the data your system needs. Maybe they are asking, because they see some similarity, or maybe just because they trust you to deliver, because you have done a good job.
Your product road map should be about the mission of your product. If this capability is only loosely related to that mission, maybe it should be built on a different product. At the least, you don’t want to “muddy up” your code base with stuff that gets in the way of delivery core capabilities going forward.
This is an important decision – to make your product a “suite”. Maybe some things are shared with products in the suite. But keep each sub-product true to its mission, and not complicated or convoluted with ideas from other missions. This is very important.
Don’t let your product grow tentacles. If you have a thin thread of capabilities going away from your core, that is probably a bad thing, so you should think before you build those.
Build your product in capabilities clustered tightly around specific missions, not randomly across a range of unrelated needs. So when you get the “odd” request, don’t think you have to do it. Just decide whether you have to do it “here”, and if here is the wrong answer, help your customer figure out where is better.
No Comments