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 OSS Think Big juxtaposition

I recently saw the advertisement below:

I’ve clipped only the last 10 seconds because that was the part that struck me. The ad is for BHP*, one of the world’s largest miners. The mining industry thinks in long-term projects because it takes many years to deliver results – for exploration, planning, approvals, for the infrastructure to be built and operationalised, etc.

Mining is “only” the process of pulling natural resources out of the ground, but despite all our complexities, mining projects tend to be far more complex than for OSS. The decade-long duration of projects means that technologies that were originally included in plans frequently become obsolete mid-flight and have to be re-planned. That means major contracts also need to be obsoleted and re-planned mid-flight. Work-force management has a completely different scale than for OSS.

Mining thinks in time-frames of decades. OSS transformations are planned in time-frames of years. OSS delivery, especially Agile deliveries, often only think in quarters (or much, much less).

In OSS, do we really Think Big?

But there’s a twist on this question. In the rare cases when we do think big, are we constraining ourselves by then following into the “deliver big” mindset too? In OSS, I’ve always felt that we deliver most efficiently when very small numbers of very clever people group together.

So there’s the juxtaposition with the clip above – Think Big… Think Small.

When you’re thinking of OSS roadmaps, what’s your thinking time-frame?

* For disclosure, I’m not an investor in BHP to my knowledge, but perhaps my super fund is.

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?

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).

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?

From pipeline to platform

Amazon established an architecture to leverage its assets for implementing a wide range of business models in a repeatable way for the retail industry. In most cases, Amazon is exposing product offerings it doesn’t actually own. It carries some inventory for third parties, but its main tasks now are vetting retail partners, ensuring product quality, giving partners access to the marketplace, and arranging payment and delivery of purchases. The company’s business model is to provide an ever-growing number of products through a broad, simple solution that’s fast, efficient and highly effective.
A similar level of speed and efficiency is possible when the same approach is applied to an operator’s architecture. Easy access, exposure of product information, a managed ecosystem of partners, a simple solution that hides background complexity – many of the same things that make it so easy to shop with Amazon – can transform the way our products are created, modified, assembled, offered, personalized and delivered. In other words, operators need architectures that support platform business models analogous to the Amazon architecture to onboard offers from many, connecting suppliers to consumers and monetizing the end solution with settlement of payments to those involved. Many platforms are possible because of technology, but they’re successful because of trust among ecosystem partners, curator and consumers
.”
From TM Forum’s “Digital Platform Reference Architecture Concepts and Principles” (IG1157 Release 17.0.0)

A recent post entitled, “I want a business outcome, not a deployment challenge,” discussed cloud deployment, hosted service offerings and trust – three important considerations to the Amazon-style platform play for future CSP business models.

Neither the architecture or the trust currently tends to exist to allow most telcos to follow a model where, “its main tasks now are vetting retail partners, ensuring product quality, giving partners access to the marketplace, and arranging [e-]payment and [e-]delivery of purchases.” Some telcos are already going down the path of complete transformation to services-driven platforms (ie SOA). This is as much for offering (web) services to internal silos as it is to external customers.

The real platform play will only happen when the “internal” services are also opened up to third-parties to provide, not just consume.

I want a business outcome, not a deployment challenge

We can look and take lessons on how services evolved in the cloud space. Our customers have expressed how they want to take these services and want a business outcome, not a deployment challenge.”
Shawn Hakl
.

Make no mistake, cloud OSS is still a deployment challenge (at this nascent stage at least), but in the context of OSS, Shawn Hakl’s quote asks the question, “who carries the burden of that deployment challenge?”

The big service providers have traditionally opted to take on the deployment challenge, almost wearing it as a badge of honour. I get it, because if done well, OSS can be a competitive differentiator.

The cloud model (ie hosted by a trusted partner) becomes attractive from the perspective of repeatability, from the efficiency of doing the same thing repeatedly at scale. Unfortunately this breaks down in a couple of ways for OSS (currently at least).

Firstly, the term “trusted partner” is a rare commodity between OSS providers and consumers for many different reasons (including trust from a security perspective, which is the most common pushback against using hosted OSS). Secondly, we haven’t unlocked the repeatability problem. Every organisation has different networks, different services, different processes, even different business models.

