How and why we need to Challenge our OSS Beliefs

The OSS / BSS industry tends to be quite technical in nature. The networks we manage are technical. The IT stacks we build on are technical. The workflows we design are technical. The product offerings we coordinate are technical. As such, the innovations we tend to propose are quite technical too. In some cases, too technical, but I digress.

You would’ve no doubt noticed that the organisations garnering most attention in the last few years (eg the hyperscalers, Airbnb, Uber, Twitter, Afterpay, Apple, etc) have also leveraged technology. However, whilst they’ve leveraged technology, you could argue that it’s actually not “technical innovation” that has radically changed the markets they service. In most cases, it’s actually the business model and design innovations, which have simply been facilitated by technology. Even Apple is arguably more of a design innovator than a technology innovator (eg there were MP3 players before the iPod came along and revolutionised the personal music player market).

Projects like Skype, open-source software and hyperscaled services have made fundamental changes to the telco industry. But what about OSS/BSS and the telcos themselves? Have we collectively innovated beyond the technical realm? Has there been any innovation from within that has re-framed the entire market?

As mentioned in an earlier post, I’ve recently been co-opted onto the TM Forum’s Transformation User Group to prepare a transformation framework and transformation guides for our industry. We’re creating a recipe book to help others to manage their OSS/BSS/telco/digital transformation projects. However, it only dawned on me over the weekend that I’d overlooked a really, really important consideration of any transformation – reframing!

Innovation needs to be a key part of any transformation, firstly because we need to consider how we’ll do things better. However, we also need to consider the future environment in which our transformed solutions will operate within. Our transformed solution will (hopefully) still be relevant and remain operational in 5, 10, 15 years from now. For it to be relevant that far into the future, it must be able to flexibly cater for the environmental situation in the future. Oh, and by the way, when I say “environment,” I’m not talking climate change, but other situational change. This might include factors like:

• Networks under management
• Delivery mechanisms
• Business models
• Information Technology platforms 
• Architectural models
• Process models
• Staffing models (vs automations)
• Geographical models (eg local vs global services)
• Product offerings (driven by customer needs)
• Design / Develop / Test / Release pipelines
• Availability of funding for projects, and is it capex, opex, clip-the-ticket, etc
• Risk models and risk adversity level
• etc

Before embarking on each transformation project, we first need to challenge our current beliefs and assumptions to make sure they’re still valid now, but can remain valid into the next few years. Our current beliefs and assumptions are based on past experiences and may not be applicable for the to-be environment that our transformations will exist within.

So, how do we go about challenging our own beliefs and assumptions in this environment of massive, ongoing change?

Well, you may wish to ask “re-framing questions” to test your beliefs. These may be questions such as (but not limited to):

1. Who are our customers (could be internal or external) and how do they perceive our products? Have we asked them recently? Have you spent much time with them?
2. What is our supply chain and could it be improved? Are there any major steps or painful elements in the supply chain that could be modified or removed
3. Are these products even needed under future scenarios / environments
4. What does / doesn‘t move the needle? What even is “the needle”
5. What functionality is visible vs invisible to customers 
6. What data would be useful but is currently unattainable 
7. Do we know how cash flows in our clients and our own companies in relation to these solutions? Specifically, how value is generated
8. How easy are our products to use? How long does it take a typical user (internal / external) to reach proficiency 
9. What personas DO we serve? What personas COULD we serve? What new personas WILL we serve
10. What is the value we add that justifies our solution’s existence? Could that value be monetised in other ways
11. Would alternative tech make a difference (voice recognition, AI, robotics, observability, biometric sensors, AR/VR, etc)
12. Are there any strategic relationships that could transform this solution
13. What does our team do better than anyone else (and what are they not as strong at)
14. What know-how does the team possess that others don’t
15. What features do we have that we just won’t need? Or that we absolutely MUST have
16. Are there likely to be changes to the networks we manage
17. Are there likely to be changes to the way we build and interconnect systems
18. Where does customer service fall on the continuum between self-service and high-contact relationships
19. What pricing model best facilitates optimal use of this solution (if applicable) (eg does a consumption-based usage / pricing model fit better than a capital investment model?). As Jeff Bezos says, “Your margin is my opportunity.” The incumbents have large costs that they need to feed (eg salaries, infrastructure, etc), whereas start-ups or volume-models allow for much smaller margins
20. Where are the biggest risks of this transformation? Can they be eliminated, mitigated or transferred
21. What aspects of the solution can be fixed and what must remain flexible
22. What’s absorbing the most resources (time, money, people, etc) and could any of those resource-consumers be minimised, removed or managed differently

It also dawns on me when writing this list that we can apply these reframing questions not just to our transformation projects, but to ourselves – for our own personal, ongoing transformation.

I’d love to get your perspective below. What other re-framing questions should we ask? What re-framing exercise has fundamentally changed the way you think or approach OSS/BSS/personal transformation projects?