Let’s say I have a great product capability in mind, and it has a bunch of features. (Maybe these are user stories, whatever.)
Some of those features are “must haves.” I can’t really deliver the capability without those. Some of them are “nice to have” – the more of those, the better the experience my customers will have, but they aren’t truly necessary. And some of the features will differentiate this capability from my competitors. We will all have capability X, but my version of X will have feature Q which they don’t have and that customers will find really valuable.
What I want in my requirements management tool is the following:
- Let me decompose a capability into features.
- Let me characterize the relationship between a feature and its parent capability – is it a must have, or a nice to have, or a differentiator (or, or, or)?
- Can I ship it? (All must-have features are ready to ship.)
- Can I put it on the datasheet? (I am shipping at least one differentiating feature.)
- Can I demo it? (If I’m only delivering must-have features, then I won’t demo the capability, but if I have some nice-to-have and differentiating features, I’ll show them in the demo
Would this work for you?
It strikes me that you have well thought out description of your functionality. The only point I would add is the need to translate features into a projection of:
1. Perceived customer value for different segments
2. The value of time to market
An outside in perspective and the value of different speeds to market should, I think, alter the resources you are willing to put behind the development.
Alisdair – great comment, and totally aligned with my expectations. In Accept360 we had the ability to associate requirements with different segments, customers, and market themes. This allowed us to do some quantitative analysis on how important a particular feature was given a particular set of company product priorities. So in my example of the "must-have," "nice to have", "differentiator" capabilities, along with the rollups , I've already assumed I assessed the importance of the overall capability to the market. Of course, there aren't any extant requirement management tools out there that do this quantitative prioritization either, sadly – Accept360 is basically dead at this point.
Why do you say A360 is dead Nils? Granted there haven't been any big steps forward since it was sold but it is still doing the job for me.
Roger – I'm happy to hear it's still providing value for you! My comment essentially was that smaller companies are not going to get be able to get the benefit of A360 post-the acquisition. BTW, I'd be happy to be wrong about this!
If you are going to have a competitor in mind it strikes me that you need to have 2 options:
-Feature is a “Differentiator” or”me too”
And if this is a revenue generating venture you should try to predict expected (hoped for) revue outcome. That way over time you can measure the history of the backlog feature types that tend to produce the best outcomes in your prioritization efforts.
Paul – great comment. I basically agree, however, I would put the competitor info and the potential revenue information into a separate part of the model. Arguably, if you had the competitor relationships up to date you could derive the "differentiator" dimension. I'd rather make it an explicit relationship between the feature and the capability, though. Your question also suggests that it might be worthwhile to create an ideal requirement management schema that takes into account all these relationships that I've mentioned, as well as those other people have asked me about, like revenue. In the products I personally have been a product manager for, it's very hard to tie revenue to specific features or capabilities. But I know there are plenty of products where you can make that relationship. For example, add-ons for iPhone apps might be an example. Those are generally capabiilties, or even simply features, and they result in a new revenue stream for the vendor.
Nils, you've really explained the relationship between capabilities (what I usually call themes) the the features that make them up very nicely. Thank you.
I'm at work now something I call Reqqs. It's a roadmap tool for product people. If you don't mind, I think I'd like to use your notion of characterizing "the relationship between a feature and its parent capability – is it a must have, or a nice to have, or a differentiator." I think that makes a lot of sense.
I hope that I can build a requirements management tool that will finally be the thing we've all been looking for. For more info, check out http://www.reqqs.com.
Bruce – thanks for the comment and sorry for the delayed response. I’m totally happy for you to make use of my suggestion. I think this is one of a number of properties that would be valuable on the parent-child relationship. Simply the concept of there being some relationships between parent and child requirements in addition to the ancestry is useful – and of course having specific ones supported makes it a lot more useful.
Oh, and you probably noticed I mentioned Reqqs in a blog post today.
Thanks, Nils! I'll check out the new post.