An offering describes the parameters in which a service is packaged and delivered to provide enough clarity to buyers, while leaving room for tailoring the service to the customer’s environment and needs.

Development agencies, system integrators, ISVs, security consultants, and other professional services providers often subscribe to a ‘we can do anything’ approach. Within that vendor’s specialty, it could be a fair statement. By definition, a developer can develop anything. However, that’s a poor sales strategy, where prospects need to invest a lot more time and energy in initial engagements without being able to truly understand a vendor’s specialty or service capabilities. 

This is a common pitfall and can be found manifesting itself in many places. For example: What’s your total addressable market? The whole world.

Most vendors’ sales and marketing collateral lack the specifics which help prospects prequalify vendors, with the level of detail staying at an ‘application development’ or ‘improve security posture’ level. Common solutions to this problem include niching down. Let’s say you would only target highly regulated industries and get all the compliance and certification in place. Or, you specialize in AWS services. Another common solution is productizing services to define off-the-shelf solutions at fixed prices with fixed deliverables.

A more suitable and strategic technique is to define offerings, which provide a way of clearly articulating what you offer to get qualified leads, have clear customer conversations and differentiate yourself, target the right customers, develop a content strategy, and build authority in the space.

In this guide, we will describe how to define an offering, best practices for writing, and we will also assess publicly available offerings from notable professional IT service providers.

Let Me Make You an Offer

Imagine being in a conversation with a prospect, and you hear one of the following statements:

• My services are latency-sensitive, so I’m looking to replatform my application to be used at the edge.
• I’m looking to deploy a proprietary machine learning technology, but I don’t have enough confidence it will behave as anticipated in production.
• I want to enable end-users to consume our services using Natural Language Processing, but the system needs to handle communications securely.

What would be your response? Generally – and this is good practice – is to diagnose the problem by asking clarifying questions. Once that’s done, we make notes of what’s needed and put a proposal together to be sent later.

Now, how would an offering look?

• To replatform applications at the edge, we have partnerships with providers that have edge compute capabilities. We select the provider following an assessment of your environment that will help us determine whether the application just needs to be lifted and shifted to operate on a VM or container at the edge, or whether it would be better rearchitected to microservices. For both options, we can use a tool such as New Relic or Datadog for observability and alerting.
• We have a framework for creating an MLOps pipeline, which also includes a human-in-the-loop system for real-world deployments that automatically shifts the decision-making process from the ML to a human when the confidence score falls below a predetermined threshold.
• Our solution for delivering services via NLP includes the integration of a large language model such as ChatGPT, and we use an API security tool such as Traceable to ensure secure communication between ChatGPT and first- or third-party APIs or databases.

What are we trying to communicate here:

• We’ve seen your problems before, and we know how to address them
• The service is already defined and available as soon as a statement of work is signed
• You have full visibility into how the service is delivered, the output, and the benefits
• Here’s our solution brief that explains everything

For all of the above, notice the level of flexibility. We are not locked in to a vendor, tool, programming language, or such. Enterprises may already have these tools in place. We are offloading their mental workload and denoting that we have the right expertise.

This is a balancing game, and the key here is understanding what enterprises need and want. 

Selling to Enterprises

There’s a fantastic article by Brian Chambers, enterprise architect at Chick-fil-A, on what he and his peers look for once purchasing a tool or service. Some of the points relevant to this context include:

• We often plan really far in advance – be mindful of your clients’ financial planning and budgeting, which can be allocated as much as a year and a half in advance.  Even decision-makers have their hands tied by the allocated budgets and timeframes. In this sort of scenario, an offering can help provide not only a good indicative price for an engagement, but also lowers the time and effort to scope work. Quite often, IT departments are conservative with spending throughout the year, only to realize that they have a lot of budget left in Q4 and looking for avenues to spend the remaining budget so it would be reallocated in the next fiscal year. 
• We like POCs / we are slow at POCs – for professional services, a proof-of-concept is a reduced scope solution whose performance can be monitored and reported on. For example, a large website optimization project can be narrowed down to a single-page optimization project, which can be measured in terms of page load time, LCP, and the like.
• We like finding products vs having them pushed on us – reimagining this point to services, a content catalog that covers specific use cases can build authority for specific use cases. Blog posts are actually a fantastic channel to promote solutions to specific challenges or use cases. We discuss more about writing blog posts later in this guide.

Here are a few more points on selling to enterprises:

