The colour palette analogy of OSS

Let’s say you act for a service provider and the diagram below represents the number of variations you could offer to customers – the number that are technically supported by your solution.
13,824,000 Colours
That’s 13,824,000 colours.

By comparison, the following diagram contains just 20 colours:
20 Colours

If I asked you what colours are in the upper diagram, would you say red, orange, yellow, green, blue, etc? Is it roughly the same response as to the lower diagram?

If you’re the customer, and know you want an “orange*” product, will you be able to easily identify between the many thousands of different orange hues available in the upper diagram? Would you be disenfranchised if you were only offered the two orange hues in the lower diagram instead of thousands? Or might you even be relieved to have a much easier decision to make?

The analogy here to OSS is that just because our solutions can support millions of variants, doesn’t mean we should. If our OSS try to offer millions of variants, it means we have to design, then build, then test, then post-sale support millions of variants.

However, in reality, we can’t provide 100% coverage across so many variants – we aren’t able to sufficiently design, then build, then test, then post-sale support every one of the millions of variants. We end up overlooking some or accept risk on some or estimate a test spread that bypasses others. We’ve effectively opened the door to fall-outs.

And it’s fall-outs that tend to create larger customer dissatisfaction metrics than limited colour palettes.

Just curious – if you’ve delivered OSS into large service providers, have you ever seen evidence of palette analysis (ie variant reduction analysis) across domains (ie products, marketing, networks, digital, IT, field-work, etc)?

Alternatively, have you ever pushed back on decisions made upstream to say you’ll only support a smaller sub-set of options? This doesn’t seem to happen very often.

* When I’m talking about colours, I’m using the term figuratively, not necessarily the hues on a particular handset being sold through a service provider.

The PAOSS Call for Innovation has been released

I’ve been promising to release an OSS Call for Innovation, a manifesto of what OSS can become – a manifesto that also describes areas where exponential improvements are just waiting to happen .

It can be found here:
http://passionateaboutoss.com/oss-call-for-innovation/
And you’ll also notice that it’s a new top-level menu item here on PAOSS.

Each time I’ve released one of these vision-statement style reports in the past, I’ve been pleasantly surprised to find that some of the visions are already being worked on by someone in the industry.

Are there any visions that I’ve overlooked? I’d love to see your comments on the page and spread the word on all the amazing innovations that you’re working on and/or dreaming about.

Who can make your OSS dance?

OSS tend to be powerful software suites that can do millions of things. Experts at the vendors / integrators know how to pull the puppet’s strings and make it dance. As a reader of PAOSS, chances are that you are one of those experts. I’ve sat through countless vendor demonstrations, but I’m sure you’ll still be able to wow me with a demo of what your OSS can do.

Unfortunately, most OSS users don’t have that level of expertise, nor experiences or training, to pull all of your OSS‘s strings. Most only use the tiniest sub-set of functionality.

If we look at the millions of features of your OSS in a decision tree format, how easy will it be for the regular user to find a single leaf on your million-leaf tree? To increase complexity further, OSS workflows actually require the user group to hop from one leaf, to another, to another. Perhaps it’s not even as conceptually simple as a tree structure, but a complex inter-meshing of leaves. That’s a lot of puppet-strings to know and control.

A question for you – You can make your OSS dance, but can your customers / users?

What can you do to assist users to navigate the decision tree? A few thoughts below:

  1. Prune the decision tree – chances are that many of the branches of your OSS are never / rarely used, so why are they there?
  2. Natural language search – a UI that allows users to just ask questions. The tool interprets those questions and navigates the tree by itself (ie it abstracts the decision tree from the user, so they never need to learn how to navigate it)
  3. Use decision support – machine assistance to guide users in navigating efficiently through the decision tree
  4. Restrict access to essential branches – design the GUI to ensure a given persona can only see the clusters of options they will use (eg via the use of role-based functionality filtering)

I’d love to hear your additional thoughts how to make it easier for users to make your  (their) OSS dance.

