Digital Transformation is tricky

According to Samsung, the company implemented what they call a New Concept Development in 2013. At the time, this was the new product development strategy of Samsung. I’ll explain what this has to do with Digital Transformation in a minute.

As a part of Samsung’s overall innovation process, a Project Innovation Team (PIT) was born out of the need to have an incubator group to work with every business unit to provide more market insight.

Taking advantage of the Google Android operating system, the company is nowadays leading the global Smartphone market with 22% in Q2’19.

It is interesting to read Yoon’s comment on the core of the change.

The primary mission was to change our customer-facing product development process from engineer-driven to customer-driven

Yoon C. Lee

Samsung’s PIT is following a four-step process: Understand, Ideate, Concept Development, Concept Finalization.

Transformation In Progress

Around 2006, the time the team has been established, a lot of organizations made the step to customer-centric development. In retrospect, I’m asking myself why it has ever been done differently, to be honest.

Considering the sizes of enterprises such as Samsung, Microsoft (which also performed a remarkable transformation), GE, ABB, etc. it is no wonder that some large companies are still in the process of implementing the new concepts.

Thinking of the Past

In most cases, the companies had a more or less working product management which was shielding the customers from development team questions such as “what do you want to achieve”.

The development teams were embedded in V and waterfall models, which work very well for products where components need to be put together.

Software development, however, is a creative process which can better be compared to painting a picture. Even a doctor’s visit to check the reason for certain symptoms comes closer than assembling a motor.

At the same time the handover date, scope of work and resources/price needs to be communicated upfront. A timeline is set to, for example, ramp up the complex marketing machine.

This is also btw, why I think it is not good to speak about projects in product development:

A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.
And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.


A product team is quite the opposite. It is an in many regards well-balanced, empowered team that stays together and continuously explores opportunities as long as the product is alive. The goals are defined per iteration and base on moving targets, such as KPIs.

Why the Digital Transformation is so hard

Until today, applying the project way of thinking, which is dominant in industrial environments, to product teams causes friction in organizations. This might also be related to the fact that development works best with budgets than cost/effort estimations.

Effort estimations and Statement Of Work-based pricing almost always lead to a lock-in of too many variables (quality, resources, time, money, scope) which lead to missing the agreed goals.

So why is it so hard in large enterprises to think of development like going to a doctor?

Digital Transformation isn’t about digital products

It’s about an organization’s mindset

Everybody accepts that doctors can’t tell upfront how long it will take to heal, so why do we expect the development team to be able to do this?

It is convenient and gives a feeling of control.

But it is a lie.

Consider the pain involved in accepting this. Whole sales organizations are incentivized to sell equipment which gives a commission. If such organizations are asked to sell digital subscriptions, you are set up for failure.

When given the choice, a salesperson would always choose the one with the high commission over the low. To be honest, who wouldn’t?

On the other side, for example for co-development, it is better to use incremental delivery contracts. This enables the customer to exercise influence and get what is required with a lot less emotional pain. On top of this, it enables a faster go to market for the customer himself.

Embrace Change and move on

The sooner an organization moves on and deals with this, the sooner products can be created that really provide customer value. After adapting the required mindset, introducing digital products is easy.

Where value flow is, there can be cash flowing as well


So what’s important for a successful Digital Transformation is:

  1. Separate disruptors / the Product Innovation Team (PIT) from the rest of the organization, while they are in their ideation to allow them to be creative without the judgment
  2. Get the PIT regularly grounded by involving operational entities
  3. Give the PIT market access
  4. Understand that PITs have another working mode (explorative, hypothesis-driven vs assertive)
  5. Incentivize everybody on the goals of the transformation
  6. Have goals that make sense for each organizational level
  7. Manage goals and expectations (a mindset doesn’t change overnight)
  8. Embrace failure, but require to document what has been learned
  9. Give everybody in the organization a voice (not via townhalls, but via collaboration platforms)
  10. Record every meeting and hold people accountable
  11. Reduce meetings to 6 participants and have a timebox
  12. Note the money spent for a meeting
  13. Trust the teams to make autonomous decisions
  14. Digitalize internally first, then externally
  15. Change the mindset to “You rent a team and don’t buy the outcome”