Cloud-hosted OSS represents a big opportunity into the future if we first focus on identification of the base ingredients of repeatability amongst all the disparity. Catalogs (eg service catalogs, product catalogs, virtual network device catalogs) are the closest we have so far. Intent abstraction models follow this theme too, as does platform-thinking / APIs. Where else?

Functional silos can be dysfunctional

OSS are often delivered into large organisational structures, structures that are functionally siloed. For large OSS, even the OSS team can have multiple functional silos.

Where there are functional silos, there are activities within OSS that need to be delivered across silos. That’s where things can get a bit dysfunctional. Jurisdictions, ownership of responsibilities, agreements on approach, misalignments of performance indicators, downstream impacts and dare I say it, turf wars, can make it more difficult to deliver an OSS organisationally than technically… and OSS can be incredibly difficult to deliver from a technical perspective.

Organisational change management is often completely overlooked, or only brought to bear far too late in the delivery process. Often there are so much dysfunction between silos, even where each silo has the best of intentions, that a bigger change management accord needs to be invoked.

These include:

  • A burning platform – communicating the need for urgent, radical changes brought about by dire circumstances
  • A moon shot – focussing the attention of the entire organisation on incredibly ambitious challenge
  • Dictatorship of decision making rather than democracy

Alternatively, insert any other method to help ensure all members of the team, across all silos, have a clear understanding of the greater objectives the team is trying to meet. I’d love to hear of examples that you’ve invoked to get great team results on complex OSS projects (or any other project type for that matter).

When in doubt, connect

When in doubt, connect.
That’s what fast-growing, important organizations do.
Making stuff is great.
Making connections is even better
.”
Seth Godin
in his post here.

Simple words. Simple concept. Interesting message…. with a traffic-light of OSS layers.

Layer 1 – A connection red light
The more connections an OSS has, the more enriched the data tends to become. However, by contrast the more interconnected an OSS gets, the more inflexible and difficult it gets to maintain. The chess-board analogy and the handshake analogy attest to the challenges associated to a highly connected OSS. In this case, when in doubt, don’t connect.

Layer 2 – A connection orange light
Five of the top seven companies (by market cap) in the world are tech companies (1. Apple, 2. Alphabet (Google), 3. Microsoft, 6. Amazon, 7. Facebook). They have become valuable through the power of connection. China Telecom represents one of the original connectors, the telecommunications carriers, and just makes it into the top 10 whilst Verizon and AT&T are both worth over $250B too. Our OSS allow these connections to be made – but they’re making a connection “for” the customer rather than making a connection “with” the customer. Until brand-OSS starts making a connection with the customers, we’ll never be fast growing like the tech titans. When in doubt, connect at a deeper level.

Layer 3 – A connection green light
Tripods or Linchpins are the most valuable of OSS resources because of their ability to connect (ideas, people, products, workflows, contracts, etc). They are the pinnacle of OSS implementers because their breadth of connections allows them to interconnect the most complex of OSS jigsaws. If you want to become an OSS tripod, then Seth’s lead is a great one to follow – When in doubt, connect.

OSS billionaires with perfect abs

If [more] information was the answer, then we’d all be billionaires with perfect abs.”
Derek Sivers
.

The sharing economy has made a deluge of information available to us at negligible cost. We have more information available at our fingertips than we can ever consume and process. So why don’t we all have massive bank balances and perfect abs? (although I’m sure most PAOSS readers do of course)

The answer is that information is only as good as the decisions we are able to make with it. More specifically, the ability to distill the information down to the insights that compel great decisions to be made.

As OSS implementers, we can easily bombard our users with enough information calories to make perfect abs an impossible dream. Too easily in fact.

It’s much harder to consistently produce insights of great value. Perhaps it even needs the unique billionaire’s lens to spot the insights hidden in the information. But that’s what makes billionaires so rare.

Herein lies the message I want to leave you with today – how do us OSS Engineers train ourselves to see information more through a billionaire / value lens rather than our more typical technical lenses? I’m not a billionaire so I (we?) spend too much time thinking about technically correct solutions rather that thinking about valuable solutions. Do we have the right type of training / thinking to actually know what a valuable solution looks like?