My least successful project

Many years ago I worked on a three-way project with 1) a customer, 2) a well-known equipment vendor and 3) a service provider (my client). Time-frames were particularly tight, not so much because of the technical challenge, but because of the bureaucratic processes of the customer and the service provider. The project was worth well in excess of $100M, so it was a decent-sized project as part of a $1B+ program.

The customer had handed the responsibility of building a project schedule to the equipment vendor and I, which we duly performed. The Gantt chart was quite comprehensive, running into thousands of lines of activities and had many dependencies where actions by the customer were essential. These were standard dependencies such as access to their data centres, uplift to infrastructure, firewall burns, design approvals, and the list goes on. The customer had also just embarked on a whole-of-company switch of project management frameworks, so it wasn’t hard to see that related delays were likely.

The vendor and I met with the customer to walk through the project plan. About half-way in, the customer asked the vendor whether they were confident that timelines could be met. The vendor was happy to say yes. I was asked the same question. My response was that I was comfortable with the vendor’s part, I was comfortable with our part (ie the service provider’s), but that the customer’s dependencies were a risk because we’d had push-back from their Project Manager and each of the internal business units that we knew were impacted (not to mention the other ones that were likely to be impacted but we had no visibility of yet).

That didn’t go down well. I copped by far the biggest smashing of my career to date. The customer didn’t want to acknowledge that they had any involvement in the project – despite the fact that they were to approve it, house it, host it, use it and maintain aspects of it. It seemed like common sense that they would need to get involved.

Over the last couple of decades of delivery projects, one trend has been particularly clear – the customer gets back what they put in. That project had at least twelve PMs on the customer side over the 18 month duration of the project. It moved forward during stints under the PMs who got involved in internal solutioning, but stagnated during periods under PMs that just blame-stormed. Despite this, we ended up delivering, but the user outcomes weren’t great.

As my least successful project to date (hopefully ever), it was also one of my biggest “learnings” projects. For a start, it emphasised that I needed to get better at hearts and minds change management. There were many areas where better persuasion was required – from the timelines / dependencies to the compromised architecture / hardware that was thrust upon us by the customer’s architects. What seemed obvious to me was clearly not so obvious to the customer stakeholders I was trying to persuade.

OSS brand building with the simple stick

Today’s consumers want to get the best prices, but offering your brand at a discount can undermine profits and threaten viability. Smart brands utilize strategies to create and sustain a meaningful difference that helps consumers justify spending more.”
Nigel Hollis
, in his PoV on branding.

I once read a statistic that at one point Apple owned 6.5% of the total handset market, but accounted for 75% of the entire industry’s operating profit. Now that’s a premium brand!

Whilst some in the OSS industry may claim their brand is the strongest, none come close to having the fanatic customer base that Apple has built. This makes me ponder what it would take to create a truly premium OSS brand.

People buy a premium brand for the enjoyment it brings them, either in the experience, the status, the prestige, the satisfaction of having a need met efficiently and probably many other variants on these reasons.

Three questions for you:

  1. For how many customers is the OSS buying experience an enjoyable one?
  2. For how many customers is the implementation / integration experience an enjoyable one?
  3. For how many customers is the user experience an enjoyable one?

Actual customer experiences in relation to the questions above might be 1) Confusing, 2) Arduous and 3) Unintuitive.

I’m going to take a completely contrarian view because the status quo clearly isn’t working. This contrarian view focuses squarely on simplicity. It seems that our developers are always building new functionality. However, most of the OSS functionality that users will ever need has already been around for decades. Rather than new functionality, how about a focus on making old functionality vastly more simple?

Rather than with Engineers, how about beating OSS with the simple stick by engaging marketers, designers, artists, stylists – the creatives – to improve the three experiences above?

The mafia… Pressure? What pressure?

