“Stories” & infrastructure software
"Stories" & infrastructure software
First, "business" explained:
When it all comes down to it, what is a business? You are an organization that has identified a pain point that people are experiencing. In order to remove that pain point, you are offering a product in exchange for money. It sounds so simple.
Second: "stories." I'm always conflicted about marketing-think being too cutsey. You know, the whole "RandoCo. isn't a company that delivers 3D things in 1 to 2 days from point A to point B. No, RandoCo is a company that transfers delight." Or whatever. As I like to say, I want pizza in my pizza box, not a DVD."
But, "stories," sure - let's take a peek.
You need to have good stories about your business and how it fits into people's lives.
Mostly, but I don't know, folks: how about concrete, city CCTV systems, and brake systems for trains? Story telling is needed for anything (even brake systems), but a thing that works at a fair price is also good to have.
For commodity goods - most things regular people buy, as profiled with Coke and over the counter pills - sure: but that's a case where the only real differentiation between products is a story that creates desire, e.g., toothpaste and soda:
What is Coca-Cola’s product really? It’s a lifestyle brand. Look at the adverts and the way Coca-Cola markets itself. It’s extremely rarely about how tasty the products are, but instead about how much fun the people in the adverts are having. They’re adventurous, young, full of life and enjoyment. That is what Coca-Cola is selling. Sure, the company has a huge, global operations and supply chain organization, but the reason that Coca-Cola is so valuable is almost exclusively its storytelling.
If that's your product - high volume, no differentiation, no objective way to say that there's no actual uniqueness or specialness that not only drives a premium price but any price at all - get good at story telling, sponsor Formula 1 cars, hire celebrities to hold watches and look pensive for airport posters, do whatever it takes to trick people into believing your product is worth paying for.
But, if you're selling a solution to a problem - what most software does - tell a story of how it fixes the problem and, then, actually fix the problem.
Arguably, when enterprise software is first starting, you have to focus on story telling, even if it's something as boring as networking or storage.
At the beginning, you won't have the resources to actually build out the full product, yet alone sell it to enough customers to start getting actual feedback about how it works and the product/market fit. (And, then, if you do have enough resources things can easily go poorly as well.)
You have to get those crazy, early adopters who'll co-develop the product with you by using it, rather, putting up with it while you finish it.
Coincidently, this:
If what you write is engaging, it'll start to live. This is a jump-start. If you play it safe and try to write something that looks like a polished product with all the rough edges smoothed off, it risks being dull. No one expects a first draft they can just go out and shoot, and so that's not the job. The job is to provide the initial spark and pour some petrol on it in the hope of the thing catching fire. The ONLY requirement is to be interesting.
Perhaps one of the under appreciated parts of open source is related: people don't expect too much (because it's "free") so they'll help you finish up the first drafts. You still have to get a final draft though, and it should work. I think kubernetes fit this cycle, there's something instructive in OpenStack and PHP, maybe in Apache httpd. And as parallel to closed source, Java and .Net vs. ruby and, I don't know, Perl.
Original Programming
Software Defined Talk #200
Two thrilling topics this week: moderating panels and the mystery of Oracle cloud. Also, some Austin talk.
Pivotal Conversations: s1p recap
Candy corn teeth, or, SpringOne Platform re-cap
With SpringOne Platform over, Danielle Burrow and Bryan Friedman join us to re-cap the conferences, esp. their favorite sessions and some notable fun findings. The news segment also covers Pivotal Application Service 2.7, Azure Spring, and the Pivotal Vanguard program.
Business Bottleneck, part 02
Rick and I presented part two of our Business Bottleneck series, as a webinar. Check out the recording, or the slides for quick flip.
We cover three business/IT misalignments: finance& strategy, compensation, and mistrust (lack of collaboration). In part two, we suggest some ways to address these problems and go over some relevant case studies.
It's been fun working on this concept with Rick, it's helped generate some new ideas and plenty of content, both of them helpful. Here's an excerpt from our own notes on the talk to give you a flavor:
First, finance and strategy. We said that the problem with finance and strategy is that they work on a different cycle, 12 to 18 months instead of monthly, or even weekly. The cycles are arbitrary and not aligned with either the business cycle, or the software and technology lifecycle. The cycles need to line up, or at least not trip over each other.
What you need to do here is convince finance that a smaller cycle is actually more helpful. To do this, IT has to demonstrate that smaller releases are actually possible and that business value is delivered in each cycle: either through actual feature delivery (which drives business value) or learning/failing.
What finance needs to understand is that when they halve, or even divide up their finance cycle into quarters, they're reducing risk by introducing more chances a year to validate their investment theories and stop investing or investment more:
If the project is going poorly, they can reduce funding by shutting it down. This may seem bad, but getting rid of poorly performing IT projects sooner rather than later will save money in the short term, but also years of maintenance money - there are scores of IT projects that should have been canceled long ago but had too much sunk into them.
Investing more is another option. We've been thinking of finance as managing risks, the risk of wasted money. However, there's also the risk of not investing enough: you lose on sales, you slow down innovation when more was needed. You can "spend" money unwisely by not spending enough. With quarterly check points, finance can determine when the market is booming and they invest more.
Case Studies: Allianz's 90 day cycles and Duke Energy takes advantage of IoT.
Post-agile improvement at Discover Financial Services
Here's a talk from SpringOne Platform 2019: Discover's Ying Zhe explains how they company improved after going agile in 2016. Improvements stalled out around 2017, so the company figured out how to get past that plateau. There was a lot of communications overhead and confusion, plus old platforms (a DIY one from the 90s and WebSphere-based one, as I recall) that caused slow down and toil:
People get used to things
From an overview of what "delight" is:
For example, Wi-Fi on a plane would be considered a delighting feature (at least it was when we conducted a Kano study in 2015). Although, as is often the case, delighting features and experiences move into must-haves as soon people habituate and then expect them. We’ll cover whether it pays to delight in a future article.
This comes up a lot in my thinking about "digital transformation." Once you're successful at it, people expect it to be normal. You're no longer rewarded for all the tough work. You could look at ERP systems through this habituation: they used to be magical things, and now they're often a curse.
This might be another thing that creates "legacy" IT: people are habituated to it now and don't see it as a thing of wonder. That's what the innovation bell curve shows, usually under the moniker of crossing the chasm stuff.
Colophon
This thing is combined in my spare time. I use Drafts to collect up links, with some little Siri Shortcuts to format things, mostly the Relevant to your interests section. Now, I'm madly typing this to just get out, right before the get ready to school rush. My son is calling me to come get him out of bed, I'm typing this absurd excuse for any misspellings or weirdness above. Just ship the stuff, don't worry about the last mile.
Relevant to your interests
Not a taco, but mostly considered good food nonetheless. “We have allowed ourselves to be bamboozled by the suspect assertions of articulate people -- and more than a few clowns -- masquerading as experts”. There’s 72 ways to deal with work email. Try not to be deceitful and negligent in UX. "I think WeWork is a great example of thinking that the tech would mask the underlying economics of the business model, and it doesn't," Levie said. "The tech is for the customer experience. It doesn't change your business model". "Barmy."