Never has a phrase been so misunderstood.
At one level, software can be thought of as just software, delivered securely, that is easy to use, that solves customers’ problems.
In these terms, it’s a simple, direct, accountable vision.
And yet, as we all know, the actual delivery is much more complex than making the code downloadable.
Understanding how and if you are providing something of real value, defined on the user’s terms, is the key to differentiating between success and failure.
To understand the importance of the software release, you have to start with the needs of the user, and how software development has changed since the first DevOps conference in 2009. Customer feedback, sentiment, and needs are defined in “new real time” — creating the foundation for the closed-loop software development model.
How we used to iterate
When I started out in my first role as a software product manager (PM) in the 1990s, apps were built based on market requirement documents (MRD) or product requirement documents (PRD). I was parachuted from computer science classes right into the distributed computing boom in global datacenters, with mainframes not ready to capitulate but still a formidable force in large IT departments (and in fact still present today in many cases).
IT departments were building capacity for “Christmas Day overcapacity” and large amounts of data processing was paid for and deployed, but rarely utilized. PC apps in general were over-featured, with settings that, in reality, were simply never used and often buried deep into the darkness of obscure corners of the app.
Being a self-made mechanic myself, I clearly understand what it means to try to zoom into a video or picture, or to change the screen resolution while up to my elbows in brake dust or transmission oil. In these situations, what we want is something simple, or configurable with just one touch, or even better, voice powered. Trust me, you don’t want to drive a car after Igor’s brake job if I didn’t follow the instructional video in detail! These are examples of features that would improve the user experience tremendously, if they were easy to access and use.
On my first PM job, as I was defining the MRD/PRD and scope of the app, I would spend six months listening to my customers during which time they would tell me what they wanted. I would turn their requests into the MRD. Then I’d create the timeline (aka roadmap), review the MRD with the Dev team, and they would code to hit the deadlines as defined and agreed. Eighteen months later, the new app features would be ready.
The flaw in this approach is obvious. When you talk to the customers, they will tell you what pains them today, not two years from now. Customers were worried about what just happened last week, what was happening today, and — in the best-case scenario — what might happen next week. They needed a problem solution then and there. So in the end, the features we had spent two years developing had nothing to do with what they needed by the time we delivered it. We had to zig-zag.
Enter the cloud
Everybody knew that software teams needed to be able to work in shorter iterations, or short loops, and the introduction of DevOps + Cloud actually enabled that beautifully. With the cloud, iterations went from years and months to weeks, days and even hours. In its essence DevOps supports the closed-loop iteration model from Plan-to-Monitor, enabling smaller iterations and incremental customer feedback.
The beauty of the cloud and cloud instrumentation is that apps can now provide near real-time user sentiment and feedback, making it possible to run a micro loop. This is the loop that is either focused on individual users, small groups of users or very small-time increments (or all of these) when it comes to the feature release. Direct and immediate customer feedback takes the DevOps mission to the next level from many perspectives and keeps customers and users in the center of our universe.
For me personally, this journey started after reading many books about Extreme Programming as a part of my M.Sc in Information Science thesis.
As I have mentioned earlier, in the real world this passion moved forward with my first PM job, and by following the leadership of BMC Software’s GM Israel Gat who changed the culture and software delivery model at BMC in the early 2000s. Today, Israel still continues to influence and challenge (!) my understanding of software development and my core technical leadership skills.
The main thing that I have learned is that the customer is the epicenter of our world and user stories should define value that can be continuously improved using this micro-loop approach, driven by machine learning and AI.
User stories are defined from the customer perspective and transcribing what users actually want based on direct customer feedback or more commonly via user experience instrumentation such as ML, as a part of a micro loop. PMs will know that user stories are much harder to write but much more powerful than MRDs and PRDs.
Creating a solution for what the user wants to do (desired outcome or objective), and not on how many features the user might think they want, is the difference, and it’s also the difference between hardware and software defining the value of a solution.
With hardware it’s often about performance definitions, as if you’re describing a motorcycle’s performance.
With software, it’s around what the device can do that’s different and valuable — which is the fun you can have on your bike, where you can go with it, and whether or not you want to race it. You need hardware as well as software, and combined, they bring value.
Going from a traditional waterfall development model to SCRUM changed the world, and it certainly changed my world. What made that possible was closed-loop which is now setting the customer in the middle of the app delivery process in near real-time.
And of course, security has to be factored in
I said in an earlier article on LinkedIn that software that’s not secure is like a car without wheels: dangerous, and of no value at all. So, no software solutions should be insecure, and when developing that software, incorporating security early in the process and in all updates afterward is crucial to providing the best possible level of security.
You get annoyed with your bank because they make it difficult to log in online — until you read that another bank’s data has been hacked, along with personal details. Then you’re happy that your bank made life difficult for the thieves as well as you.
Because of the success of the cloud, and what it allows, the expectations that we have of our devices and the software and applications they run today are very different from the first Next Generation Firewall launched decades ago, back when the security profile that we still use today was first produced.
Bringing those two worlds together — the need for value and the need for security — means being innovative. We do that by developing our own solutions such as ThinkShield and by having partnerships and working with the best security companies in the world. In the next 10 years I fully expect great innovation in security.
Putting all of this into practice
Here’s a great example of what I’m talking about. Today, when we ship devices, rather than freeze the software preload months before the launch, we instead chose to enable the device to be shipped with a preload software client, but not the final version of the implementation.
So, when the user buys this new device and opens the box for the first time, the preload is ready to download whatever the latest version of the software is at that point, when the box is opened.
No matter how long ago any particular unit left the factory, and no matter how far into the future any particular device is bought, the software implementation will be the most up-to-date as possible, perhaps only a few hours old — a great customer experience, maximizing the value to the customer.
Can you disconnect hardware from software? Of course not. A brick on a golf course is the same brick as one used in a beach house — but in the context of the structure the brick is built into, the value of the brick changes, and represents different value to different people.
The hard work of making a device do what you expect it to is done by software.
This closed-loop, short-iteration development model with dynamic backlog, focused on the user story, is what creates innovation and value.
The convergence of hardware and software is to make the movement of data simple and fast. You can’t have the one without the other.
It’s absolutely epic. It’s the number one thing in creating a great customer experience.
Originally published on LinkedIn.