Is commission management the key for next-gen OSS?

Relationships with the things we ‘consume’ (rather than ‘own’) are increasing, and are being governed by ongoing supply arrangements between customers and vendors. What sits at the heart of these relationships, from a financial perspective, is billing. The entity that has the billing relationship with the customer essentially ‘owns’ the customer – they have the right to communicate with the customer regularly, and this can form the basis of a far deeper customer relationship.”
David Werdiger
in his article “The Own-Lease-Rent-Subscribe Continuum“.

The snippet above is just a small part of a very interesting article about asset utilisation and ownership structures. The continuum that David speaks of is increasingly presenting opportunities towards the subscribe / consume end and breaking down barriers to entry for those with entrepreneurial spirit.

This has implications for our OSS from a number of angles. OSS are typically expensive to buy or build or run, as are the networks that they manage. As a result, in years past the only opportunities arising from these assets were for their owners, the communications service providers (CSPs).

The subscribe end of the continuum allows CSPs to share the capital risk with customers, which has traditionally been done via the selling of comms services. But with comms services commoditising, innovative subscription models become a more attractive way of sharing the risk. These include virtual network operators, off-payroll sales agents, managed service offerings and the like.

We’ve spoken previously about how APIs allow third-parties to uplift and upsell services offered by CSPs. From a similar, but slightly different perspective, efficient / effective commission management functionality within your OSS / BSS effectively extends and incentivises the sales arm of any business (whether internal or external). You don’t need as many (any?) salespeople on the payroll, but you are still selling… if you incentivise the commission management process and associated earnings.

Whether additional selling and consumption is supported via human interfaces such as portal / UI or via machine interfaces such as API / microservices, it’s ultimately the billing that allows ownership of the customer. CSPs still have a significant strength from their billing base and clever design of our OSS / BSS can help to leverage that further in the consumption economy.

Could you replace a 150-person OSS team with just 1?

In 1998 Berkshire Hathaway acquired a reinsurance company called General Re. “The only significant staff change that followed the merger was the elimination of General Re’s investment unit. Some 150 people had been in charge of deciding where to invest the company’s funds; they were replaced with just one individual – Warren Buffett.
Robert G. Hagstrom
in, “The Warren Buffett Way.”

Following on from yesterday’s post about Warren Buffett’s prioritisation techniques and the recent series about the “frenzy of doing,” I was reminded of the staggering story at General Re described above.

Buffett was able to replace 150 people, and significantly outperform them, because they were performing (relatively) small value, high volume transactions and he was, well, the opposite.

OSS implementation and long-play investing are obviously very different in terms of resource requirements, but if we were to draw on this story, how would we replace whole OSS teams with just one person (or a small handful of people)?

Most CSPs have vast numbers of people who build and maintain their OSS. For most of those CSPs, the OSS isn’t the core business; in fact OSS is a cost of doing business; so does it really even make sense to have so many OSS people on staff?

How do you think this analogy stacks up:

  • Remove the legions of resources who are performing high volume, low value, transactional updates to the OSS
  • Replace them with one person who has a mindset of simplification, long-term outcomes and only betting big on the most strategic of changes
  • Outsource operations of the OSS to partners who have a strong track record of return on capital, just as Buffett avoids having to manage the companies he acquires by only investing if they are led by strong management teams who have a proven ability to deliver returns

One major chink in this strategy is that it is much easier to divest of bad stocks and wait until the right investment comes along, as opposed to making in-flight transformation of the tools a CSP needs to run all parts of its business (eg sales, engineering, field-work, etc).

If you were told you HAD to replace a team of 150 OSS implementers with one person, what would your strategy be?
Even if not being quite so drastic, could elements of your strategy work within your current OSS environment?

Alternatively, if you represent an OSS vendor that offers managed services, do you have the data to prove that you deliver strong returns on a customer’s invested capital?

Should your OSS have an exit strategy in mind?

What does the integration map of your OSS suite look like? Does it have lots of meatballs with a spaghetti of interconnections? Is it possibly even too entangled that even creating an integration map would be a nightmare?

