Putting the customer first with Customer Centric product development
The key to producing consumer products cost-effectively is mass-customization. We’ve certainly come a long way since you could have a Ford in any colour as long as it’s black, but a modern car manufacturer will not give you a huge number of product variables — yes, you can choose a colour other than black, and you’ll be able to buy a sports pack, or upgrade the in-car entertainment system, but the car OEM will probably decide whether the model you want has a spoiler!
In many ways, software development has followed a similar path — the developer has decided what the solution set should be for a given problem, built a product around that solution set and allowed some level of customization around that.
Over time, additional features are required that go beyond the level of customization allowed in the original product specification. Pretty quickly under this development paradigm, the client has a system that’s no longer based on a solid code-base, so it cannot benefit from roadmap upgrades, shared innovation and maintenance. At the same time, they also have a system that lacks the benefits of custom development such as full control over code and feature set.
This is how media entertainment apps have traditionally been developed, and we think it’s broken. Fortunately, there’s another way.
Over the last 2 or 3 years, we’ve striven to base 24i product development on what we call Customer Centric principles.
As you might guess the overarching philosophy is to put the customer first, but in reality, what does this actually mean?
We’ve boiled this down to a number of principles that we adhere to in how we think about s/w development and build products, as follows:
- Don’t get too obsessed by one particular technology or toolset, it may be the best solution right now, but there will be another technology out there one day that will deliver a significant increase in functionality, power, flexibility and speed of development.
- Customization is good — but it requires a fully productized process and architecture to work at scale. Imagine how flexible a trainer factory has to be able to create personalized shoes. And what the cost of that flexibility might be.
- Deliver this customization through building apps as a collection of customizable micro-services.
- Code branching creates an exponential increase in complexity. Remove this by minimizing the inter-component complexity and dependencies between the micro-services.
So, how does this work in practice? As an example, one of our clients wanted to move from a profit to a non-profit model. The consumers using their app could move from a subscription model to a ‘single charitable donation for life’ model. There are complex rules that have to be adhered to when you’re accepting charitable donations — if this customer had been with a traditional developer, the switch would have needed a lot of new code, too much time and money, and potentially compromise the architectural integrity of the application. This is assuming they did not select an out-of-the-box vendor that would simply decline the request for the new flows.
Because our app was built on micro-services, with a minimum of dependency between the services, we were able to replace the components that needed to change and make the switch in weeks. More importantly, we enabled this change without a branch in the client’s code, so that moving forward they continue to gain from future 24i product roadmap developments.
I believe that sooner or later virtually every client has specific needs that are critical for their business. Yet, at the same time, most requirements are common between all streaming media businesses. Our Customer Centric approach based upon micro-services means that we can deliver scale, innovation and stability on these common needs, while offering the freedom to break free for that custom 5% that enables our customers to set themselves apart from the competition or fulfill unique business needs.
We know that customer-centric development based upon micro-services is the way to go — but it’s not necessarily obvious to potential customers how great an advantage this is, until they need to make a key pivot in business model, or the other customized change is the one that breaks this particular camel’s back. Which is why I’m writing this blog!
If you would like to know more about our approach to Customer Centric development, please get in touch — and look out for upcoming blogs from 24i CTO Pavel Jacko who will discuss the technical principles in more depth.
You can also read on LinkedIn