Jan Bosch challenges some of the traditional distinctions that people in software-intensive product companies tend to make.
Although many feel that digitalization is, by now, old news and that we should look forward, I feel that we’ve barely started to scratch the surface of what software, data and, more recently especially, artificial intelligence will bring to industry and society. Our ability to automate tasks that earlier needed to be done by humans increases dramatically and frees us up to spend our time on tasks that make the best use of what makes us human.
However, the digital transformation many companies are going through changes many aspects of the business. We’re changing business models from transactional to continuous (or a combination of the two), we can use data for fast feedback loops, we can incorporate AI both in our development processes and our products and we are, generally, moving toward a continuous way of working rather than the project-oriented ways of working we used earlier.
Many moons ago, together with colleagues from several leading European companies, I worked on the BAPO model. For those unfamiliar with it, the BAPO model stands for business, architecture, process and organization. It states that the business and business strategy should define the architecture of our products and platforms. The architecture should define the processes, ways of working and tools we use to build and evolve our products and platforms. Finally, the processes and ways of working should define the organizational structure.
Anyone who has spent more than a blue moon in industry knows that every company claims to be BAPO, but in practice tends to be OPAB, causing the organization and organizational structure to dictate everything else. This is fine as long as the company and the industry it operates in are rather stable. However, when major transformations take place, we must become more intentional in applying BAPO.
Our work with the Software Center companies as well as many others shows that the digital transformation is reshaping traditional organizational structures and roles. A key change is that it tends to render certain distinctions obsolete. In this series, I want to discuss ten distinctions that, in my view, are becoming increasingly blurred and outdated.
1. Product management vs R&D
Traditionally, product management focused on market needs and business strategy and defined what to build, often expressed in a requirements specification. R&D was focused on how to build it, took the requirement specification and developed, tested and delivered the product. When adopting DevOps and fast feedback cycles, product management and R&D need to be integrated into one team that focuses on experimentation as well as balancing new functionality, defect management and architecture refactoring to ensure the long-term value of products and platforms.
2. Systems engineering vs software engineering
Systems engineering has historically dealt with the overall design and integration of complex systems, including mechanical, electronic and software components, whereas software engineering focuses on creating software components. As more and more industries are adopting the principles of software-defined systems, these roles are increasingly intertwined, requiring a holistic approach to both hardware and software development.
3. Purpose vs companies
Traditionally, a company’s purpose was often seen as separate from its business operations. In my experience, many companies pay lip service to their espoused purpose, but the real purpose is to simply earn money. In today’s world, and I expect this to become even stronger over the coming decade, the purpose of the company needs to be deeply integrated into everything it does. Of course, it’s essential for brand identity and customer engagement, but also the modern generation of employees doesn’t just want to work for money but requires a motivation from the company that they can align with.
4. Customer support vs R&D
In the companies we studied during the adoption of DevOps, we noticed that the traditional approach to customer support failed as they were always one or more releases behind. The continuous feedback loops between customers and R&D are vital for iterative development and rapid improvement of products and services but also require customer support to be integrated with R&D.
5. User vs company
The boundary between a user and the company providing a product used by that user is increasingly blurred due to the continuous delivery of functionality and the feedback loop from users, both quantitatively and qualitatively. Also, many companies are looking for ways to engage customers in co-creation processes, leveraging user-generated data and content and feedback to drive innovation and enhance user experience.
6. Development vs operations
One of the more obviously outdated distinctions is between development and operations. DevOps practices require merging development and operations into a unified process and often cross-disciplinary team. Close collaboration proves to be the only way to achieve continuous integration and delivery to improve efficiency and product quality.
7. Innovation vs development
Although radical, horizon 3 innovation will still be separate from traditional development, all innovation affecting existing products and platforms is increasingly integrated into the development process. Earlier, innovation was often separate from routine development, but this is no longer effective when adopting continuous deployment. In modern agile environments, innovation is embedded within the development process, fostering continuous improvement and adaptation.
8. Products vs services
Many companies talked about themselves as either delivering products or services and when a company did both, these activities were organizationally very distinct. Digitalization and the continuous value delivery associated with it are causing many product companies to increasingly act as service providers. Many product companies are offering product-as-a-service business models and are developing digital services to complement their physical products to enhance value.
9. Platform vs product
Earlier, platforms were often used to capture the common functionality between products, allowing each product to build its differentiating functionality on top of the platform. Adopting DevOps necessitates an alternative approach to platforms, which I refer to as the superset platform approach, where the platform contains the superset of all functionality offered by all products. Consequently, each product becomes a configuration of the platform and the distinction between a platform and a product disappears.
10. Business model vs product
In the past, product-led companies built products and then told sales to generate revenue from them in any way they saw fit. That no longer works in a digitalized world as the product’s design and the way we aim to monetize the product need to go hand in hand from the start. This requires engineering to deeply understand the business and monetization strategy and build the enablers for different approaches to deliver value to customers. Sales needs to understand the technology and work closely with engineering to ensure that all viable avenues for revenue generation are exploited.
Humans always look for ways to simplify the incredibly complex world we live in and the most effective strategy we have is to create concepts and draw clear boundaries between them. In organizations, we tend to do the same and often organize work around a product, a discipline, a business model, a region or some other organizing principle. Once we create the ‘boxes,’ these tend to become fixtures in our heads as, especially in groups, it helps to have a common framework as a basis for discussion and collaboration.
We live in an age of very rapid change, in large part due to digitalization, and as a consequence, several of the concepts, boundaries and organizing principles are no longer as effective as they were earlier. Continuing to use them tends to be less effective and productive and may easily lead to a situation where we’re outcompeted and disrupted by players who use a better set of organizing principles. In many ways, I believe that SaaS companies have a better way of organizing themselves than traditional software-intensive product companies. And if I compare what the product companies under the leadership of Elon Musk are accomplishing compared to many of the companies I work with, I venture that he’s found ways of organizing work and applying organizational principles that simply are better than the traditional ones.
The purpose of this series isn’t to eradicate all distinctions and make everything one big ball of mud. Instead, I hope to challenge some of the traditional distinctions that most, if not all, people in software-intensive product companies tend to make. We need to find new organizational principles that fit better with a digital world where we deliver new value to customers continuously. We need a new paradigm. To end with a quote by Stephen R. Covey: “Paradigms are powerful as they form the lens through which we see the world.”
