Capabilities: the missing link in your service offering

Many organisations know how to create a service offer. They identify a market need, define the value proposition, describe the scope and create a presentation for clients. Sometimes they also add a delivery approach, a pricing model and a few case studies. This is useful work. It gives sales teams a clear story and helps start client conversations. But it does not automatically mean that the organisation is ready to deliver the service.

I learned this while working on cloud migration. What started as the creation of a service offer became something much bigger: building the capability behind the offer, from the commercial proposition to the people who could deliver it.

The main question changed from: "Can we sell cloud migration?" to: "Can we deliver cloud migration repeatedly, with different teams and client environments, while keeping a predictable level of quality?" - that second question changes the entire approach.

A standard service offer normally includes:

• the client problem

• the target market

• the value proposition

• the scope and expected outcomes

• a high-level delivery approach

• assumptions and dependencies

• commercial and pricing information

• case studies and references

• sales presentations and proposal content

These elements are needed. The problem appears when the work stops here. A good presentation can explain what the organisation wants to sell. It cannot prove that the organisation has the methods, people, knowledge and controls required to deliver it consistently.

From service offer to delivery capability

For cloud migration, we needed to connect the commercial promise with delivery reality. Cloud migration is not only about moving workloads from one environment to another. A real migration can involve application and infrastructure discovery, migration assessments, landing zones, networking, identity, security, data, migration waves, testing, cutover, operational handover, FinOps and post-migration optimisation.

Each area requires clear decisions, specialised knowledge and coordination between roles. This is why the work expanded beyond the service definition. We built a migration framework that described how the service should be delivered from discovery to transition and optimisation. We defined the main phases, expected activities, delivery artefacts, decision points and quality gates. This gave teams a common structure while still allowing them to adapt to each client context.

The next step was to identify what the organisation needed in order to run this framework in practice. We mapped the roles involved, including cloud architects, migration leads, platform and DevOps engineers, security specialists, data and database specialists, FinOps expertise, project management and delivery leadership. For these roles, we looked at the required skills, knowledge areas, experience levels and certifications. This made the gaps visible. It also gave us a practical basis for recruitment, training, certification planning and team formation.

Certifications were not treated only as badges for marketing. They became part of the readiness model. They supported technical credibility, partner requirements and audits, but they also helped us understand whether we had enough qualified people in the right areas. We also connected project evidence to the capability. Case studies were useful for sales, but delivery evidence had a wider purpose. It showed which types of migrations we had completed, what outcomes we achieved, where the framework worked and what needed to be improved.

Building the full system

Once I started to see the service as a capability, several connected layers became clear:

1. Market need: What client problem are we solving, and for which type of organisation?

2. Commercial offer: What outcomes, scope and value are we promising?

3. Delivery framework: How will teams deliver the service from start to finish?

4. People model: Which roles, skills, knowledge and experience are required?

5. Readiness model: Which certifications, partner requirements and evidence must be in place?

6. Reusable assets: Which assessments, templates, tools, playbooks and accelerators reduce delivery effort and risk?

7. Governance: Who owns the capability, controls quality and approves changes?

8. Improvement loop: How do lessons from delivery update the framework, training and commercial offer?

All these layers need to support each other. For example, there is little value in promising a complex migration approach if the organisation does not have the required security or platform skills. In the same way, there is little value in training people without connecting that investment to a clear service, delivery demand and project pipeline. The capability model creates this connection.

What was different about this approach

The work did not move in a straight line from strategy to a finished document. It moved across commercial, technical, people and operational topics. The service offer influenced the migration framework. The framework exposed the required roles and skills. The skills analysis shaped the training and certification plan. Partner requirements influenced the evidence we needed. The delivery experience then gave feedback into the framework and the offer.

This created a system, not a collection of separate activities. It also reduced dependency on a small number of experts. Their experience could be converted into shared methods, templates and decision points. New teams had a clearer starting point, and experienced teams could focus more on client-specific complexity.

The goal was not to remove professional judgement. Cloud migrations are too dependent on context for that. The goal was to give professional judgement a consistent structure.

What I gained personally

Building the capability end-to-end also changed how I look at service development.

First, it strengthened my ability to connect strategy with execution. I was not only involved in an attractive proposition. I needed to understand what had to exist inside the organisation for that proposition to be credible.

Second, it gave me a broader view across sales, architecture, delivery, people development, certifications, partnerships and governance. These areas are often managed separately, but a scalable service depends on all of them.

Third, it improved the quality of my conversations with leaders, clients and delivery teams. I could discuss not only what the service offered, but how it would be delivered, what risks had to be controlled, where capability gaps existed and what investment was required.

Finally, it gave me a reusable way of thinking. The same model can be applied to other services, including cloud modernisation, data platforms, AI adoption, cybersecurity or managed services.

At the end

A service offer can create interest. A delivery capability can create revenue, quality, trust and scale. For organisations building new technology services, the work should not finish when the sales material is ready. That is only one part of the job.

The real work is to connect the market need, commercial promise, delivery framework, people, skills, certifications, reusable assets, evidence and governance into one working system. This is the difference between describing a service and being ready to deliver it.