Yesterday’s article asked whether OSS tend to be anonymous and poorly designed and then compared how Jony Ive (who led the design of iPads, iPods, iPhones for Apple) might look at OSS design. Jony has described “going deep” – being big on focus, care and detail when designing products. The article looked at 8 care factors, some of which OSS vendors do very well and others, well, perhaps less so.
Today we’ll un-pack this in more detail, using a long-tail diagram to help articulate some of the thoughts. [Yes, I love to use long-tail diagrams to help prioritise many facets of OSS]
The diagram below comes from an actual client’s functionality usage profile.
The x-axis shows a list of functionalities / use-cases. The y-axis shows the number of uses (it could equally represent usefulness or value or other scaling factor of your choice).
The colour coding is:
- Green – This functionality exists in the product today
- Red – This functionality doesn’t exist
The key questions to ask of this long-tail graph are:
- What functionality is most important? What functionality “moves the needle” for the customers? But perhaps more importantly, what functionality is NOT important
- What new functionality should be developed
- What old functionality should be re-developed
Let’s dive deeper.
#1 – What functionality is most important
In most cases, the big-impact demands on the left side of the graph are going to be important. They’re the things that customers need most and use most. These are the functions that were included in the MVP (minimum viable product) when it was first released. They’ve been around for years. All the competitors’ products also have these features because they’re so fundamental to customers. But, because they already exist, many vendors rarely come back to re-factor them.
There are other functions that are also important to customers, but might be used infrequently (eg data importers or bulk processing tools). These also “move the needle” for the customer.
#2 – What functionality should be developed (and what should not)
What I find interesting is that many vendors just add more and more functionality out at the far right side of the graph, adding to the hundreds of existing functions. They can then market all those extra features, rightly saying that their competitors don’t have these abilities…. But functionality at the far right rarely moves the needle, as described in more detail in this earlier post!
Figuring out what should be green (included) and what should be red (excluded) on this graph appears to be something Apple has done quite well with its products. OSS vendors… perhaps less so!! By the way, the less green, the less complexity (for users, developers, testers, integrators, etc), which is always an important factor for OSS implementations.
Yesterday’s post mentioned eight “care factors” to evaluate your OSS products / implementations by. But filtering out the right side of the long-tail (ie marking up more red boxes) might also help to articulate an important “don’t care factor.”
#3 – What functionality should be re-developed
Now this, for me, is the important question to ask. If the green boxes are most important, especially the ones at the far left of the graph, should these also be the ones that we keep coming back to, looking to improve them? Where usability, reliability, efficiency, de-cluttering, etc are most important?
I suspect that Apple develop hundreds of prototypes that focus on and care about the left side of the graph in incredible detail, whilst looking to reduce the green bars in the right side of the graph. My guess is that subsequent updates to their products also seek improvements to the left side…. whilst also adding some new features, turning some of the red boxes green, but rarely all the way out to the right edge of the graph.
If you are in any way responsible for OSS product development, where is your “heat map” of attention on this long tail? Trending towards the left, middle or right?
But, another question vexes me. Do current functionality-based selection / procurement practices in OSS perpetuate the need to tick hundreds of boxes (ie the right side of the long tail), even though many of those functions don’t have a material impact? There’s a reason I’ve moved to a more “prioritised” approach to vendor selection in recent years, but I suspect the functionality check-boxes of the past are still a driving force for many.