When is an OOTB OSS Not Really Out of the Box?
When it comes to OSS, the term Out of the Box (or OOTB) can be correct, incorrect and highly confusing all at the same time.
Success in business, distilled to its simplest form, is often about arbitrage. The gap between supply and demand. The gap between value delivered and value received in return.
In the OSS industry, we tend to view arbitrage through a technical lens – better automation, AI, features, use cases, architecture and transformation.
But a recent trip to South East Asia made me wonder whether one of the biggest arbitrage opportunities available to us today are much simpler – treating clients, vendors and partners with more care, generosity and gratitude.
.
I was recently in Indonesia for a family wedding. It wasn’t a holiday. I didn’t visit any beaches. I had too heavy a client workload to properly switch off and enjoy the trip with family in the way I would’ve liked.
And yet, even through that fog of work commitments, something kept standing out.
The warmth. The gratitude. The vastly superior customer service. The craftsmanship. The feeling was evident even in simple daily interactions.
Today’s article stems from a fascination watching people haggling over trinkets of little financial value.
The energy felt vastly different compared with the shopping malls at home.
It made me think about the energy we bring into business relationships, especially in OSS.
This article isn’t a holier-than-thou perspective where you… must… follow… my… suggestions. It’s more of a reminder to myself.
.
When I observe OSS procurement events, partly from an outsider’s point of view because I’m not the end buyer, it can sometimes feel like bartering for trinkets in a market (but with far less warmth).
The vendor tries to protect margin. The procurement team tries to eliminate risk and is incentivised to push price down. The seller tries to avoid inheriting impossible obligations. Both sides try to gain an edge before the real relationship has even begun.
The problem is not negotiation. Negotiation is necessary (obviously). The problem is when negotiation is conducted like the other party is an adversary who you will never interact with again.
Nothing could be further from the truth. For the CFO or the chief negotiators it might be a one-off interaction, but most OSS projects are not. They become multi-year relationships involving delivery, support, roadmap discussions, integrations, data quality, operational change, scope trade-offs, executive pressure and many uncomfortable conversations.
In other words, they aren’t cheap souvenir purchases from someone you will never see again.
They’re almost always long-term partnerships. It’s why I refer to Buyer – Seller relationships as marriages.
This is a theme I have written about before in OSS/BSS procurement is flawed from the outset and the Buyer Seller Chasm series. They question whether the usual procurement KPIs – lowest price, risk elimination and contract control – can unintentionally create a war footing before a project begins. The proposed alternatives are not softer procurement, but better relationships built around trust, team formation and shared objectives.
On reflection:
In our relationships, do we genuinely want our partner to succeed or do we simply want to win each exchange?
.
There’s a big difference between the two.
“How do I get the most from this interaction?” is seeking to extract value.
“How do we make the outcome bigger, better or more useful for everyone involved?” is seeking to create value.
That distinction matters in OSS because so much of the real value is created over the years after the procurement event. It emerges, like in a marriage, through ongoing evolution (discovery, design, delivery, support, product development, integrations, process improvement, adoption and operational learning).
A buyer might extract value by squeezing the commercial terms harder.
A vendor might extract value by limiting interpretation of scope, charging for every variation, or prioritising its own roadmap over the client’s actual operating environment.
Both may be commercially rational….. in the short-term.
But both can also weaken trust and reduce the total mutual value (TMV) available from the relationship [TMV is a term I just made up BTW].
The cheapest deal can become expensive if it leaves one party resentful, defensive or financially cornered. Likewise, the most profitable deal can become fragile if the client feels trapped, under-served or treated as a revenue event rather than a partner.
The older I get, the more I see karma play out as a recurring pattern.
Not as some invisible universal accounting system but as the compounding effect of being useful, generous and trustworthy over time.
To re-use the quote attributed to Maya Angelou:
“People will forget what you said, people will forget what you did, but people will never forget how you made them feel.”
People remember who helped them clarify complexity and learn new things. They remember who gave them something valuable without immediately asking for a purchase order. They remember who cared about the outcome, not just the contract.
I wonder whether part of the problem in OSS is that so many people who work in this industry never even have the chance to see the real client outcomes?
If you’re a product designer, project manager, data scientist, consultant, etc, etc, do you ever see the people at the coal-face, using the OSS you’ve helped build, to do their roles more effectively? Have you sat in the help desks or contact centres of network operators to hear the problems faced by their subscribers and wondered whether the OSS/BSS is helping or hindering that experience?
.
This is not intended as a critique of procurement teams, buyers or clients. As a business owner, it’s primarily a message to myself.
These questions extend way beyond OSS procurement.
In product development, a feature request doesn’t have to be viewed as a backlog entry or a narrow functionality / activity that must be delivered. It can also be a signal to ask questions like:
In support, a ticket is not just a transaction to be closed. It’s often a moment of stress for the client. Something isn’t working. Someone is under pressure. Someone may be losing confidence. There might be a recurring issue that’s causing operational teams ongoing pain. The way we respond can either restore trust or quietly erode it.
In delivery, the goal should not only be to implement what was contractually agreed. It can also be to help the client’s team become stronger, more informed and more capable.
The vendor directory, reports, training, frameworks and materials we provide freely on passionateaboutoss.com serve the same purpose. Of course they help create awareness and (hopefully) build credibility for the PAOSS brand, but the deeper intent is to provide the tools and knowledge that helps the OSS industry.
To take this concept further:
The mirror principle suggests that what you put out gets reflected back. Generosity begets generosity. Kindness begets kindness. Adversarial behaviours beget adverse behaviours in return. Avoidance of risk gets risk pushed back at you. Cost minimisation strategies establish aggressive change request behaviours. A smile begets a smile.
I’m not naive enough to think the mirror principle results in perfect reflections, especially in the business world where a culture of profit at all costs seems to prevail. Regardless, I still need to channel more of the energy of South East Asia.
.
This inevitably brings me to AI (is there a single article written today that doesn’t?)
The OSS industry is already looking at AI through many lenses, mostly technical ones – automation, orchestration, assurance, root-cause analysis, network operations, code generation, documentation, analytics and support. Those are all valid.
But I feel that it drastically minimises arbitrage opportunities that rely solely on technical factors? That’s AI’s forte after all.
But if everyone is focusing on the technical and transactional, does it leave behind bigger arbitrage opportunities around generosity, kindness, empathy, trust, etc?
I can’t help but feel that many of the world’s tech behemoths are treading a fine line between offering irrefutable value and facing a backlash for breach of trust.
Clearly AI just magnifies intent:
The question I ponder is whether amplifying #1 is actually the best way of achieving #2 rather than just going straight to #2?
Used with a transactional mindset, AI may simply help us extract more. More automation. More cost reduction. More pressure. More output with less human contact. Faster responses that somehow feel less caring.
Used with a generous mindset, AI could help us create more. More insight. More clarity. More accessible expertise. More tailored support. More carefully crafted tools. More ways to help clients and the industry thrive.
It feels like the technology is not the differentiator. The intent is.
.
That’s the resonant thought I brought home from the trip.
A strong feeling that the next biggest arbitrage opportunity is relational. Just like it always has been perhaps???
I’m so far from perfect in this regard, that the final reminder to myself is to bring more empathy and generosity into what I do – before, during and after a deal (or maybe just totally independently of a deal?).
As always, I’d love to hear your thoughts!
When it comes to OSS, the term Out of the Box (or OOTB) can be correct, incorrect and highly confusing all at the same time.
Since OSS were first built, they’ve been designed around the belief that more complete information creates better operations. That belief made sense when they were
An OSS/BSS transformation often begins with excitement and urgency due to a desperate need for change. It also creates trepidation because the wrong decision could
Daniel Priestley recently highlighted something as important for business owners as telcos seeking out their next OSS or BSS solution: “If I said to you,