I’m used to selling private cloud, rack space or data centre services. Public cloud is just another data centre in the sky.
Umm, well, no. This assumption is quite a way off the mark and misses the value propositions of “why public cloud”.
So What is the Value Proposition
I’ve transitioned over time from server design/management through datacenter design/management, and todays era of public cloud design/management. In that time I’ve spent my fair share of time selling the value of server infra design/management and selling both data centre rack space and managed virtual data centres. Today I either spend time augmenting sales people or speaking to customers through existing relationships on the value proposition of public cloud.
While a point of entry into public cloud has often been server migration or data centre evacuation, this is very much a starting point. Servers in public cloud is less than 10% of what public cloud is or can do. It also has the least amount of development investment by the vendors (Microsoft, AWS, Google, etc). Even VMware and Citrix are shifting their investments away from servers.
One of the value propositions of public cloud is to take advantage of colossal services at every day prices (relatively), that are wholly managed (underlying infrastructure) by someone else.
The real value of public cloud services is the ability to innovate for your business without the constraint of servers or the budget of a bluechip company. Today you can build globally scaled applications in minutes that are ultra secure and highly available.
The Emergence of DevOps as a Cloud Standard
We are in the modern era of innovation per app, rather than innovation by platform (utilising containers and serverless rather than a new hypervisor to host your server). These new technologies, the user base that consume them, and the need for agility also need a new methods and ways of working. Enterprise DevOps became mainstream to deliver high quality solutions using innovate technology very quickly.
Why am I mentioning this? If you’re targeting the actual value of public cloud in a sale with a customer then success will be limited unless you or your delivery team examine cloud readiness and the operating model of the team(s) that will consume the services you sell.
Sales Do’s and Don’ts
Guard Rail Number 1 – Arm yourself with knowledge.
Private cloud and datacenter is largely centred around securely managing servers and as already mentioned servers are a minority part of public cloud. Selling the hundreds of public cloud services is very different to private cloud and/or datacenter. The audience of who you’re selling to is also changing (more on that further down).
Do:
- Learn cloud basics as this will make you significantly more effective, and make you more comfortable in your own skin when selling. The more you have to defer to someone else the more difficult the sale will be, particularly in winning confidence. You’re not just selling your company, you’re persuading a customer to do something in tech they aren’t used to doing and that will be very different to what they are used to. Show them you are serious and passionate about it enough to understand the fundamentals:
- AZ-900 Microsoft Azure Fundamentals – aimed at sellers and people with non-technical backgrounds, also covers cloud basics as well as Azure specific basics
- AWS Technical Essentials – as above but more technical
- Google Associate Cloud Engineer – as above but more technical
- Make sure you sell a duck. Understand your company products inside out. Having been on both the giving and receiving end it’s a terrible position when something is sold as a duck, but it turns out to be a polar bear that rides a unicycle while blindfolded across 10 lanes of freeway traffic in 30 seconds or less. Nobody needs that – everyone gets upset, the PMs, the delivery guys, the customer, and then you.
- Be certain there is collateral that will help you in your sale
Don’t:
- Be afraid of asking for tech assistance – it’s not a sign of weakness
Guard Rail 2 – Start with “Why”
I’ve been in several customer meetings and witnessed RFPs now where the leading customer statement is “to be the market leader in the digital workspace for our industry sector”, or something similar.
In Gherkin terms this is a very high level Epic or core business objective.
Some customers have met this with “we need to migrate our server application to cloud as is to gain agility so we can be competative” (the “why” and incidentally the “how”)
Others have met the same objective with “we need to migrate our application to cloud and take advantage of PaaS, containers and/or serverless to give us the agility we need to lead the competition digitally. Servers won’t get us there”.
Either way the customer will gain advantages by moving to public cloud, however moving a server from one place to another gives minimal benefit.
Do:
- Understand the “why” or clear business objectives. These start with highest level in the room (E.G. CTO), then lower level. I like to map each job position in the room to a requirements in gherkin, but it isn’t essential. E.G.
- “As a CTO I need to ensure we have a platform and system that gives us the agility we need to be leader in our sector”
- “As Operations Manager I need to ensure we have a standardised, secure and automated platform”
- “As an application owner I need to ensure my developers can use tools they are familiar with to take advantage of cloud native technology, delivering on the promise of agility”
- Plant the seed. Landing zone ready for colonisation
Don’t:
- Dive into servers, networking, storage, locations, etc because it’s the common ground and a frame of reference.
Guard Rail 3 – Cloud Readiness
Selling cloud isn’t just about selling your fully managed virtual servers, or selling tech. You’re selling a completely new way of working. Fully managed services of the kind common to private cloud are old news. With the accessibility and speed of provision that public cloud brings to the consumer we’re in a world where the customer wants to retain some or complete control after your project is finished. Therefore it is crucial to understand the capability of the customer to make sure they are successful.
Do:
- Ascertain how far along their technical departments are in skilling up
- Investigate their DevOps capability
Don’t:
- Hear they have DevOps and assume they are ready
Guard Rail 4 – Understand Your Audience
The audience is changing. Traditional operations are moving to DevOps, Infrastructure architects are transitioning to cloud technical solution architects and infdevs (app innovation specialists) are emerging. We are spending more time now talking to application owners about their apps than we are to IT managers about their infrastructure.
Do:
- Teach, don’t sell. Customers are often intimidated in the face of an expert company. The “doers” that decision makers rely on for input into their decisions generally fall into two camps, those that are looking forward to learning from the experts, and those that need your company and their peers to see them as knowledgable. Be inclusive in the conversation. Don’t be afraid of course correcting imperfect knowledge, treat it as a education exercise.
- Ensure application owners or an overarching representative is addressed and has input. These guys will be the most nervous about a transition to public cloud
- Ensure you include a security representative in the conversation. Often they are an afterthought that comes to bear part way through a project rather than in the pre-sale.
Don’t:
- Limit the audience to traditional infrastructure people. As a minimum I’d be looking to talk to decision makers in operations, security, architects and app owners/devs.
Guard Rail 5 – Never Make Assumptions
Assumption is the mother of all muck ups, or as my mother used to say, “thought followed a muck cart thinking it was a wedding”.
Do:
- Be certain that what you say is accurate. Doesn’t matter whether it’s about your company, yourself, your colleagues, your services, your capability, technology or what the man down the pub orders from the menu on Fridays. Integrity is everything, not just with your customers but for trust with your colleagues and across teams.
Don’t:
- Guess. If you’re unsure, take the question away, or better still use Teams or S4B to IM someone to see if they can come into your meeting/call to answer the customer question – how awesome would you look being able to get expert advice ad-hoc!
Guard Rail 6 – Trust Your Techies
Public cloud is an incredibly wide and deep ocean of services and capability. Customers will always come up with some bespoke or edge case “must have” that catches you off-guard. These guys are the best friends you can have when selling tech services. They can enthusiastically and passionately provide reassurance to your customers that your company knows what it’s talking about by providing expert advice.
Do:
- Play to your strengths. Tee up your prospects, build rapport, set the scene, then introduce the technical expertise when needed.
- Put your Technical aid at ease. Build a relationship with the relevant teams
- Give maximum info when you need them to aid with a customer.
- Recognise that they may course correct a previous technical misunderstanding with the customer. Don’t worry, it’s part of the reason you engaged them in the first place
Don’t:
- Be afraid of asking for help. Techies aren’t there to make anyone feel stupid. A techy is motivated to teach, enlighten and help.
Guard Rail 7 – Servers are Legacy
If you start out talking about data centre extensions, server migrations, backup, etc then you are subliminally steering your customer down the route of “more servers”. However, start talking core fabric, with security, governance and redundant connectivity as standard as the landing zone ready for colonisation, then you are teeing the customer up for the right mentality to start examining their business drivers for each application with an open mind to innovation.
Do:
- Tee up the conversation. Define a customers starting point as a landing zone ready for workload migration. You don’t have to design and build the whole thing up front and neither does the customer. The purpose of cloud is to be flexible and agile. Choose the right technology, processes and methods that meet customer requirements as the application owners are ready to have those conversations. Get the customer in this mindset.
Don’t:
- Push the customer into deciding on a migration strategy up front. Often for a full migration to the cloud your are talking at least 6 months, more likely over a year. That’s a long time to fix everything in stone up front. Trying to get everyone to agree and sign up to a design up front for everything is both difficult, and unnecessary. Work in increments. Landing zone > 2-3 minor applications > enhanced security > DevOps service > migration by transformation. That way the customer will see progress within the business and be able to adapt to changes in requirements to the business without being locked into a specific all encompassing design/migration plan.
Guard Rail 8 – Hybrid or Multi-Cloud is Likely the Answer
Public cloud isn’t the answer to everything. Larger customers will be multi or hybrid cloud for a long time as they upgrade, innovate, transform. Hybrid is a viable solution in the mid-term to ensure the right migration decisions are made.
Do:
- Encourage your customers to analyse migrations per application, rather than a single migration strategy encompassing all workloads. This will take time so it’s OK to have a hybrid strategy.
- Keep your services close to your users. This is a mantra for virtual desktop specialists but the analogy applies to public cloud. If a customers has applications used by staff that are sensitive to latency then it makes sense to keep those apps close to their user base. Yes there are low latency, high bandwidth connectivity solutions to ease that, but not all customer scenario’s can support them, and not all apps support the “work from anywhere” philosophy.
Don’t:
- DC evacuation is a bad reason to move to public cloud. It stunts innovation and often ties customers into a specific kind of strategy that forces them to migrate twice. Once to public cloud, and again to innovative services such as S3 buckets or Azure Files. Once the customer has rushed to evacuate their DC they have spent a lot of money doing it, they are going to be disinclined to then charge down a route of innovation. Encourage your customers to start small, live with hybrid and put each app under the lense for a per app migration strategy.
Guard Rail 9 – Never Help a Customer Determine Which Public Cloud Vendor to Use by Comparison
This is the fastest way to damage your extremely valuable partner relationships with these vendors. They definitely do not like or want you to get involved in comparison/competition conversations with your customers. Always politely decline this request. The sale is not worth it.
The Automation Guy 