Tech-Threats: The Risks and Opportunity Cost of Product Customisation
Tech is very much in the business of delivering services to customers and meeting their needs. Very naturally, we’re all inclined to meet the wants of customers — and often the easy way out is to customise our software solutions to meet every single customer want. It’s the most straightforward way of delivering value.
Yet, when I say customisation is easy, I do not mean it is a trivial task. If not done properly with the right spirit, there are risks to bear.
- Customisation should deliver to customers’ needs, and not wants.
- Customisation involves effort, coding, documentation, and a tonne of testing. The astute reader would immediately see that customisation comes with some sort of tech risk. Or worse, business risks as well.
- Customisation requires you to reach out to the correct target audience and market — it is an outwards-looking task, rather than inwards.
Let’s break it down, shall we?
Delivering Needs, Not Wants
Let’s first talk about why it’s so easy to just think that product customisation is the best way to deliver value to customers.
For one, it’s a pretty straightforward process of figuring out what customers want, and then just simply giving it to them:
- Perform user research and market surveys
- Assign priorities to the features that customers say they want
- Take the results back to the developers and explain the need for these features
- Build and deliver, rinse and repeat
Secondly, you often land up with a deluge of customer feedback and data. And data is always assuring.
But such a simple approach to customisation assumes that the customer is always right, which is more of an approach to business rather than a granular prescriptive. In fact, we tend to further assume that many customers must be always right, and are lulled off in the sweet security of huge numbers.
In actual fact, customers may know what they want, but not necessarily what they need. Unless the customisation process is guided by a strong organisational vision (e.g. serving the needs of citizens) and ordered by a solid product roadmap (e.g. features emerging on the ethos behind serving the needs of citizens), the ease of customisation lends itself very readily to over-customisation.
Over-customisation = Business & Tech Risk
On the business risk of over-customisation, from the business perspective, one might think that users would generally like as many features as possible. “User customisation is great! I want this, and that, and I want to be able to make this software do my every bidding and take the thinking out for me!”
Is this really true? Here’re some facts to get us thinking on the right track:
- Users are not looking for a tonne of features. Psychologically, this results in choice paralysis and redundancy.
- Instead users often only interact with your product in a specific way, to solve specific problems. A good product is one that lends itself well to these specific problems, requiring only those specific features + a little more, to get the job done without much thinking and choosing.
- Users also buy your vision as much as your product. If your product doesn’t prioritise certain features that illustrate your company vision, you’re not walking the talk. And users can tell that you’re not selling to them.
Instead, a product that is customised just right, engages the intended customer audience.
On tech risk, there is much to say as well. You see, when we look at software, we tend to see just a coherent whole. But the underlying codes are multiple pathways of user actions codified into a visual user experience. Complexity is therefore multiplicative, not additive, when you add features — for instance, a simple app with two features (e.g. night mode + two font types) has 4 different scenarios that you should test for, not 2.
Meeting the entire wish-list of your customers is dangerous, because it increases tech-risk. Which comes in many forms, really:
- Cost of system maintenance
- Risk of delayed implementation and go-live at each delivery milestone
- Burden on your team for acceptance testing
- Documentation loss and difficulty in implementing good knowledgement management
- Loss of agility because of the difficulty in code upgrading or tech-stack switch
- Manpower turnover risk, when the product is too complex to keep up with staff turnover rate
Customer Features vs Company Efficiency
Here’s where a clear organisational vision helps makes things clear. As any company or organisation ought to be, product features must be prioritised for customers’ needs, rather than a company’s internal efficiency. Notice how the word here is “prioritised”, rather than an absolute “developed” — if your company is facing some severe tech-efficiency risk, it might well make sense to focus first on pulling your company together. Otherwise, customers first before company.
And the reason is simple. You can’t change your customers, but you sure can change your company.
- Fundamentally, customisation is an outwards-looking process or activity, rather than an inwards-looking one. You look first to resolve customer needs, and not employee needs with the product.
- Organisations who further make the mistake of brainstorming product features within themselves instead of prioritising feedback from customers run into this risk of diluting the product goal. The product becomes self-serving, rather than customer-centric.
How do we meet our company efficiency needs then, are they not important? That certainly isn’t true, but because company processes, skills and culture can be changed, you should never look to your product first to meet these needs.
The Opportunity Cost of Over-Customisation
The effort in customisation can sometimes be directed to business process re-engineering (BPR) instead, especially if the initial product feature was simply to cater to complex company processes.
As defined by Michael Hammer, BPR is the “fundamental re-thinking and radical redesign of business processes to bring about dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service and speed”.
It’s an entire discipline by itself, but one useful mantra is to obliterate, not automate. Very often companies think about automation, workflow customisation, creating more data export options, endless backend features — when actually, we should be thinking about whether these features can be done away with by transforming our internal processes.
In the wise words of a fellow GovTech colleague:
Why are we building upon complexity? If we’ve already identified that these processes can be done away with, why are we building a system before we review the way we do things? Complexity scales very fast, and we should seek to wean the fat where we can, before we build a product.
Again, it’s time to put down the pen. So many thoughts, so little time.