Similarly, how many customisations have you made to your out-of-the-box tools?

In recent posts we’ve discussed the frenzy of doing without necessarily considering the life-time costs of all those integrations and customisations. There’s no doubt that most of those tweaks will add capability to the solution, but the long-term costs aren’t always factored in.

We also talk about ruthless subtraction projects. There are many reasons why it’s easier to talk about reduction projects than actually achieve them. Mostly it’s because the integrations and customisations have entwined the solutions so tightly that it’s nearly impossible to wind them back.

But what if, like many start-ups, you had an exit strategy in mind when introducing a new OSS tool into your suite? There is an inevitability of obsolescence in OSS, either through technology change, moving business requirements, breakdowns in supplier / partnership relationships, etc. However, most tools stay around for longer than their useful shelf life because of their stickiness. So why not keep rigid control over the level of stickiness via your exit strategy?

My interpretation of an exit strategy is to ensure by-play with other systems happens at data level rather than integrations and customisations to the OSS tools. It also includes ruthless minimisation of snowball dependencies* within that data. Just because integrations can be done, doesn’t mean they should be done.

* Snowball dependencies are when one builds on another, builds on another, which is a common OSS occurrence.

Telcos still innovate… but more by proxy now

CSPs globally are trying to be innovative, and being heavily involved in tech since their earliest days, always perceive themselves to be innovative to their core (yes, bad pun).

There’s no doubt that there is a lot of innovation happening in large CSPs, but I wonder how much of it is really attributable to the CSP? Much of the change swirling through our organisations (or customer organisations) has been designed elsewhere. SDx (Software Defined Everything) was invented elsewhere (as were IP networks prior), IoT, CI / CD, Agile, Design Thinking, User Experience (UI/UX), AR/VR, AI/ML, open-source and all the other modern buzz-words.

Telcos do come from innovative roots when you look back at what Bell Labs, BT Research, Telstra Research Labs, or most other major telcos were doing globally in the early-mid 1900s. They defined not just telco but developed ground-breaking primary research into transistors, microwaves, satellites, lasers, communications theory, etc. Since this golden era, they’ve increasingly delegated the innovation process to suppliers. The same is true in our OSS. OSS were originally invented by telcos, but suppliers largely frame the story now.

In many recent blogs, including yesterday’s on network vs digital variants, we’ve discussed ways to invent new, more profitable revenue streams… revenue streams that will in turn fund exciting new OSS projects.

But I also wonder whether the reverse is true? If a telco was to discard the addiction to innovation and take on the utility mindset – providing ubiquitous, bullet-proof, regulated supply of long-haul and wide-spread access networks – would that be a better fit for these large, highly regulated enterprises?

They tend to have the natural moat in their networks – the cables and spectrum that require too much capital for others to easily replicate and compete, but whose physical assets have long useful lives. If they remove the constant need to constantly invest in change then their cost structures will arguably reduce more quickly than their revenues are dipping (yes, that means profitability increases). That gives the opportunity to focus on doing things simpler and better rather than doing things newer.

Have many CSPs long since lost the innovation war? Is their innovation primarily by proxy (through partners and suppliers), acquired rather than earned? Many factors work against them ever recapturing the innovative lead that they once held. So why not just admit it and let the innovators innovate, incubating partnerships rather than competing?
The answer is because that’s anathema to these organisations (and the people who drive them), which still perceive themselves to be innovators, perhaps akin to the aging Lothario with the comb-over and expanding waistline dreaming of his younger days.

Would the OSS market look much differently if CSPs were to all “age gracefully” with respect to innovation and take a different approach to the inventiveness that still surrounds them?

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?

The three big lies of the telecoms industry

What are the three big lies of the telecoms industry?
The first lie is that data monetisation is coming. Well we are still waiting.
The second is that we have billions of customers. Well are they really our customers or are they people who just tolerate us and are really customers of someone else?
The third lie is that we are utility so we have stable returns, and because we have spectrum allocations that is our safety net. EBITDA multiples for the telco industry were at around 6, while utilities were at multiples of 12 to 16, so it could not be said that telcos – which often had up to five competitors in markets – were utilities
.”
Alexey Reznikovich