OSS delivery teams can be quite tense environments to work within can’t they? Deadlines, urgency, being in the customer’s line of sight and did I mention deadlines? [As an aside, I’m not sure which type of deadline is more stressful, the ongoing drain of fortnightly releases under Agile, or the chaos of a big-bang release that is preceded by lengthier periods of relative calm.]

When it comes to dealing with stress, I see two ends of a continuum:

  • The teflon end – get it off me, get it off me – the people who, when under stress, push stress onto everyone else and make the whole team more stressed
  • The sponge end – the people who are able to absorb the pressure around them and exude a calm that reduces stress contagion

I can completely understand those who fall at the teflon end, but I can’t admire them or aspire to work with them. I’m sure most would feel the same way. They let urgency overwhelm logic.

This reminds me of a project where the mafia were tightly entwined into a customer’s project team and they were constantly wrangling scope, approvals and payments to ensure “the organisation” profited. They were particularly “active” around delivery time.

A biggest of big-bang deliveries required me to stand in front of a large customer contingent for three days straight to demonstrate functionality and get grilled about processes, tools and data sets. At the end of the third day, we’d scheduled the demonstration of some brand new functionality.

It was a module that had been sold to the customer before even being conceptually architected let alone built. [You know the story – every requirement on an RFP must be responded to with a “Complies” even if it doesn’t]. My client (the vendor) was almost ready to back away from this many-million dollar contract due to the complexity and time estimated to build the entirely new module from scratch. I stepped in and proposed a solution that stitched together four existing tools, some glue and only a few weeks of effort… but we’d never even had it working in the lab before entering into the demo.

At first pass, the demo failed. Being at the end of the three-day demo (and the hectic weeks leading up to it), my brain was fried. The customer agreed to take a short break while we investigated what went wrong. We were struggling to find a resolution, so I was proposing to delay demonstration of the new tool until the following day.

Luckily for me, the most junior member of our team sat in the background plugging away, trialling different fixes. He tapped me on the shoulder and told me that he thought he’d resolved the problem.

We regathered the customer’s team and presented the new module. We waited for the customer’s lead to push an unknown configuration into the network and waited for him to check whether our new tool had responded correctly. It did and the customer was ecstatic.

We’d been saved by a very clever young man with an ability to absorb pressure like a sponge. I couldn’t thank him enough.

Increasing the percentage of digital revenues

Digital revenues
The diagram above comes from research by AT Kearney and Delta Partners courtesy of an article by Mark Newman of TM Forum.

It provides an interesting perspective on CSPs‘ ability to “compete” with a broader, more digitally native group of service providers.

The golden age for CSPs was when they transported data from point A to point B (ie data and voice services) and people performed the value-add on top of those communications (ie business development, marketing, etc). DSPs have disrupted this model by now providing the value-added as digital services on top of base comms services (ie the over-the-top play).

The breadth of OTT services means that CSPs can’t possibly create the whole long tail of offerings. However, like DoCoMo, they can create partnerships and/or platforms that support the long tail of third-party offerings. It’s no coincidence that DoCoMo is the clear leader in the graph above as they have a long history of deriving revenues from third-party partnerships.

The question for an industry where 3.8% of revenues are from digital sources is not so much how to transition to an OTT model themselves, but how to provide digital delivery platforms that support third-party revenue streams and to do so more profitably (for all parts of the supply chain).

What’s the next tool in your toolbelt?

As OSS exponents, I’m sure you’ll agree that there are many OSS tools / skills that we use and develop (to differing degrees) over the years.

In fact, there are so many to choose from that we often have to make a conscious decision which ones to master and which ones to leave for others to master. Other times we have the decision thrust upon us.

When you have the chance to decide, do you choose from a perspective of craft or value?

Choosing by craft is analogous to already having a toolbelt with a hammer, a screwdriver and a glue gun, then choosing a nail-gun as the next tool to learn. They all fall into the same category of fasteners. They make you more proficient at choosing the right fastener for the job, but adding more to the list is unlikely to significantly increase the hourly rate a customer or employer will pay for your services. Whilst you’re more skilled, there are still a lot of others out there who can use fasteners. In fact, it can arguably be said that I can even use a few of those tools. They’re not really differentiators for you or your customer / employer.

