There is a perceived paradox in designing for scale while allowing for local requirements. You need to discipline yourself on the short run in order to ‘protect’ the flexibility that you need in the long run, across your entire footprint.
In short:
Many telcos, and organisations alike, that operate across a variety of markets need to cater for both a wide range of very specific (local) requirements as for ‘generic’ UX that by which they can leverage their economy of scale. Under pressure of local requirements or competition they often give in to the most immediate pressure of ‘fixing’ things tactically. This often results in tailor-made solutions that work in the market they were designed for, but are difficult to scale across other markets. This undermines the potential economy of scale. There is less opportunity to re-use these tailored capabilities elsewhere. The key to success (leveraging the economy of scale) lies in the design phase: Design for scale without violating agile ways-of-work.
Scale
Scale is achieved by the re-use of assets. Namely those assets that are the ‘building blocks’ of the telco value proposition (either the connectivity to the network itself, or the services running on top of this network). The high level components of the value chain could be presented as follows:
The value proposition is the foundation of your user experience. But often the standardisation is driven from the opposite direction. From the place where the explicit need for variations is most apparent; in the customer-facing touch points. This leads to a series of obstacles that limit the opportunity for scale. The touch points need standardised APIs. The APIs need a harmonised IT stack. In turn, the IT stack is build for unique business logic, coming from a wide variation (read: wild-growth) of value propositions.
The best way to efficiently harmonise and standardise the value chain is bottom-up. Starting with the value proposition.
The value proposition
Unique market circumstances need unique value propositions to meet those. Maybe they are driven by the competition’s propositions, regulatory constraints of a specific segmentation in that market, each local marketing team requires a level of flexibility to meet the demand from its customers. This begs the question; how to offer flexibility whilst maintaining a coherent and scalable value chain?
Key is to dissect the value proposition into 2 distinct parts:
- its essential components (i.e. types of variation)
- the variation in which these components can be offered (i.e. the value of the variation)
Allow me to illustrate this with an simplified example of a Valentine campaign’s value proposition.
Those customers who top up a pre-pay number of their choice, between February 10 and February 14, with a minimum of $5, receive unlimited text messages between those two numbers on February 14th.
Dissecting this proposition leads to the following ‘components types’ and their ‘value’.
| component type | component value |
| segment | pre-pay customers |
| window of availability | Feb 10 – Feb 14 |
| monetary threshold | >$5 |
| redemption time | Feb 14 |
| eligibility | donator and recipient |
The separation between ‘type’ and ‘value’ is key to maintaining a comprehensive, yet simple model for the value proposition, the IT supporting its provisioning & billing and ultimately the touch points where the proposition meets the end-user.
The number of types needs to reflect the business model. These are limited and typically do not exceed 10 to 15 different types for the most intricate industries like telco of air travel. It is important to scrutinise the introduction of new types on necessity, for each addition will imply complexity down the value chain (namely in your data model and core IT).
The variation in value is practically limitless, as these do not introduce complexity to IT systems, but rather are catered for by configuration. As an example; the type ‘redemption time’ can be registered in seconds. This will cater for seconds, minutes, hours, days or months. As all of these can be expressed in a discrete number of seconds to your data model (while using ‘days’ your communication toward your end user)
A list of ‘types’ could look as follows:
- price
- unit
- in time
- in quantity
- Location (e.g. geo-fenced discounts)
- number of redemptions
- users
- purchases
- compatibility
- eligibility
- segment
- time boxed
- balance (telco) % depleted
- network connected to (telco) (e.g. roaming)
- plan hierarchy (which plan to chart from when mutual conditions are met)
- discount
- unique (redeem limited time) vs generic (redeem unlimited times)
- percentage
- of product price
- of basket
- per check-out
- per time window (accumulated)
- window of availability
- duration
- contract of engagement
- stop on empty (e.g. prepay)
- stop on time passed (e.g. postpay)
- multiplier effect (e.g. er more loyalty points when gold member)
- tax/VAT
- hardware (physical product) vs service (access, software, etc..)
Once a comprehensive set of components is established, one that can meet the rationalised set of value propositions, these need to be codified (qualified and documented).
The codifying of the components requires an enormous discipline. Principles need to be defined and religiously adhered to. Even with a limited number of ‘building blocks’ one can achieve a wide range of variations to cater for a market’s specific needs. Allow me to explain this with an example we all know from childhood; Lego blocks.
A relatively limited variation of Lego blocks offer a tremendous room for creative building. A house, a horse or a submarine. I can be built! Kids show us every day. Of course, the horse won’t have long manes to cover its neck, but it is a trivial omission in kids imagination. A mere set of 6 basic logo blocks can be used in millions of combinations.
| Mathematician Søren Eilers was intrigued by a LEGO-related math problem. Let’s say you have six “standard LEGO bricks” (the rectangular 4×2 bricks seen in the original LEGO patent). If you fit them together, how many possible structures can you make?
This question was first officially “answered” in 1974, and LEGO mathematicians arrived at the number 102,981,500. Eilers was curious about the mathematical methodology behind that number, and soon discovered that it only covered one kind of stacking—thus, it was dramatically low. So he wrote a computer program that modeled all the possible brick combinations. After running the program for a week, he ended up with a massive number: 915,103,765 combinations. |
| http://mentalfloss.com/article/92127/how-many-combinations-are-possible-using-6-lego-bricks |
However, there is a condition. The principles by which a hand full of Logo blocks are so versatile are non-negotiable. The mutual compatibility is the ‘secret’ of Lego’s success.
They would never compromise the dimensions of the studs connecting one block to another, because that would undermine their principle of ‘playability’.
Lego does introduce new components when the market asks for it (e.g. Starwars puppets or pastel colours) but never changes their ‘backward compatibility’. There is a certain trade-off to be made. To keep the list of ‘elementary units’ under control you might have to apply a so called 80-20% approach to your current set of propositions. In other words, you need to sunset ~20% of your longtail to reduce ~80% of your complexity by eradicating those legacy components, as these cause a disproportional complexity in the upper part of the value chain.
As a result all capabilities build on top of the value-proposition-foundation can be made compatible and easy to maintain. The components drive the rationalisation of your entire chain.
Introducing new components
It is inevitable that a changing business environment will make some components redundant over time and will demand some to be introduced. The introduction will need to follow the same 80-20% logic. The introduction of a new component shall not trump the benefit of scale unless the local benefits cover a scalable solution. The designers of future blocks need to carry this responsibility. Either work with the combinations they have, or introduce a new component according to the thought-through and documented principles. In turn, this documentation is a key input to the requirements for campaign management systems, billing & provisioning systems, CRM and so forth.
Simplicity, after all, is not only about reducing complexity, but also avoiding complexity to sneak back into your system. Keep it simple! , but don’t oversimplify.
Or to paraphrase Einstein: Everything should be made as simple as possible, but not simpler.
further reading/viewing: