Most OSS/BSS Professionals don’t Prove their Value because…

I have a really important question for you to ask yourself today. It’s a question that shapes a lot of our thinking about how I can help the OSS/BSS/telco industry.

How does what I do make more money for clients?

Not just what your company does. Not what your brand says on the website. Not the broad category we sit in.

What do YOU do, specifically, day-to-day, that creates commercial value for a client?
Do you really know where commercial value flows through your organisation and your role specifically?

Those sound like simple questions. They aren’t, especially for techies!

Most people in OSS/BSS can describe their activities. They can describe their deliverables. They can describe their domain expertise. But far fewer can draw a straight line from their own day-to-day work to a measurable commercial outcome for the client.

Collectively, we need to get better at this to prove to all the non-believers just how valuable OSS/BSS people and projects are to the telco industry (or energy, or enterprise, etc industries that also rely on OSS/BSS tools).

A solution architect might say they create target-state designs. A product manager might say they shape roadmaps and prioritise features. A project manager might say they coordinate delivery and reduce risk. Here at PAOSS, we might say we help clients make better transformation decisions, faster.

All of that may be true.

But none of it is yet the real answer.

The real answer is only found when you can explain how your work improves one or more of these commercial levers:

1. Revenue growth
2. Cost reduction
3. Risk reduction
4. Speed of execution
5. Capital efficiency or
6. Decision quality

Better still, we need to be able to show which in-flight metrics indicate value is already being created long before a full transformation goes live.

That matters here at PAOSS in particular because most of what we do is during the pre-implementation phase.

The same is true for many people in the OSS/BSS industry. Chances are you either work on pre-implementation or implementation phase activities.

It can be months or years before the real value is realised via a transformed OSS/BSS stack. It’s when the stack is handed over to the operational phase where one or more of the commercial levers above tend to start being realised.

We are the people helping shape the decisions, designs, trade-offs, priorities and plans that determine whether the downstream investment ever has a chance of succeeding.

So how, with those constraints in mind, how do we answer the initial question properly?

Here is a step-by-step process that we use.

Step 1: Stop describing activities. Start describing economic effect

Most professionals answer the question at the wrong level.

They say things like:

• I create architecture documents
• I manage stakeholders
• I define requirements
• I run vendor evaluations

Those are activities. Clients don’t buy activities. They buy outcomes.

The better question is this:

What changes for the client because I did that work well?

For example, PAOSS doesn’t create value merely by producing a shortlist or a roadmap. The value comes from compressing decision time, improving decision confidence, reducing rework and increasing implementation readiness. That leads to better investment choices, fewer dead ends and faster mobilisation. In short – trust, risk and fear minimisation.

A solution architect does not create value merely by drawing boxes and arrows. They create value by reducing future integration failure, exposing hidden dependencies early and preventing expensive redesign later.

A product manager does not create value merely by maintaining a product roadmap and backlog. They create value by ensuring scarce investment is directed toward features with the highest commercial leverage (ie product differentiation, value-creation for clients, pain-point removal, etc).

A project manager does not create value merely by updating status reports. They create value by reducing slippage, improving coordination between stakeholders and keeping the cost of delay under control.

Your first task is to convert “what I do” into “what commercial effect my work creates”.

Step 2: Identify the value lever you influence most directly

Not every role influences revenue in the same way. Some roles have direct impact. Others have indirect but still powerful impact.

This is true of OSS/BSS too. They’re often seen as creating intangible value. We need to turn intangibles into obvious, tangible value through the way we describe what we’re building. The diagram below shows that OSS/BSS underpin an entire telco business model, including operational and commercial outcomes:

Most value in OSS/BSS sits in one or more of six levers:

1. Revenue generation and acceleration
2. Revenue protection
3. Cost reduction
4. Capital efficiency (partly via operational efficiency)
5. Risk reduction
6. Decision speed and confidence

For many pre-implementation roles, the last two are the real starting point.

That is certainly true for PAOSS. In many of our engagements, we are not implementing systems ourselves (although we’ve done a lot of them in the past and often assist clients with implementation advisory today). We are helping clients understand the market, define scope, assess options, avoid blind spots and build a transformation path that can actually survive contact with delivery. Our most direct lever is not immediate revenue. It’s decision advantage.

That means our value is often expressed through measures such as:

1. decision cycle time (via reduction of fear, improved confidence and risk minimisation / mitigation)
2. stakeholder alignment
3. option quality
4. requirement clarity
5. rework avoidance
6. time to mobilisation

Once you identify your primary lever, your value story becomes much easier to articulate.

Step 3: Work backwards from money to your specific contribution

This is the step that I suspect most people skip. Most techies are in it for the tech. But the tech is just a means-to-an-end.

The following step is something we’ve had to really focus in on at PAOSS:

Take the final commercial outcome and reverse-engineer the chain.

For PAOSS, the logic might look like the following and is the key reason we use The Inverted Pyramid Approach for OSS/BSS Vendor Selection:

1. Better market scan and clearer transformation framing leads to stronger option selection
2. Stronger option selection leads to fewer resets and less misallocated spend
3. Fewer resets and less misallocated spend lead to faster mobilisation and better ROI
4. Faster mobilisation and better ROI lead to earlier and more reliable value realisation
5. Moreover, shrinking a vendor selection process from 18-24 months down to ~3-5 months strips a huge cost burden from OSS buyers and sellers alike
6. When added to freeing up internal resources to focus on their BAU activities, it can literally save the OSS buyer millions

For a solution architect:

1. Better dependency mapping and complexity reduction leads to a clearer understanding of not just the ideal end state, but the stepping stone state changes required to get there
2. This leads to fewer transformation and integration surprises
3. Fewer integration surprises lead to fewer delivery delays and change requests
4. Fewer delays and change requests lead to lower cost and faster go-live