• Predictability and consistency – by having a pre-defined and documented set of deliverables, IT buyers have an easier time understanding the engagement and outcome. Enterprises can more easily conduct impact assessments, produce business cases or proofs of concept, get approvals from management and finance, and select vendors that can demonstrate they tick boxes earlier in the engagement.
• Ability to deliver on an existing strategy – business cases are produced far in advance and get multiple stakeholder sign-offs. Once these are approved and budgets are allocated, the project managers need to deliver on the details agreed upon by the wider business. With respect to the way we defined an offering (i.e. service packaged and delivered to provide enough clarity to buyers, while leaving room for tailoring the service), an offering can indicate to buyers that the services are a good match for their existing strategy, without locking in to any technology or vendor.
• Governance and reporting – must-haves for enterprise engagements include governance and reporting capabilities, which are typically delivered through dedicated account and project managers, regular progress reports, and demonstrating abilities to deliver services in compliance with HIPAA, PCI-DSS, or other standards applicable to regulated industries.
• Testing and validation – following the design and implementation of a project, enterprises have a requirement to understand the performance and reliability of the new service before it gets deployed in production. Tests that can be conducted include user acceptance testing (UAT), penetration testing, performance benchmarks, unit testing, integration testing, and system testing.

Framework for Writing a Compelling Offering

A well-defined offering covers service aspects such as definition, title formulation, description and use cases, challenges addressed, methodology, and the expected deliverables and outcomes. This framework is not categorical. It can help define the information that should be present, but the structure or flow of an offering needs to make sense depending on how the offering is documented (i.e. website copy or solution brief), and the service itself.

Service Definition

The first step in writing a compelling offering is defining what the service is. These can take one of the following forms: 

1. Consultancy, advisory, strategy – done with you. Output is a written artifact or a presentation.
2. Professional – done for you, once. Output is a digital product, environment configuration, or service improvement.
3. Managed – done for you, continuously. Output is the outsourcing of an IT function to a third-party provider.

Alternatively, the above list can also be presented as design, build, and run.

Following that, we need to define the scope of the service.  As such, we need to determine the following:

1. Core activity – development, design, system integration, assessment, technical support
2. Output – website development, compliance audit, mobile application, enterprise resource planning configuration, security operations center, network design, security policy definition
3. Target market or industry – local government, national government, eCommerce, telecommunications, multinational corporation, healthcare or financial services provider.  
4. Tooling or technology – public cloud, VMware, headless CMS, workflow automation, distributed databases.
5. Use cases – real-time website analytics, global content delivery, auditing and compliance, cost optimization, product development, 

 Note: The wider the scope, the lower the resolution.

How to Write Service Definitions

In formal logic, there are eight rules for writing a definition. These are a surefire way to consistently compose them clearly and concisely. The definition must be:

1. Encompassing – the definition must be both exhaustive and exclusive. This means that the definition must not be too wide – to include aspects that are not in scope; or too narrow – to exclude aspects that are in scope.
   • Serverless computing allows developers to consume resources on a pay-as-you-go basis. Too narrow – there is more to serverless than just the pricing model.
   • Serverless computing is a model of outsourcing infrastructure. Too wide – there are other models of outsourcing infrastructure.
2. Essential – The definition must express the essential points of the term you are defining.
   • Network Function Virtualization allows for easier management of networking resources. While it is true, this definition misses the point of NFV, namely that it abstracts the capabilities of a physical appliance into a virtual construct.
3. Not circular – A definition must not contain the term that is being defined.
   • The Internet of Things connects everyday things to the Internet.
4. Replaceable – The defined term must be able to be replaced with its definition. This is a great test to see whether the definition holds up.
   • Multi-factor Authentication (MFA) is a credential verification method that requires the provisioning of two or more verification mechanisms to gain access to an IT resource.
   • I always need to go through MFA when I log in.
   • I always need to go through the authentication method that requires the provisioning of two or more verification mechanisms to gain access to an IT resource when I log in.
5. Positive – You must say what a term is rather than what it isn’t.
   • Autonomous vehicles are not driven by humans.
6. Industry-specific – The definition must be written in the context of the industry. For example, access controls for buildings is different from access controls for IT resources.
7. Clear – The definition must not contain figures of speech, metaphors, or ambiguities.
   • DevOps is every developer’s dream.
8. Objective – The definition should not contain marketing speak, epithets, or hyperbolae.
   • Intent-based networking is a world-leading solution that can instantaneously provision fully optimized networking configurations for break-neck speeds.

Applying the Eight Rules

For a real-world example of seeing these eight rules applied to define a new category, we will look at Andrew Green’s definition from the GigaOm Report on Edge Platforms:

Edge Platforms leverage globally distributed infrastructure to deliver content, computing, and security closer to end devices, lowering latencies, offloading networks, and improving service performance.

