Tech the Heck? - CloudTruth
This is the weirdest email you will get today
TL;DR: Welcome to a bizarre series called Tech the Heck, in which I try to explain in plain language what a particular tech startup’s product does - despite it being non-obvious on their own product page.
Look, most of the new technologies we deal with as software engineers are conceptually not that complex. We’re just not very good at explaining them, either to non-techies or to each other.
Sure, we all like to think we’re above using marketing buzzwords: “leverage transformative innovation”, “supercharge ROI by driving accelerated adoption”, etc. But man, do we ever have a problem with technical jargon.
When I land on some developer-tooling startup’s product page, I find myself glazing over at words like “Programmatically provision customer-representative environments, for comprehensive cross-distro testing that prevents customer issues”. (That’s real copy, name withheld to protect the guilty.) That description paints NO picture in my mind’s eye. I can read it five times and it just drains out of my brain like water through a sieve.
The obtuse way we talk about technology has a couple of bad effects: it makes us feel dumb, and it helps vendors foist expensive crap onto us before we realize what we’ve gotten ourselves into.
“Tech the Heck?” is a new series I’m trying that explains WHY a software product exists and WHAT problem it is trying to solve, in as plain English as I can come up with. Think of it not as the missing manual, but as the missing confessional. Also, there will be cartoons.
Huge round of applause to consulting client CloudTruth, who were incredibly good sports to let me share today’s notes publicly. Seriously, this is VERY cool of them. I wouldn’t be doing this if they hadn’t given the okay, and I also wouldn’t be doing it unless I thought their product was legitimately useful - and deserves to be better explained.
Tech the heck? - CloudTruth
Selling professional developer tools is really hard. People think this is because developers don’t like to pay for things. And they don’t, but that doesn’t really matter, because in a business context the developers aren’t usually the ones buying the things.
The real problem is a mismatch in values. Developer tools are usually built by developers who care a LOT about doing software engineering The Right Way. They care about good abstractions and clean code and hygienic ops. They care about writing fast, maintainable apps. They might even have left their old day job because they were so frustrated by the slow, out-of-date practices and DIY tooling. They believe they can build a better path. And they assume that the better path ought to be worth money, because what’s more valuable than happy, productive developers?
This is why so many technical founders market their tools with phrases like “easy to use / better abstractions / less toil”: because those are the things they themselves value. If you want to get developers to adopt an open-source product, definitely talk about the great abstractions and ease of use.
But if you want engineering directors to pay for a tool, you’re probably gonna have to do better than that. It is 2024. Nobody has budget and everybody is laying people off. Nice-to-haves are not need-to-haves. When you, a developer, ask your boss to buy a product that will help you design more aesthetically-pleasing build pipelines, the boss is hearing “Can we spend money on a more fun way to do non-revenue-generating tasks?”
This is where CloudTruth comes in. They asked me to take a look at their homepage and see if I could think of any ways to explain their product better. When I first landed on it, the main hero copy looked something like this. (They’re A/B testing some new things now, so you might see something different when you click):
OK, based on just that information, what problem would you guess that CloudTruth is trying to solve?
They’re apparently selling something that’s supposed to help with “config”. When I hear “config”, I think “YAML templates.” Or maybe it’s some kind of infrastructure-as-software product that helps you manage config with code? Maybe it’s a configuration management database (CMDB) for tracking IT assets! I don’t know, and context clues aren’t helping. It definitely FEELS like I should know what they’re referring to, though, so I catch myself nodding along.
The next thing on the page is a demo video. We could do a whole essay about making a great demo video, but just note that the very first thing you see in that video is a slide called “The need for ConfigOps in modern SDLCs.”
Hang on. I already don’t know what they mean by “config”. Now we’re talking about ConfigOps. What is ConfigOps? It’s a term CloudTruth is trying on for size to encompass what they do, but it creates no picture in my mind. I’m pretty sure I have both config and ops in my SDLC already. Maybe I don’t need this product, whatever it is.
Here’s where I pause again to clarify that I am not dunking on CloudTruth. I think they have built something interesting and it probably even speaks well of them that so far they have put 99% of their energy into building it, rather than tweaking copy on their landing page. But what the heck is it?
Simply put: CloudTruth is a single pane of glass for configuration data. Configuration data is secrets, environment variables, and other parameters—the stuff you inject into your app at deploy time to make it work.
Yes, there are tools that manage certain types of config data today. Hashicorp has Vault. AWS has Secrets Manager and SSM Parameter Store (or whatever they’re called these days; I’m not looking it up). The Linux Foundation has a vaguely terrifying open-source thing called External Secrets Operator that sucks all your config data into Kubernetes. Some of us are unfortunate enough to have used Secret Server.
These tools tend to be best at one thing (eg, secrets handling), or are provider-native; most require a good bit of manual spackle, and keeping track of different versions of parameters as they change over time tends to be an unfriendly adventure.
CloudTruth’s founding insight, as with so many developer-tool founders before them, is that this situation sucks! There should be an easy way to version and push out config data across lots of different teams and cloud environments. There should be a great set of abstractions for wrangling the data, and that should reduce ops toil as you … aaaand you see where this is going.
Easy, great abstractions, reduced toil. The rogues’ gallery of Nice-to-Haves. If those really were CloudTruth’s primary selling points (and when I looked at their marketing site I kept seeing “easy and fast” pop out like a scary clown), I would not be writing this post because I would not believe in CloudTruth’s potential and I would not be defending them in this weird backhanded who-needs-enemies-with-friends-like-these kind of way.
But there is another way to look at CloudTruth, and that view is: oh crap, this is not a devtools startup, this is a data startup. And then it suddenly becomes very interesting.
Look, let’s be brutally honest: platform / DevOps / SRE / whatever teams generally don’t excel at managing data. This is why the DBAs are always refusing to let them get their slimy hands on the production databases.
The most mission-critical data that platform teams usually get to touch is probably configuration data: the Kubernetes ConfigMaps, the VPC layouts. Because it’s “just config”, we’re often pretty casual about handling it, and that is a massive misperception of risk. It just so happens that mistakes in handling config data are the culprit of something like 80% of all production outages. The more apps and teams and cloud environments you juggle, the more likely you will push a dev parameter to prod, or ship an environment variable that really should have been a secret just because your secret manager is way over there. (I’ve seen what you all do with your OpenAI API keys.)
Building a prettier dashboard for your config data is a Nice-to-Have. Building a thing that lets you responsibly manage, audit, secure, and version the kind of data that is statistically more likely to take your apps offline than anything else—THAT seems like it could be a Need-To-Have.
If I’m trying to convince the head of my platform engineering team to use CloudTruth, I’m not talking about how easy it is to use. I’m talking about the fact that it might be the only product on the market that has a coherent plan for taking care of the most mission-critical data our team is allowed to touch. Config data is load-bearing, and it might be smart to share the load.
The CloudTruth homepage has a bunch of possibly-hypothetical “things our customers used to say” near the top of the page. I don’t find hypothetical testimonials compelling and I suggested they get rid of them entirely. What I do find compelling is the list of REAL “things our customers say now” with logos waayyy down near the bottom of the page, which boil down to “uh, holy crap, we really were not taking config data seriously enough before CloudTruth came along.” I would move those testimonials way up.
The last thing I want to call out is this “how CloudTruth works” section near the middle of the homepage:
The copy is … a lot of words. It uses bolded jargon terms like configuration artifacts and platform components that I am not totally sure I define the way CloudTruth does. I feel like I would grok what they are telling me much quicker if I could see it in a diagram. Fortunately the right side of the screen is taken up with … oh. Oh no.
I call this style of graphic “Developer Impressionism”. It’s a dreadful genre that pops up in so many product announcement videos and investor slide decks. It looks sort of like an architecture diagram, but it conveys no information. Nothing is labeled. It is essentially abstract art, meant to invoke the feeling of an architecture diagram.
Your target audience is scrolling this page with two minutes and half a brain cell to spare before diving back into a quarterly roadmap meeting. If you are going to take up screen real estate with a diagram, make it a real architecture diagram. I would like to see a napkin sketch that that shows how CloudTruth actually fits in my deployment process:
Okay, I know that’s crude. But it contains exactly the same information as the original wall of text, with the crucial distinction that I can follow at a glance what CloudTruth’s role in my CI/CD process is supposed to be.
My overall recommendation to CloudTruth was to focus on their killer value prop: they are stewards of mission-critical data. That means getting really precise with language.
CloudTruth is testing some new landing page ideas. When I last checked that main hero copy, it looked like this:
Gone is the oblique reference to “config.” They are now calling themselves “The Configuration Data Platform.” That already creates a better picture in my mind, but in case it doesn’t, we have context clues above and below: variables, secrets, and parameters. The word “easy” does still appear in the sub-head, but crucially, the thing they are making easy is an important thing: accurate config data.
Maybe you think a configuration data platform is a Need-to-Have, maybe you don’t. But at least now, you’ll be having a real conversation about it, not just saying: “Tech the Heck?”
Thanks again to CloudTruth for giving me permission to share these reflections based on my work with them. If you would like me to walk through your product page with you, I’ve opened up a few 60-minute meeting slots.