Three valid points. OSS / BSS could be highly influential in whether these are actually lies or not.

Data:
If we think of data as carriage, that’s clearly not monetising for most telcos currently. Well, it does bring in revenues but at a diminishing rate per bit. If we think of data in terms of content (eg voice, video, text, etc), then there are some monetisation wins (eg Game of Thrones) but more content is coming on line so there is more supply, making the profitability tail longer. If we talk about data as insight (or supporting the generation of insights if selling analytics or API offerings) then this will never go out of fashion (although with more “insights” being generated, the bar will be raised on what is truly insightful)

Customers:
Alexey’s note here that our customers just tolerate us and are really customers of someone else possibly has some merit. It’s the reason why the OTT play has been so successful. I still have the sense that there is an implicit trust in our service providers, due to the long subscription/billing history, media / shareholder attention on them and regulation that governments place on them (even if not an implicit trust in their customer service). Not all OTT players have the same track record of regulatory governance. Some OTT providers are invisible, hidden somewhere out on the cloud. I feel that this could represent a strong opportunity in a world where crypto-currencies carry vastly more value than they do today.

Utilities:
This comes down to the business model of any given Telco and / or the regulatory frameworks they operate within. They could opt to go down the path of ubiquitous data (like ubiquitous voice of the distant past), or like most, they can go down the path of being a digital service provider. To be honest, there are probably quite a few incumbent providers that are probably more closely aligned to utility than DSP in the collective way of thinking within their workforce. That often transfers to their mindset in building OSS.

Is OSS tech-debt good debt or bad debt?

But what if it’s ALL tech-debt?
Everything we build needs to be supported for its natural life. The more we accumulate, the more that needs supporting. Support represents all the debt we leave behind, like going on a credit-card fuelled spending spree. And like any other debt, the more you collect, the more it compounds (due to the handshake analogy).”
More details here.

If we consider every investment of effort or cash in our OSS as a debt of support that the organisation has to carry forward, does it change our expectation of what we need from our OSS in return?

Taking on debt to buy assets (eg property, shares, businesses) is considered good debt. Taking on debt to buy stuff that produces no financial return is considered bad debt.

By that definition, is the expenditure of time and cash on our OSS good debt or bad debt?

Are all of our efforts producing:

  1. A tangible financial benefit
  2. An intangible benefit or
  3. No perceivable benefit at all

I suspect that in most environments it’s probably all of the above but heavily weighted towards B.

Clearly we need mechanisms to drive more of our tech debt into A initiatives. That means more “revenue generation” thinking though.

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?

The interview question tech recruiters will never ask, but should

Over the last few days, this blog has been diving into the career steps that OSS (and tech) specialists can make in readiness for the inevitable changes in employment dynamics that machine learning and AI will bring about.

You’ve heard all the stories about robots and AI taking all of our jobs. Any job that is repeatable and / or easy to learn will be automated. We’ve also seen that products are commoditising and many services are too, possibly because automation and globalisation is increasing the supply of both. Commoditisation means less profitability per unit to drive projects and salaries. We’ve already seen how this is impacting the traditional investors in OSS (eg CSPs).

Oh doom and gloom. So what do we do next?

Art!

That leads to my contrarian interview question. “So, tell me about your art.”

More importantly, using the comments section below, tell me about YOUR art. I’d love to hear your thoughts.

FWIW, here’s Seth Godin’s definition of art, which resonates with me, “Art isn’t only a painting. Art is anything that’s creative, passionate, and personal. And great art resonates with the viewer, not only with the creator.
What makes someone an artist? I don’t think it has anything to do with a paintbrush. There are painters who follow the numbers, or paint billboards, or work in a small village in China, painting reproductions. These folks, while swell people, aren’t artists. On the other hand, Charlie Chaplin was an artist, beyond a doubt. So is Jonathan Ive, who designed the iPod. You can be an artist who works with oil paints or marble, sure. But there are artists who work with numbers, business models, and customer conversations. Art is about intent and communication, not substances
.”

If we paint our OSS by numbers (not with numbers), we’re more easily replaced. If we inspire with solutions that are unique, creative, passionate and personal, that’s harder for machines to replace.

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?