For a product manager:

1. Better understanding of client needs identifies a pipeline of features that clients desire
2. Better prioritisation leads to focus on high-value features
3. Focus on high-value features leads to better differentiation, adoption, conversion, client satisfaction and/or retention
4. That leads to stronger revenue or reduced churn

For a project manager:

1. Better understanding of project outcomes and dependencies allows for complexity reduction, backlog clarity and better understanding of stakeholder roles and responsibilities (see our Ultimate Framework for Planning Large-Scale OSS Transformations)
2. Better backlog sequencing, task allocation and governance lead to fewer blockers and less idle time
3. That leads to more predictable delivery and lower cost of delay
4. That improves ROI on the programme
5. This shortens project delivery times

The key is to keep asking, “and then what?” until you reach a real business outcome.

Step 4: Define the in-flight metrics that prove value is being created

Unfortunately for many of us, if you only choose end-state metrics, many of them will not become visible until long after your part of the work is finished. But we need to prove our value in-flight. That’s a serious problem for strategic advisory, design and pre-implementation roles.

And I should note that this becomes even more important in a world of AI where telling or documenting is easily replicated but showing / doing / delivering becomes far more valuable for clients.

So you need in-flight proxy metrics that show value creation is already happening.

For PAOSS, useful in-flight metrics might include:

• slashing decision cycle time (as a supplier, the aim is to get in, help decisions get made and get out, as opposed to time-and-materials contracts that incentivise complexity and decision delays)
• increase in stakeholder alignment score
• percentage of transformation artefacts that are rapidly implementation-ready for stakeholders to coordinate from, not just procrastination mechanisms
• reduction in decision-to-action lag
• number of viable options assessed before commitment (but leaving a breadcrumb trail that eliminates the need for future reassessment)
• reduction in procurement rework or shortlist resets

For a solution architect:

• number of critical dependencies identified early
• percentage of interfaces or domains covered by design
• number of unresolved design assumptions over time
• architecture completeness score
• reduction in downstream design changes
• slashing decision cycle time (one and done, not analysis paralysis)
• percentage of designs that get funded (due to clarity, predictability, risk mitigation, ROI persuasiveness, etc)

For a product manager:

• percentage of backlog linked to measurable business outcomes
• prioritisation confidence score
• time from idea to validated decision to product release
• ratio of roadmap items with quantified business case (as verified by clients, not internally)
• reduction in low-value feature carryover (ie focus on the left-side of the long-tail diagram – see here)
• amount of suck subtracted (refer to this article about subtracting the suck)
• number of clients requesting take-up of new features
• reduction in process cycle time (ie the time it takes an operator to perform an e2e workflow)

For a project manager:

• schedule variance (or even better, schedule reduction)
• blocker resolution time
• decision turnaround time
• replan frequency
• client, third-party and other stakeholder engagement and on-time task completion
• percentage of milestones achieved on first pass

These are not vanity metrics. They are evidence that uncertainty is collapsing, clarity is improving and the path to value is getting shorter.

Step 5: Build a baseline comparison

Metrics only matter when they show change. A single number in isolation rarely proves anything. A trend does.

Not every project has a before-current-after metric during pre-implementation or even implementation phases. These often only get proved during the operational phase.

But, if we can, we can consider how to build a baseline that we can compare against.

It’s not always possible, but we can ask:

• What was the client’s baseline before my involvement?
• What was the expected project / milestone timeline vs. what was delivered?
• What improved during the engagement?
• What became easier, faster, clearer or lower-risk because of the work?
• Are predicted in-flight outcomes being realised?

For example:

PAOSS might show that a client’s traditional vendor selection process would have taken 18 to 24 months, involved dozens of internal stakeholders and produced a narrow shortlist based on familiar names. With our Inverted Pyramid approach, the client might reach a better-informed shortlist in weeks, with broader market coverage, stronger evidence and less internal effort.

A solution architect might show that complexity reduction mapping reduced cross-domain dependencies from 27 to 5.

A product manager might show that only 30 percent of roadmap items were previously tied to measurable business outcomes, but now 85 percent are. Alternatively, that features delivered a long-tail y-axis benefit of 500,000 transactions per month rather than 10,000.

A project manager might show that decision turnaround times fell from three weeks to four days or that release cadence went from 3 features to 10 features being delivered to the client per week.

Using these examples, does value stop sounding theoretical (especially when compared with the list of activities we started with in Step 1)?

Step 6: Turn your value story into one sentence

Once you have worked through the logic, force yourself to compress it.

At PAOSS, one possible version is:

We help clients to reduce the breadth of the Buyer Seller Chasm

(ie we help clients make faster, higher-confidence OSS/BSS procurement decisions that reduce effort, avoid rework and accelerate implementation readiness)

A solution architect might say:

I reduce the cost of future delivery failure by pragmatic reduction of complexity before it becomes expensive

A product manager might say:

I turn limited product investment into features that our clients love because they deliver greater efficiency and better commercial outcomes

A project manager might say:

I strip away complexity, unnecessary documentation and stakeholder discourse, turning effort into coordinated forward motion to deliver project outcomes earlier

.

The real challenge

Unfortunately many people in our industry are unbelievably intelligent, capable and hard-working, but are unable to describe the value they truly create, so they end up being undervalued.

That’s not because they don’t create value. It’s because they’ve never articulated the chain between their work and the client’s economics.

Once you do that, two things happen.

First, you stop sounding like a person who performs tasks and start sounding like a person who understands AND moves commercial levers.

Second, your clients gain a clearer way to assess whether your work is worth paying for.

The market rarely rewards effort alone. It rewards people who can show how their work delivers commercial benefits for their clients. As mentioned earlier, the need to deliver outcomes is even more important than simply providing information in this post-GenAI world.