Digital Transformation
cancel
Showing results for 
Search instead for 
Did you mean: 

The Digitization of Everything means "A New Style of Business"

mikeshaw747

Let’s take a look at how the digitization of everything, and thus, “software-defined products” allows to change the way we do business (I introduced these concepts in a previous blog post).

 

This blog post contains the following sections...

 

A.  Start with an early release, Minimum Viable Product

B.  Publicly Experiment

C.  Continuous Innovation and thus, Continuous Delivery

D.  Be prepared to fail - Become more like a Scientist

E.  Related Blog Posts

 

1. New style of biz.png

 

A. Start with an early release, Minimum Viable Product

 

When products were all physical, with no application driving them, if was very difficult to update them once they were released. You couldn’t, for example, update the functionality of your record player or your home thermostat - the functionality you got when the product was the functionality you were stuck with. This meant that manufacturers had to wait until they had a full-functionality product before they released it - no-one would have bought a thermostat that had a few functions missing.

 

This requirement is no longer there when products are software-defined. We can buy a thermostat that is very much “first release”, knowing that the manufacturer can download software updates to improve the functionality as they learn more about what people want from their product. We can use the first version of a music player like Spotify, knowing that over time, its functionality will be improved.

 

This means that product managers can get products to market earlier than previously. This then allows them to get an ealry entry point into the market, and to learn about how their customer use their products.

 

These early-release products are known as MVPs or Minimum Viable Products.

 

It’s interesting to see consumers’ reaction to taking minimum viable products. They might not be for everyone, but a lot of people are now prepared to accept taking the first release of new product if they trust that the manufacturer will “get it right eventually”. We are, of course, used to pure software products like Spotify or Gmail constantly being updated, but this also happens to products that are partially software-driven. I took my car in for a service last week, and when I picked it up, the engineer told me that they had downloaded a software update and that the automatic door locking functionality had changed.

 

1. Google_Mail_Beta_logo.png

 

B. Publically Experiment

 

When products are all, or in part, software-defined, we can experiment with functionality. Why would we want to do this?

 

I was a product manager for many years. I recall many a discussion with development engineers about what functionality customers would and wouldn’t like. It was all theoretical. Sure, we had a few “tame customers” we could talk to, but it was a conceptual discussion and even if we gave them a mock up, it was never used in anger.

 

Now, development teams routinely put out three or four versions of a product at the same time as an experiment to see which versions, and which parts of which versions, customers like best.

 

You'll notice that the title to this section is "Publically Experiment". Not "Internally Experiment", but "Publically Experiment" - important difference.

 

1. edison.png

