My Dream Penknife
Ever since I got my first penknife from my Dad at a single digit age I wanted a Swiss Army knife — I overshot in my late pre-teens by buying a massive contraption with about 30 blades and a spoon — however I soon settled on a basic Swiss Army model with a couple of blades and a flat bladed screwdriver as well as one of those mysterious ‘stones from horses hooves’ things.
It’s a decent knife — it’s prime function is cutting but if you really haven’t got a screwdriver it’ll do a reasonable job for you — if you’re a horse owner I’m pretty sure you have other ways of getting stones out of hooves.
It’s almost totally useless in my day job running a software product development company, but it serves as a useful reminder for me — make sure my product can do one thing really well. It used to be convenient to cluster a lot of diverse functions in a single package because all the data could be managed in a single place — so you’d have accounts, inventory, personnel etc in one app which became difficult to understand, navigate and mantain — I’d argue that those days are gone now — data exchange is usually pretty easy and there are a myriad of ‘best in class’ applications which allow you to mix and match to get the best fit for all the jobs you need to do. Of course having multiple logins can be a hassle but there are ways to overcome these issues.
In the IT product business we talk about ‘feature creep’ where a software product acquires little extra bits of functionality as the project progresses. For established products like our action tracking tool we also have to watch out for ‘feature bloat’ which is as uncomfortable as it sounds.. the temptation to cram a couple more buttons into that top menu line, or add a bit more configuration to the editor — with an established product it’s easy to do stuff like this because the frameworks and structures are already there and we generally just need to ‘bolt on’ another piece of functionality. (My engineers tell me I’m oversimplifying this bit..)
The problem of course is that we might reach the ‘tipping point’ where our product moves from being ‘simple to use’ to ‘ usable’ because we’ve added some esoteric rarely used feature at the expense of the magic sauce which was the reason for it’s existence in the first place, the other problem is that for many of our specialised vertical market products we don’t have a million customers who will immediately express their dislike of poorly thought out changes, so it’s very hard to gauge the immediate impact of design decisions.
Add to that the desire to keep innovating and we have a potent recipe for carnage — unless the product management process includes enough sanity checks and customer advocates. Fortunately although we don’t have millions of users we do have thousands, and it’s relatively easy to contact a good cross section of them and speak to them about what we’re planning.
I’m not arguing against having a lot of features — but you need to be sure that they’re all necessary and that they give your users a compelling reason to choose your product.