By now it should be clear, why I picked Samsung in the beginning. I think they are doing a lot right, which is why I’d like to cite Yoon again:

Without a replicable process, it is very difficult to make innovation stick within a large organization. But there is a secret sauce to it. Make the process extremely simple.

Yoon C. Lee

Print your guiding principles on the back of every business card. Why should you hide them from your customers anyways? You might, after all, have the same gole but didn’t know yet 🙂

Generative Software Design

Ever since Maurice Conti’s talk, which also included generative design, I thought about applying this to software development. In Generative Design, CAD software explores the solution space to find an optimal solution using constraints and objectives given by the user. For software development, I call this Generative Software Design.

When comparing software development with mechanical engineering and industry, it feels like we just finished the First Industrial Revolution.

The Industrial Revolutions:

First RevolutionMechanical ProductionSteam, Water1765
Second RevolutionMass ProductionElectricity1870
Third RevolutionDigitalizationIT, Electronics1969
Fourth RevolutionIndustry 4.0Internet, VR, AR, CloudNow

We just made it from reinventing the wheel over and over again (fixing a spoke with hand tools) to sharing libraries via GitHub (order spokes as components) and the use of platforms and frameworks (order wheels/set of components). So in a sense, the driver (steam) is the connected world.

Software Mass Production – The Second Software Revolution

Software developers bare with me. I know development is a creative task and what’s coming next is a stretch. 🙂

Following this thought process, it would be logical to next progress using standardization towards the Second Software Revolution (software mass production). And in a way in the past this trend showed from time to time when yet another code generator or a low code platform was born.

As a result of the Third Software Revolution, the code will be generated by providing (business) objectives. The algorithm then solves for an optimum independently. By using Generative Software Design, the glue between the modules and maybe the modules themselves are optimized. A computer explores the solution space for the best design.

Software Mass Production Prerequisites

  • All existing libraries need to contain a standardized description and have some form of unified interface (Think swagger on steroids)
  • Transforming the non-compliant, existing libraries with an automatic wrapper mechanism would be incredibly helpful
  • Algorithms to identify common code segments to be standardized and carved out into a library
  • Algorithms to identify common, standardized code segments and suggest them during programming or refactoring

In a way, this scenario seems to be unavoidable. It might take time but if you compare code today with code ten years ago, there is a very clear trend towards libraries. The type of code changed as well. Where twenty years ago we implemented ring buffers, you find nowadays code defining the data flow between distributed modules.

Smart Software Libraries are the first step

Smarter libraries allow progressing and focusing on new, more complex topics. We are just at a stage right now where standardization would add structure to this. This allows companies and individuals to focus on creatively solving business problems while paying less attention to knowledge obsolescence.

Change in Workforce

This has implications. While coding gets more powerful on one end and more automated on the other end, higher skills are required to work in the industry. As of today, 18.2 million employees work as software developers.

In the First and Second Industrial Revolution, the change in the workforce was relatively slow because for example not every company was able to afford a steam engine.

Many jobs shifted toward creativity and people skills. It’s not by accident that roles such as marketing, human resources management (must read), production, finance, and functions of management had to be created just for this new era.

Further Thoughts – Repeating Pattern

It might be interesting to do some research on repeating patterns in technology. While technology evolves, knowledge of these patterns might be useful to analyze and predict for example security concerns or implications for society.

Generative Software Design Conclusion

As always, innovation requires the willingness to change. For the industry more standardization in software modules could enable enormous gains. To do this is and eventually progressing to more automated software development, if it is at all possible, will require a lot of work.

With a Second Software Revolution, the change of the required skillset can happen in a couple of days. This is why I believe, in a time of specialization, it’s important more than ever to get a broad skillset.