Choosing by value, to extend on the analogy, is to add expertise as a builder, surveyor, draftsman, architect, etc in addition to the fastener skills you already have. They might be harder to attain, but that’s what increases differentiation. They’re perceived to be more valuable because they are perceived to play a more exclusive part in the final product that’s being offered to customers.

In OSS, if you can already program in five languages, does taking the time to learn a sixth significantly add value (to you or your value chain)? Sometimes perhaps. But if you were to spend the same amount of time to become more proficient at infrastructure or networks or team leadership, etc I suspect your contribution to the value fabric (ie customers, your team, etc) would increase far more… even if it didn’t immediately translate to a higher hourly rate.

The most invaluable people I’ve worked alongside in OSS, the valuable tripods, are proficient across many of OSS‘s domains and can link silos of expertise together. But that’s certainly not to devalue the importance of the craftspeople, as it’s their continued search for excellence that strengthens the silos, the foundations of OSS.

When you next have the chance to decide, will you choose from a perspective of craft or value?

Omnichannel will remain disjointed until…

Omnichannel is intended to be a strategy that provides customers with a seamless, consistent experience across all of their contact channels – channels that include online/digital, IVR, contact centre, mobile app, retail store, B2B portal, etc.

The challenge of delivering consistency across these platforms is that there is little cross-over between the organisations that deliver these tools. Each is a fragmented market in its own right and the only time interaction happens (in my experience at least) is on an as-needed basis for a given project.

Two keys to delivering seamless customer experience are the ability to identify unique customers and the ability to track their journeys through different channels. The problem is that some of these channels aren’t designed to uniquely identify and if they can, aren’t consistent with other products in their linking-key strategies.

A related problem is that user journeys won’t follow a single step-by-step sequence through the channels. So rather than process flows, user journeys need to be tracked as state transitions through their various life-cycles.

OSS/BSS are ideally situated to manage linking keys across channels (if the channels can provide the data) as well as handling state-transition user journeys.

Omnichannel represents a significant opportunity, in part because there are two layers of buyers for such technology. The first is the service provider that wants to provide their customer with a truly omnichannel experience. The second is to provide omnichannel infrastructure to the service providers’ customers, customers that are in business and want to offer consistent omnichannel experiences for their end-customers.

Who is going to be the first to connect the various channel products / integrators together?

Use cases for architectural smoke-tests

I often leverage use-case design and touch-point mapping through the stack to ensure that all of the use-cases can be turned into user-journeys, process journeys and data journeys. This process can pick up the high-level flows, but more importantly, the high-level gaps in your theoretical stack.”

Yesterday’s blog discussed the use of use cases to test a new OSS architecture. TM Forum’s eTOM is the go-to model for process mapping for OSS / BSS. Their process maps define multi-level standards (in terms of granularity of process mapping) to promote a level of process repeatability across the industry. Their clickable model allows you to drill down through the layers of interest to you (note that this is available for members only though).

In terms of quick smoke-testing an OSS stack though, I tend to use a simpler list of use cases for an 80/20 coverage:

  • Service qualification (SQ)
  • Adding new customers
  • New customer orders (order handling)
  • Changes to orders (adds / moves / changes / deletes / suspends / resumes)
  • Logging an incident
  • Running a report
  • Creating a new product (for sale to customers)
  • Tracking network health (which may include tracking of faults, performance, traffic engineering, QoS analysis, etc)
  • Performing network intelligence (viewing inventory, capacity, tracing paths, sites, etc)
  • Performing service intelligence (viewing service health, utilised resources, SLA threshold analysis, etc)
  • Extracting configurations (eg network, device, product, customer or service configs)
  • Tracking customer interactions (and all internal / external events that may impact customer experience such as site visits, bills, etc)
  • Running reports (of all sorts)
  • Data imports
  • Data exports
  • Performing an enquiry (by a customer, for the purpose of sales, service health, parameters, etc)
  • Bill creation

