One of the many, great sessions at Product Camp London last month was Paul Pechey’s “Roadmaps – in the fast lane or stuck in a pothole?”. There was an interesting discussion around roadmap ownership, gaining consensus, HiPPOs and more. One of the questions that interested me was how to balance strategic and tactical development in an agile process.
Then, out of the blue, the other day, a long-time customer and early adopter wrote to me to ask about my views on ‘Features’ vs ‘Featurelets’. Howard Jones of Twenty4D VFX Ltd has given important and influential early feedback on several products I’ve been involved with, so I sat up and paid attention.
Basically companies often bring out great new features, which may be 95% there. However it is thought too expensive to fix the other 5%. Sometimes however this 5% can be so frustrating that it becomes pointless or a struggle using the feature the gaps – thought pointless to fix – become a major source of user frustration.
One story I like is when I was helping with the animation timeline in a product. The viewer only showed frame numbers and not traditional video timecode. Discussing this with the Engineering Manager I explained that you would normally start at 10:00:00:00 TC in the UK which is 900,000 frames, so it becomes impossible to navigate in frames. He was adamant though that there was no resources to fix it. Whilst we were chatting I heard a voice from behind: ‘I can fix it, it’s ok’.
By the time the Engineering Manager had convinced me that there was no resources the voice piped up again: ‘fixed it’.
The point here is that often the time management allocation takes longer than the fix, and the difference was between a usable and useless feature. This fix is to me a ‘Featurelet’: something too small to be considered worthwhile to an engineer, but something that makes the difference to the user between going home and seeing your children or swearing loudly at a grey box that refuses to budge (a new form of Tourette’s that should be named Billette’s thanks to Mr Gates and others).
Anyway as someone who constantly nudges for these things I feel they are too often ignored and software manufacturers should almost dedicate a small team to just go through and improve the day to day drudgery that users of the software endure.
(I’ve edited Howard’s text a little to disguise identities)
One of the themes of our discussion of roadmaps at Product Camp was the problems of balancing the PR-generating, market-growing, mega-features with the user-loving, RSI-saving, featurelets. The general discussion was the need to balance the strategic with the tactical.
In the past we used to have a rule that we’d have 3 headline grabbing mega-features and 20 featurelets in each release. With a mature product that can sometimes be difficult to achieve, but you certainly know when featurelets hit the spot because your users will be voluble in their thanks.
Another Product Manager I know likes to have a list of featurelets that engineers can dip into when they have a little spare time, recognizing that if they are working in the same area of the product they could implement one quickly and easily.
At the same time we have to recognize that there is always a Pareto moment with a
feature. Despite the fact that the engineers want to build a perfect complete feature, and the users can always think of new ways to enhance it, there has to be a point where it is “good enough”. You have to stop and release if the users are to be able to enjoy the benefits.
So, balance the scales with care, and ‘fix it’ for your users.