The boring maturity model, and, pricing higher
The boring parts of a platform
Container people are playing with a “make it boring” maturity model. They’ve tinker away at containers for years and now want to standardize on kubernetes and whatnot, ending all the jockeying and invention in the space. E’ryone is kubernetes krazy!
As I theorized yesterday, feisty developers will always be interested in the internals of containerized platforms: they can’t help themselves. Maybe we get upset when they shade tree mechanic a cluster and end up with a few spare parts when they rebuild it, but someone has to make all those “well actually” comments on Hackernews.
The part that developers will find tedious and boring is all the operations stuff and governance. Traditionally (and likely into the future as SRE think re-enshrines the division between developers and operators), developers haven’t cared about this stuff: except maybe wrestling with a nagios.
In the future K8s will exist as an infrastructure API almost universally. VMware has introduced project Pacific. Now you have a consistent way to provision resources and infrastructure and do health management and updates and scheduling. So the landscape from an operational complexity goes way down,” said [Pivotal’s Ian] Andrews.
These are the reliably “boring” things. It’s probably a good idea for the PaaS community to expose and talk about the inner container and orchestration inner workings of all this, but in a safe, kind of museum way: like those interactive exhibits about gravity and stuff. Let developers tinker around just long enough to understand how it all works and, then, as they do, automate it all away (shifting their usage to more a PaaS model). For example, let them write scripts at first, and then when the get bored, offer the PaaS-y stuff:
“If you look at the state of the art today, there is no human building little command scripts that says, ‘When the container fails, respawn another container on a different host’. It’s built into the system. The human interface is now a declarative statement that says: ‘When this application runs, I want three containers of this type always deployed on the same host.’“
What developers will be interests in here is not the actual script that does restarts reliably and follows enterprise policy, but arguing about the actual heuristics and schemes for doing restarts: they’ll be fascinated by the ongoing theory, scribbled out on white boards and taking up hours of discussion over lunch (I mean, it’d be sort of better if they took a 60 minute lunch door-to-door and spent all that extra time coding, but, hey, I get it). But the actual “script,” not more than one or two times.
But, all that “day two” stuff, they won’t care too much: identity management is guaranteed to be boring out of the gates, probably even enterprise registry management.
Anyhow. The theoretic advice being, keep the thin layer of kubernetes exciting, focus on making all the other stuff boring.
(And, hey, if some developer persistently likes all this boring stuff, you’ve found yourself a new SRE and won’t have to spend all that time and money hiring one on the open, expensive market.)
Cheap stuff isn’t worth buying
Pricing is a weird, mystical craft. You can science it by experimenting and trialing what “the market” will pay, but that’s just feedback on your own strategic magic-making. I like pricing theory a lot because it’s an ever evolving, complex system that’s completely open ended. That is, you never run out of novel things to talk about.
For example, my old D&D friend (2nd edition forever!) Jason explains why focusing on cost savings is, like, small potatoes:
It’s always 10x more valuable for a business to grow faster than it is for the business to save money.
This insight points us to an alternate pitch for [his example app] DoubleDown. It’s not about spending less for the same amount of growth, it’s about spending more to create more growth.
Using this app example (the app helps get more customer/leads/etc. through AdWords):
The customer is willing to spend $40,000 to generate 200 leads, and therefore is happy to spend $80,000 to generate 400 leads. It doesn’t matter how much of that $80,000 is going to AdWords versus going to DoubleDown. The key is not to “save money on AdWords,” but rather to “generate more growth at a similar unit cost.”
In the “saves money” pitch, the value was $20,000, and the customer needed to keep 75% of that value-creation [which drives you to price the app lower, cheaper]. Whereas in the “generate growth” pitch, the value is $40,000, and the customer is happy to pay 100% of that value-creation to a vendor. Both the amount of value created, and the percentage of value the customer is willing to pay, is a multiple higher for the “growth” pitch versus the “save money” pitch.
So, then you can charge a lot more than a cheap price.
This approach also changes your sales pitch, the whole sales strategy really. You want to talk with people who are focused on growing the business, not eking out cost savings by running IT more efficiently. Sure, your app is more efficient, but you don’t lead with that or, really, ever want to talk about that.
That’s not exactly universal…if you can cut costs at massive scale, saving millions of dollars, that’s a fine pitch: exhibit number one, there, VMware. Even then, though, you want to be involved in the next discussion: “thanks for saving me millions of Euros…now can you come in and white-board with me what we’ll do with all that extra cash and time?”
You know, like, maybe start writing more software to change your business model, add new types of businesses, and grow more? Just sayin’.
Pricing! So much fun!
(Ooo, ooo! And the doing company valuation, esp. for funding rounds and IPO’s, but also for M&A - an even more esoteric form of pricing spell-craft.)
Relevant to your interests
“Our 2020 strategy is to broaden the definition of our platform.” Each bank has billions to spend on running existing IT and building up new stuff. “They had this great platform, but nobody had talked to the commercial team”.