There are many more that may be required depending on what your OSS stack needs to deliver, but hopefully this is a starting point to help your own smoke tests.

The OSS Mechanical Turk

The Mechanical Turk… was a fake chess-playing machine constructed in the late 18th century. From 1770 until its destruction by fire in 1854 it was exhibited by various owners as an automaton, though it was eventually revealed to be an elaborate hoax.
The Turk was in fact a mechanical illusion that allowed a human chess master hiding inside to operate the machine. With a skilled operator, the Turk won most of the games played during its demonstrations around Europe and the Americas for nearly 84 years, playing and defeating many challengers including statesmen such as Napoleon Bonaparte and Benjamin Franklin
.”
Wikipedia.

This ingenious contraption can be mirrored in certain situations within the OSS industry.

I once heard of an OSS fulfilment solution that had consumed a couple of years of effort and millions of dollars before management decided to try an alternate path because there was still no end in sight. There was so much sunk cost that it was a difficult decision.

The problem statement was delivered to a new team brought in from outside the organisation.

They had it working within a single weekend!!

How?

They had focused on what the end customers needed and developed an efficient self-service portal (a front end) that created tickets. The tickets were then manually entered into the back-end systems. Any alerts from the back-end systems were fed back into the portal.

It did the job because transaction volumes were low enough to be processed manually. The first approach failed because integrations, workflows and exception-handling were enormously complex and they were laser-focused on perfect automation.

The Mechanical Turk approach to this OSS conundrum proved to be far more successful. It doesn’t work in all situations but it could be used more often than it is.

Hell’s Kitchen, OSS style

Gordon Ramsay used to run a TV show called Hell’s Kitchen where he would take a failing restaurant and would attempt to transform it one expletive at a time.

I’m not remotely interested in reality kitchen shows but I did watch a couple of episodes of this one. Enough to notice a trend happening. He would always:

  • Simplify the menu
  • Seek to understand the customers and what they want (with an understanding of the local situation – palates and produce)
  • Coach the team
  • Market the new concept

Following on from yesterday’s post on variants, it seems to me that cloud providers tend to follow the Hell’s Kitchen approach to service offerings and their management more so than CSPs.

Whilst their recipes might be complex behind the scenes, they can focus and automate because they keep variants to a minimum all the way through their stack.

CSP OSS menus tend to look more like the typical Chinese restaurant with hundreds of options, but without the modularity (ie black bean, teriyaki, chicken, beef, etc)

Ramping down network variants, ramping up digital variants

Voice and data are no longer the services that organisations, large and small, see as making a difference. The services that do make a difference are more dynamic and diverse – digital distribution, promotion and marketing, payments and billing, business intelligence, business continuity (including security) and more – the factors that make their organisations thrive.

Our OSS and BSS are currently complex due to all the network variants that they handle. But if customers don’t value the network (as a differentiator) then why are we putting so much effort / attention there? If customers want ubiquitous, secure data streams with digital services on top, then why aren’t we reducing network variants and correspondingly reducing complexity in our network-based OSS / BSS?

That will give us the head-room to enhance our tools and ramp up the digital services that organisations do value.

Customers like options. But if all the options are available on the digital services / bundles, customers won’t really care if they’re delivered over a network stream that has almost no variants. This also allows a transition to more of a consumption-based model rather than all the variants of speeds and feeds and protocols.

The big challenge here is convincing the networks teams to ramp down and allow digital teams to ramp up. That concept won’t go down too well at most service providers though will it?

Channelling “Intel Inside” to improve the brand recognition of your OSS

