Hypotheses for cloud services
How to write a misery hypothesis when you sell cloud services. Where to look, the four guesses that tend to land and an example opener.
· 3 min read
Nobody wakes up wanting to buy cloud services. They wake up to a bill that's bigger than last month, a migration that's a year late or a data center lease that ends next spring.
Your hypothesis should start there. With the problem, not the platform.
Why cloud pitches sound the same
Cloud services firms all list the same partnerships, the same certifications and the same migration methodology. To a buyer, they're interchangeable. So the buyer picks on price or on whoever they already know.
You break out of that by showing you understand where this company is stuck. That takes research. And the good news is that cloud problems leave a trail.
Where the trail is
Job posts are the richest source. A company hiring cloud platform engineers, site reliability engineers or a FinOps analyst is telling you what it's struggling with. A posting that names a specific cloud provider and a specific legacy system in the same description tells you the migration is underway and probably understaffed.
Filings come next. Look in the 10-K for language about legacy systems, data center consolidation, technology costs or a multi-year modernization program. If the CFO mentions cloud costs on an earnings call, that's pressure with a name attached.
Then the people. A new CIO or VP of infrastructure is often brought in to finish what the last one started. Watch what infrastructure leaders post. Someone writing about cost visibility or tagging discipline is living inside a cost problem.
Run it as 3x3 research. Public record, social context, market. Three facts from each, at most. Then write.
Four hypotheses that tend to land
The cost surprise. They moved to the cloud expecting savings, and the bill went the other way. Your guess is that nobody owns cost by team, so nobody changes behavior.
The stalled middle. The easy workloads moved in year one. The hard ones are still on premises, tangled with systems nobody wants to touch. Your guess is that the migration plan didn't account for the dependencies.
The deadline. A data center lease or a hardware support contract ends on a fixed date. Your guess is that the schedule is tighter than the team can deliver.
The skills gap. They're hiring cloud engineers and not filling the seats. Your guess is that the roadmap assumes people who aren't there.
Pick one per message. If the research supports two, save the second for your follow-up. The second message is a new hypothesis covers why.
An example
Say a regional healthcare network's 10-K mentions consolidating two data centers by the end of next year. It's posting for four cloud engineers, and a new VP of infrastructure started in the last two months.
You joined as VP of infrastructure a couple of months ago, and the 10-K commits to closing two data centers by the end of next year. That's a deadline you inherited, not one you set. With four cloud engineering roles still open, my guess is the hardest workloads haven't moved yet and the team is behind on the plan. Is that accurate, or is the real pressure somewhere else?
Research hook, personal trigger, misery hypothesis, binary exit. No list of your partner badges.
If he writes back that the team is fine and the real issue is the clinical systems vendor, you've just found the actual problem. That correction is worth more than any discovery call. There's more on that move in hypotheses for modernization services.
Who else to write to
The infrastructure VP is the economic buyer or close to it. But cloud decisions touch finance and security too.
The champion might be a cloud platform manager whose team is buried. Write to them about the workload and the hiring gap. The technical lead might be an enterprise architect who'll decide the target state. Write to them about the dependencies. If cost is the hypothesis, the finance partner who sees the bill each month cares as much as anyone.
Same research. Different trigger for each seat.
What to leave out
Leave out the provider logos. Leave out the migration buzzwords. Leave out any claim about how much you'll save them, since you don't know yet.
Find the deadline, the bill or the stuck workload. Guess at what's behind it. Let them tell you where you're wrong.