When evaluating a feature for value it’s easy to fall into the trap of equating value with money; direct revenue is not the only value you can get from a feature. Here are some other concepts of value:
- ease of maintenance, monitoring and admin tools to quickly identify and diagnose potential issues (keep good customers)
- framework designs can save time adding new features and allow parts of your system to be resold as services (robust resellable software)
- the right free features can draw customers to your product in the face of stiff competition, gaining you greater customer numbers (get more market share)
The benefit from these features is completely wasted if their execution is ill thought out, is flaky or worse, they don’t work at all.
If you hear that someone isn’t ‘allowed’ to put too much time into a feature because it’s offered for free or its only internal, alarm bells should be ringing. The same key aspects of software should apply here as for anything else:
how this feature should work for each and every user type
Does every type of customer interact with the feature in the same way? Are there staff only actions? Does the feature work in different ways on different tariffs?
how it should be presented and supported
How does the interface appear? Does the ‘flow’ of the feature make sense to the intended audience? What help is available immediately alongside the feature? Is it easy to get to more detailed help? How do support staff learn about this feature?
what design will allow it to be flexible for the future
Does this feature scale appropriately? How much does it share with other features? How often do they change? Do we anticipate offering this through another channel or interface? Is there the possibility of a new type of customer we could be offering this to?
who we should be collaborating with
internal users, infrastructure experts, trainers, support staff, beta testers, external suppliers, industry partners
how we can develop it to be easily maintained and monitored
active monitoring and analysis tools for predictive performance, usage and capacity; intelligent logging and log file analysis; alternative access to feature data including admin tools; api endpoint test harnesses and tools
how we should be testing
when we should be testing; who should be testing; what we are testing for: functionality, usability, performance, load
the most efficient, and least disruptive, release process and cycle
where we deploy, redundancy and failover, how often we release, minimising outages, maintaining reliable and predictable service.
If your free service is mentioned as a big selling point in all the marketing material and brings in twice as many customers, you’ll be glad to have shunned the shoddy and invested wisely in the free world.