During Intel’s marketing of “Intel Inside” they taught consumers to look for the Intel Inside logo as an assurance of quality. Consumers eventually came to see “Intel Inside” as a standard and began asking the question: “Why doesn’t your product use Intel processors?” This standard became so important that today it is one of the world’s largest co-operative marketing programs,where hundreds of computer companies license the use of the Intel Inside® logos.
The ingredient must be highly differentiated in order to add value to the overall brand. This means the ingredient should have a separate name and logo and overall purpose, because the added value comes from the extra identity. First and foremost, brands should not create confusion in the market. The main brand should be well established in the market before employing an ingredient branding strategy because the consumer needs first understand the core brand and then find additional value in the ingredient
.”
From an article about Ingredient Branding on Disenthrall.co.

When you think about the chips inside the multitude of electronic devices you own and use, how many brands could you identify? How many chipsets are differentiated enough to sway your decision on the device itself?

According to FastCompany, “If one thing distinguishes Intel’s innovative thinking, it is their 1990s strategy of branding a semiconductor chip as a valuable feature that consumers would look for when they purchased a computer. The campaign’s two decades of ubiquity make us forget this now, but at the time it was an incredibly novel approach to marketing. People bought computers because of the software, the specs, or a friend’s recommendation. Who cared about who made some tiny chip inside the box that you couldn’t even see?
But with the proliferation of PCs, and with consumers at a loss in trying to figure out what made one better than the other, Intel saw an opportunity, and so it took a major risk. Intel’s leadership was convinced this was the way to grow market share…

The “Intel Inside” initiative has arguably been the most successful ingredient marketing exercises in history. They’ve made the invisible visible.

To many users/customers, the achievements of our OSS are invisible, with other components getting the credit for outcomes that are heavily underpinned by our OSS. The challenge for us, just like Intel, is to differentiate and improve the value of our brand. We get the flak for when things go wrong (often through no fault of our own), but we rarely get the credit for the things that work – for the services activated, for the problems resolved, for the equipment ordered, for the new services enabled, for the insights gleaned, etc.

The question for us all is how to make those accomplishments, that differentiation, the brand value visible. [Note that I’m referring to the brands of internal OSS suites here, not just external vendor products]

If we think about making the invisible visible to key execs / sponsors / stakeholders, we need to think about how they tend to interact with OSS. I would surmise that in most cases they interact via reports. Assuming you’re confident that you’ve nailed the content of your reports, that they’re succinct and valuable to those stakeholders, is there any reason why we couldn’t put our equivalent of the “Intel Inside” badge on the reports?

But first, are you confident that the badge is a badge of honour? Will your brand instil in customers a sense of quality, assuredness and innovation?

Inverting the iceberg to get more funding for your OSS

In the last couple of days, we’ve discussed frameworks that could allow CSPs to design disruptive business models around factors that our OSS / BSS can control. Not exactly riveting stuff for the tech-heads amongst the reader-base, but relevant for the amount of investment that gets directed into the tech projects that we all work on.

Let me get a little more specific today. We only get to work on cool OSS projects if funding is allocated to them. As we all know, OSS are the linchpin around which a service provider is built, but most executive sponsors don’t grasp the full extent of this dependence. There are a few reasons for this:

  1. OSS are perceived as not generating any revenue directly
  2. OSS projects continually disappoint (on time, cost and/or functionality)
  3. The full picture of OSS functionality is hidden (like an iceberg) and is boring to most. The Service provider’s customers certainly have zero interest in the back-end systems / functionality in use
  4. Our business cases tend to be built around cost reduction, not business growth. Let’s be honest, OSS cost reductions go in the same excitement bucket as a reduction in paper clips, pens and printer paper
  5. The technologies used by OSS seem to be obsoleted even faster than the network technologies they manage
  6. They tend to deliver more negative messaging (eg network outages, fall-outs resulting in poor customer experiences, etc), whilst others get the credits for any positive messaging that OSS have facilitated
  7. Due to the costs of implementation and change, OSS are seen by many as giant sinkholes of cost centres
  8. The list goes on!!

Aaarghhh! Why do we bother working in OSS?