• Encompassing – it describes at a high level the whole Edge Platforms space, which includes content, compute, and security.
• Essential – it notes the focus on geographically distributed infrastructure
• Not circular – the words ‘edge’ or ‘platform’ are not found within the definition
• Replaceable – It can be used within a sentence to replace the term ‘edge platform’ (it wouldn’t be feasible to do so, but the point is to see if the definition holds up)
• Positive – all statements are positive
• Industry-specific – it is specific in the cloud and networking space of enterprise IT
• Clear – every term used has well-defined meanings
• Objective – the definition does not contain overinflating terms

To walk the walk, here is the definition of what an ‘offering’ is from the beginning of the book.

An offering describes the parameters in which a service is packaged and delivered, enabling prospects to pre-qualify a service, while leaving space for tailoring the service to the customer’s environment and needs.

Title Formulation

The title of the offering must be a clear representation of the service. Generally speaking, it must include at least the target and action.

Challenges

Write challenges such that they imply your solution. The opening line is precious real estate, so packing both the pain point and solution in a single line will make sure you won’t end up with:

“In a post-Covid world, cybersecurity is of paramount importance.”

The above is a real-world example from a reputable vendor.

Let’s look at an example of an unclear opening paragraph that highlights the challenges:

• Organizations have been monitoring applications for almost as long as they built those applications. However, with the adoption of microservices and distributed systems architectures, this space has become much more complex.

Rewriting it to imply the solution, we produce the following:

• While Kubernetes makes managing a containerized infrastructure much easier by creating levels of abstractions such as pods and services, it also requires monitoring for distributed applications, the containers running them, and Kubernetes itself.

Here are some more examples of well-written challenges:

• Early approaches to cloud adoption focused on infrastructure and application migration, with very little attention to the underlying code.

• • • Implies an Application Modernization service (see section on Rackspace’s offering below)

• Federal government agencies have a higher threat profile than many of their commercial counterparts, coupled with institutional constraints in acquiring, hiring, and implementing the critical resources needed to fully protect their agency.

• • Implies a Managed Security Service for Federal Government (see Accenture’s MSS for Federal Government below)

So how do you do that? Here is a framework you can use:

• [Something is good, or better than before] but [has these limitations that must be addressed].
• [Something is difficult] because [of specific industry or technology requirements]
• [People usually do this] but [they don’t pay attention to this]

Service Features 

These are the functional aspects of an offering that describe how the end result of a service is achieved. While the service definition describes what it is and what it does, the feature provides additional capabilities that enhance the core activity of the service. To understand how to identify a service’s features, let’s look at the following two examples.

Highlighting the Methodology

Most professional services have a similar methodology, which takes a high-level form of:

1. Discovery or assessment
2. Design or planning
3. Development or implementation
4. Testing or validation
5. Production deployment
6. Monitoring and iteration

The key here is not the methodology itself, but the low-level details for how each is carried out. For example, the methodology for a web performance optimization service can say something along the lines of:

• Discovery or Assessment – We understand your environment using a pre-defined checklist of 42 line items covering relevant entities and common misconfiguration.

• Design or Planning – Upon completing the assessment, we create a high-level design draft and present it to the project’s leadership team for approval. Following the approval, we produce a low-level design and validate it with stakeholders from the business units impacted by the change.

• Development or Implementation – The changes are implemented following an Agile method. All changes are tracked in Jira as a project management software. Each deliverable provides visibility in the development process and adequate sign-off procedures.

• Testing or Validation – the solution is stress-tested in a sandbox environment and performance is monitored using a third-party tool such as Catchpoint to test between the old and new page

• Production Deployment – We implement roll-back mechanisms to revert to a previous state in the scenarios where the service does not perform as expected.

• Monitoring and Iteration – We deploy and configure observability tools such as Datadog and New Relic to track performance. 

Deliverables and Outcomes

Outline the main deliverables or outcomes the client can expect from your service. The outputs can take one of the following forms:

• Written artifact – vulnerabilities assessment report, audit result, quality assurance, and user acceptance testing report.
• Digital product – website, mobile application, SaaS solution, web services, data analytics solution
• Service deployment, configuration, and optimization – high availability and disaster recovery, firewall deployment, CDN configuration, ERP configuration, zero-trust implementation, and network segmentation.
• Service improvement – application security, website performance optimization, API integrations. 
• SLA-based services – technical support services, managed network operations center, managed security operations center, managed infrastructure services.

Here is an excerpt from one of Palo Alto Network’s Deployment Services for Prisma Access:

Assessing Real-World Offerings

Let’s look at three examples of Application Modernization services from notable vendors in the industry and see what they do right and what can be improved.

Note – we are not evaluating the vendors’ capabilities, but rather the way the services are communicated in these publicly available assets.

Also note – large and reputable vendors are able to get away with unclear offerings, only due to the wide reach, existing customers, word-of-mouth, and large marketing budgets.