(citation : Photo Thomas Edison. www.businessInsider.com

 

As with minimum viable product, experimentation is strongest with purely software-only products, but the practice is starting to be used with products which are in part software-defined too. 

 

Experiments and Canary Rollouts

 

How does product experimentation work? Typically, experiments will be small scale. You probably won’t find a company giving one half of their installed base one version and the other half another. They will probably use small groups of users, giving each group a different version. This approach is known as “canary rollouts”. 

 

Canaries are birds that spend most of their time singing - hence the phrase, “singing like a canary”. Before the invention of poisonous gas detectors, canaries were taken down mines in cages. While the canary sang, you were good. When the canary stopped singing, you needed to get worried. Canary rollouts allow manufacturers to test ideas without impacting all of their installed base should the experiment not work out.

 

1. canary rollout.png

 

Canary groups are chosen based on demographic (people younger than 21, for example) or geography (everyone in the country of Finland, for example), or are self-selecting (invitations to take part in experiments are one of Google’s favourite approaches).

 

Using Big Data to get fast, detailed and accurate customer feedback

 

Going back to my product management days, we would do early releases of product. And it was my job to collect feedback from these early releases. I would ring up the beta customers and we would have a discussion. It was a time-consuming business, and the feedback was not always that scientific (very unscientific, in fact).

 

Big Data has changed all this. Companies like Twitter and the gaming division of Sony use big data techniques to collect detailed information about how customers are interacting with their experiments. Big Data allows them to both quickly and accurately monitor their experiments - what do customers like, what don’t they like, where do they spend time, and so on.

 

 

C. Continuous Innovation and thus, Continuous Delivery

 

In “the old days”, innovation was serial. You released a product and then you started working on the next version. Your first record player was good, but the next version, released two years later, was better, and the next version, release two years after that, was better still.

 

Software-define products allow us to practice “Continuous Innovation” - three versions of our product are in production, another is in canary rollout in Finland, another is going thru final system test, and yet another is in design and development.

 

 

1. app factory.png

 

Continuous Innovation demands that the people creating the software are able to practice Continuous Delivery. Rather than everyone working on a product, releasing that product, having a celebration and then starting on the next version, we need to be working a number of different versions as the same time. In later blog posts, I plan to talk a more about this, because you can’t go from serial delivery to parallel delivery using the same tools, the same level of automation, and the same measures and attitudes.

 

Continuous, parallel innovation makes it difficult to "buy your way to innovation"

 

As an aside, parallel, continuous innovation makes buying your innovation difficult. In the old days, if you were cash rich and wanted to enter into a technology area, you would buy one of the companies delivering the latest product. But with parallel, continuous innovation, you don’t want to buy the latest product, you want the version in design and development or the one in system test. This is much higher risk than buying a released product - as an ex-product manager, I know that the distance between a product in design and development and a product actually in production can be huge.

 

While acquisition of innovation will still be an option, companies can’t rely entirely on this strategy - they must innovate themselves.

 

 

D. Be prepared to fail - become more like a scientist

 

Agility, innovation and experimentation look "messy" to management

 

A good friend of mine works for a software company. She was told by management to “adopt agile”. Her development team adopted all of the techniques I describe above - minimum viable product, experimentation, and continuous delivery. 

 

My friend was put in charge of controlling the continuous delivery product - a “sprint manager” in agile speak. So far, so good.

 

And then management, who thought that agile was something that just applied to software teams and not to the business, started asking what the product would be released and what functionality it would contain at first release. Of course, my friend didn't know - these were things that would evolve thru the "continuous innovation" process.

 

My friend wasn’t being difficult - it’s just that a corollary of this new way of thinking is that you inch forward in terms of functionality and the idea of a “release date” becomes a very fuzzy thing. No-one at Spotify or Nest could have told you what functionality their products would eventually have when they started coding.

 

The delusion of control with the "well planned release"

 

At first glance, it may seem that this new way of thinking is much higher risk than the old, serially planned approach. Putting on my ex-product manager’s hat, I would strongly disagree. The old way of doing things was full of delusion. I would create an external spec. The assumption was that I had a degree of omnipotency - the spec was “correct” and should be implemented. What rubbish. The new way of doing things where we get a minimum viable product “out there” as soon as possible is much more honest. Yes, you can’t tell management exactly what the product will contain, nor when it will be “finished” (whatever “finished” is in a world of continuous innovation), but at least every step you take is used in anger (hopeully, not too much anger) by real customers.

 

Postulate, experiment. Rinse and repeat.

 

The modern product team needs to be a little less “engineer” and a little more “scientist”. Like any good experimental scientist, they need to postulate a theory (like, for example, “people will love a cool, self-learning thermostat”) and then test it, maybe comparing two or three different versions at the same time.

 

Experiments “fail”. However, as Thomas Edison said, “I have not failed. I’ve just found 10,000 ways that won’t work.” One of your “deliveries” from the continuous delivery factory may not work well, but you will almost certainly learn from it. And because you have a continuous delivery factory, you’ll be able to quickly adjust.

 

 

E. Related Blog Posts

 

Below is a list of related blog posts on The Digitization of Everything and Core / Fluid IT:

      

1. The Digitization of Everything and A New Style of Business (this blog post) : digitally-based, software-powered products allow the business to do things very differently. We can release "minimum viable product", we can experiment with new products we can "continuously innovate". 

 

2. Digital Disuption: From Transforming a Product to Disrupting an Industry : digitization starts with a digital product that replaces the analog one. Think CD or DVD or home thermostat. But, once products are digital, the business model can be disrupted - think Spotify, think "the connected home", think Uber, think AirBnB. This blog looks at this disruption for a number of industries including transportation, retail banking and the connected home. 

 

3.  Digitization of Everything and the role of Central IT : digital disruptions are "software powered". Which is great because IT creates software, doesn't it? But it's a very different style of software development to that that we used for our Systems of Record. 

 

4.  Capitalize on The Digitization of Everything with two different IT modes : IT can't be innovative, cool, experimental and reliable, careful and solid using the same people, the same behaviours, the same processes, the same supplier relationships. We need to split IT into two - Core IT and Fluid IT.

 

5.  The Guardian Function - making the Core / Fluid IT co-operation work : If the two parts of IT, the Fluid and the Core, don't cooperate with each other, we'll eventually become uncompetitive and inefficient across the whole organization We need to ensure that the two parts of IT work well together. This is part technology (as discussed in the next blog post) and partly about governance, finance and attitudes. This blog post talks about "The Guardian Function"; that function that ensures the cooperation works. 

 

6. The Five Areas of Cooperation between Core and Fluid IT : I've broken the technical aspects of cooperation between Core and Fluid IT into five areas : i. Service Brokering, ii. Continuous Delivery, iii. Creating a best-in-class user experience, iv. Big Data and v. Protecting your assets. This blog post looks at these five areas in overview.

 

7.  Service Brokering for Core and Fluid IT cooperation : This post dives into what customers tell me is the most important of the five cooperation areas; Service Brokering. 

 

8. How to get to Continuous Delivery and thus, Continuous Innovation : This post looks at the second cooperation area; getting Continuous Delivery of new functionality. This entails a flow of new releases from Fluid across to Core IT. It is, of course, DevOps, but I've put a Core/Fluid IT spin on it. 

 

9. How to create an Engaging, Best-in-class  Digital User Experience : Digital products pretty much always mean either a mobile application and / or a smart device like a smart cooker, a smart thermostat, or a smart shopping trolley. We need to ensure that the user experience of that mobile application or smart device is best-in-class. How do we do this across our Fluid and Core IT teams?

 

 

My "scoop.it" topic on the Digitzation of Everything - a couple of times a week, I post interesting articles on what's happening in the world of "the Digitization of Everything".

 

Screen Shot 2015-09-07 at 09.16.17 7 Sep 2015.png

 

I also post all updates to my status in LinkedIn. You can connect to me on LinkedIn at Mike Shaw, HP.

 

Mike Shaw
Director Strategic Marketing

twitter.gif@mike_j_shaw
linkedin.gifMike Shaw

  • IT Strategy and Leadership
0 Kudos
About the Author

mikeshaw747

Mike has been with HPE for 30 years. Half of that time was in research and development, mainly as an architect. The other 15 years has been spent in product management, product marketing, and now, strategic marketing. .

Comments
bibol

Nice information you have here
love it so much
I will remind myself to visit here again.

Puja sharma

Your style is really unique compared to other folks I have read stuff from. Many thanks for posting when you've got the opportunity, Guess I will just bookmark this web site. http://packers-and-movers-bangalore.in/

puja sharma
Your style is really unique compared to other folks I have read stuff from. Many thanks for posting when you've got the opportunity, Guess I will just bookmark this web site. http://packers-and-movers-bangalore.in/
Labels
Events
28-30 November
Madrid, Spain
Discover 2017 Madrid
Join us for Hewlett Packard Enterprise Discover 2017 Madrid, taking place 28-30 November at the Feria de Madrid Convention Center
Read more
See posts for dates
Online
HPE Webinars - 2017
Find out about this year's live broadcasts and on-demand webinars.
Read more
View all