For all of us in the OSS industry, we understand the justifications behind these derogatory remarks above.

It all comes down to the messaging going to executive sponsors. Like Steve Jobs, I have just three things (to help build a compelling story for your executive sponsors):

  • Break “the sink-hole perspective” by generating revenues – via APIs, via platforms, via metrics that show OSS contribution to revenues or anything else that shows real value, not just cost-out, to executive sponsors as well as the customers they’re trying to service
  • Invert the iceberg – show just how much capability is hidden under the surface by mapping how dependant the organisation’s positive outcomes are on its OSS (OSS as the puppet-master). All the sexy stuff (eg 5G, IoT, network virtualisation, etc) can only be monetised if our OSS pull all the strings to make them happen
  • Simplify – the massive (and increasing) complexity in our business is boring to non-OSS people and an impediment to us in our ability to deliver exciting outcomes for everyone else. Just take Google – they have an incredibly complex tech-stack to run… but what does the customer interact with on their search page?

Six things in a disruptive ring

The diagram below shows the six phases in a customer life-cycle as defined by Forrester Research:
Forrester life-cycle

It also represents a map of the omni-channel experience for customers and approximates hand-off points. As far as the customer is concerned, the experience should be a seamless continual loop regardless of whether they engage via retail outlet, online, contact centre, chatbot, IVR, etc (or more likely, a somewhat random mix of all).

From a CSP‘s systems perspective, there are usually completely disparate functions that are designed in isolation, perhaps with only loose integration / hand-off between segments in the ring at best. Typically, the only thing that entwines the ring is people and process. For example, that might be a contact centre operator who hopefully has some level of visibility of each of the segments (but often doesn’t) and can tie the pieces together elegantly for the customer.

If we truly want a robust omni-channel experience for our customers, then all systems need to be designed with a seamless continual loop in mind. We can’t expect human-cost reduction automations like chat-bots or online self-service to thread the pieces together unless we can track every single user’s journey, via common linking keys, through each system.

Our OSS/BSS are better positioned than any others to provide this seamless interlock. We’re typically involved in the Buy and Use segments. We’re often called upon for the Ask segment and sometimes for the Engage. If we can also loop in data from the Discover and Explore segments (usually handled by digital or retail/sales), then we have access to the pieces. Then it just remains for us to pull the jigsaw pieces together.

I’m actually really excited by what this ring-thinking could translate to for CSPs – disruptive customer experience models. It gives the opportunity to re-imagine our systems from the customer experience out, as alluded to in the recent OSS Singapore analogy.

The first date principle of product development

“…don’t ask your customers what they like or don’t like about your product. Or what they’d change if they could. That’s all about you. If you want really insightful answers, ask them about themselves instead. You can find out a ton about you by asking them about them.
Jason Fried
.

We’ve previously discussed how the first date analogy applies to selling an OSS. Until reading Jason’s quote above, I hadn’t equated it to product development too!

If you want feedback from customers (or potential customers), you’re generally going to get more valuable information by asking questions about them and understanding their situation than by asking what they think about you. Interestingly, this ties in well with the initial empathising phase of Design Thinking.

The OSS / Singapore analogy

Singapore has made some really innovative decisions over the years. Recent ones include tokenisation of the Singapore Dollar on cyber-currencies, investing heavily in international startups based in Singapore and the streamlining of identity management (which will undoubtedly help to get around one of the biggest blockers to self-on-boarding new customers onto comms networks, particularly mobile).

Singapore perhaps lacks the natural commercial advantages (eg mining, manufacturing, agriculture, etc) that some other countries have. Despite that, it has made itself into a significant global player by being an economic and trading hub. It’s a focus on the abovementioned types of innovative thinking that has helped simplify the ability for people to do business in / through Singapore and has been instrumental in it developing a presence that outsizes its natural assets.

OSS falls into a similar category with regards to natural commercial advantages. Most people see OSS as cost centres, which implies having no ability to generate revenues directly (I don’t agree with this perspective, but that’s another story or two).

OSS can take a leaf out of Singapore’s book to out-size its presence – by acting as a highly efficient facilitator of business (and social) activities – but also by diligently identifying innovative ways to improve efficiency even further.

One way is for OSS to take more of a lead in the omni-channel experience as elegantly stated here:
The customer travels across all their channels — online, mobile, IVR, live and more – as they interact with you. You need to travel with them. If your channels aren’t fully integrated, they become just one more source of customer frustration. When you aren’t fully aware of how your customers have engaged with you across all your channels, costs of sales and service rise, and customer satisfaction shrinks.”

Another is through acting as a conduit to trade by doing more to bring its subscribers, all of which are buyers and sellers at some level, together with platform / marketplace / API / service thinking.

Another is through using data to provide marketing / sales / product-dev insights. Taking this further, to provide insightful information as mobile moments.

I’m sure you can think of more angles that take OSS beyond an inward-only facing operations toolset (ie cost centre). Do you have any great Singapore-thinking ideas for OSS to embrace?

Looking outside for innovation strategy

Brainstorms inside the company are useful but not as efficient as stepping outside and checking out the world around you. A lot of companies talk about innovation strategy. I always laugh when I hear that. In this rapidly changing world you cannot talk about innovation strategy anymore. That implies some sort of planning or forecasting the future. Innovation, especially in communication and technology business, you find outside your own company.”
Erik Hoving
here.

There’s a particular telco company that organises OSS RFIs on an almost annual basis. They bring in vendors big and small to demonstrate their best stuff and take careful note of the innovations.

Unfortunately for the vendors / integrators, they’re almost never contracted to do any work for this carrier. However, their best innovations do seem to end up in the carrier’s in-house developed OSS within a year or two. [I should not here that I’ve never dealt with Hoving’s employer so this story is not about KPN].

It seems to me that most of the paradigm shifts in OSS are coming from other digital industries in recent years. I’m blessed to have a large network of highly knowledgeable friends and colleagues who are passionate about tech. PAOSS is another vehicle for looking outside to find relevant innovations but I often feel like there’s so much more I’m missing out on.

I’d love to hear where you “look outside” to find innovation that is relevant / insightful to your OSS trajectory.

The five data stakeholders

When it comes to data stakeholders (people / processes / systems / interfaces / etc), I like to think of them in five categories:

  1. Creators – The primary data creation / collection source, which could be people or machines
  2. Ingestors – The stakeholders that take the source data and compile it into a repository such as a database
  3. Curators / Librarians – The stakeholders that manipulate / reconcile / correlate data in the repository
  4. Presenters – The stakeholders that take data from the repository and distill it for presentation to others
  5. Consumers – The stakeholders that consume the data that by now is hopefully turned into information / insights that are useful enough to do something with

Any given stakeholder might fit into one or more of the categories above BTW.

In OSS, we spend a lot of our time and effort on the first four steps. Ultimately though, it’s the final step that is the most important. If all the steps don’t result in purposeful consumption, then they are effectively wasted. All other data is superfluous to needs.

We perhaps don’t always start with the end in mind – identifying the consumers that need their information curated, distilled and delivered (without asking) in a time-frame that suits their needs. These consumers are usually to pivotal to need the distraction of the irrelevant and don’t care about the preceding four steps (unless there is a gap in the pipeline that impacts their ability to get the right information at the right time).

The question becomes how we figure out what IS relevant. The answer is probably obvious – spending more time with the consumers to understand and refine what they need presented to them. But from the perspective of being proactive, it also means understanding the decision-making process of their role well enough to gather additional, vitally concise information to push to them.

Oh, by the way, there’s one really important point that’s missing from this five-step plan – the entire feedback loop that looks at:

  1. The actions coming from the consumed data / information
  2. The results coming from those actions
  3. Determining how results could be improved through refinement of any / all of the previously mentioned steps in the data stack. This is the hardest, but most valuable part of the entire chain