Skip to content
Bits&Chips
×
×
About
Memberships
Advertising
Magazines
Videos
Contact

Log in

Jan Bosch is a research center director, professor, consultant and angel investor in startups. You can contact him at jan@janbosch.com.

Opinion

From Agile to Radical: link architecture and teams

19 August 2024
Reading time: 5 minutes

Jan Bosch explores the setup where R&D teams are organized based on innovative, differentiating and commodity functionality.

Many of the companies I work with have a continuous discussion concerning organizing teams around the architecture, ie component teams, or organizing teams around features. Many factors play into deciding on the preferred model. My general advice is to focus on where the highest degree of complexity and challenge is. If specific components contain highly specialized and complex functionality, assigning teams to those components is likely the better approach. On the other hand, if the main challenge is the end-to-end integration of all functionality related to features, then it’s better to focus on feature teams.

Although many seek to take a binary decision that uses the same approach everywhere, I think it’s important to realize that there’s also a hybrid approach. In this case, we use component teams for the small set of highly complex components containing some of the key differentiating functionality that sets the company apart from the competition. In parallel, we use feature teams for the rest of the system. This combines the best of both worlds and allows companies to drive innovation and efficiency.

There is, however, a third perspective that I want to discuss here: classifying the functionality in the system using the principles of the three-layer product model. In this model, all functionality in a system, platform or portfolio is categorized into three categories: commodity, differentiating or innovative. Commodity functionality is the functionality that’s required for the system to function but doesn’t provide a reason for the customer to buy the product. Sometimes referred to as “table stakes,” we need it, but it isn’t special. Because of this, investments in this category of functionality should be as limited as possible and focus on minimizing the total cost of ownership.

Differentiating functionality, as the name implies, is the functionality that helps us stand out from the competition. It’s what customers talk about when they’ve selected our system and what prospective customers use to evaluate us against competitors. Consequently, we should focus our R&D investments on this differentiating functionality. This is where the return on investment is earned.

The challenge is that what’s considered differentiating inside the company is frequently already considered commodity by customers. This discrepancy causes companies to overinvest in commodity functionality, decreasing the investment in functionality that’s actually differentiating.

The third type is innovative or experimental functionality. The word “innovation” is incredibly overused and often refers to differentiating functionality. In our model, however, this category contains those features, concepts and ideas for which we haven’t yet established that they provide value to customers. This is where we try to generate as many ideas as possible and then, through a variety of mechanisms, seek to establish as quickly and cheaply as possible whether they hold water or not.

Innovation can refer to sustaining innovations that maintain the differentiation of the system, platform or offering and this is where we use the term in the context of the three-layer product model. However, innovation is also required to identify, build and grow entirely new products and lines for business. For the latter, I often refer companies to the three horizons model.

A well-functioning innovation team should have a success rate that’s in the 5-25 percent range, meaning that all the other initiatives have failed in that customers didn’t consider the ideas valuable. If the success rate is higher, we’re too conservative in trying out new things, which is a risk as competitors and new entrants may identify areas of innovation that may cause us to be disrupted.

The challenge with innovation and experimentation is that many who work with commodity and differentiating functionality fail to recognize that the nature of innovation is that most initiatives fail. Evaluating innovation activities from their perspective, where 95 percent or more of their efforts lead to successful outcomes, makes innovation seem incredibly inefficient. The consequence may be that those responsible for innovation start to act more conservatively to increase the success rate. At its worst, the innovation team becomes an extension of normal development, simply asking customers what they would like to see in the product and then building it.

In addition to component teams and feature teams, the third alternative is to organize the teams around the three layers of commodity, differentiation and innovation. One team or set of teams is assigned to work on functionality that’s considered commodity and their efforts focus on minimizing the total cost of ownership. This often includes removing variants, replacing internally developed functionality with open-source or commercial software acquired outside the company or even creating open-source initiatives to share the cost of maintaining certain software with a community of developers outside the organization.

A second team or set of teams works on differentiating functionality. These teams want to maximize the value of differentiating functionality to customers. This often includes adding variants, providing alternatives for the most valuable use cases, dealing with special cases and deeply understanding how customers use the functionality, both through quantitative data and customer interaction, to maximize the value of the system for customers.

Find the few ideas that bring home the bacon

The third team is concerned with innovation activities. They’re the vanguard, trying out many, potentially crazy sounding, ideas with the intent of identifying the few nuggets of gold that can be used to provide future differentiation. Their focus is to try out as many ideas, concepts and features as possible to find the few ideas that bring home the bacon.

In terms of resource allocation, our research shows that companies spend 70-90 percent of resources on commodity functionality, the remaining on differentiating functionality and hardly anything on innovation. My recommendation is to seek to limit investment in commodity to 35-50 percent, ensure at least 5-10 percent investment in innovation and use the rest for differentiating functionality. Of course, this depends on the specifics of each company, but it’s a rule of thumb that can be used as a starting point.

The advantage of explicitly modeling R&D in terms of these three layers is that it requires explicit decisions about the state of functionality. The innovation team will transition functionality to the differentiating-functionality team when this functionality is desired by customers and we have the evidence to back this up. Similarly, commoditizing functionality is handed over by the differentiating-functionality team to the commodity team when the time is right and from that point on, the functionality is treated very differently. If you want to learn more about the model, I refer you to my book “Impactful software,” which can be downloaded for free from my website.

Most companies have a constant discussion and tension between organizing R&D in terms of component teams or in terms of feature teams. There are arguments for both and I encourage companies to adopt a hybrid model. Here, I’ve explored a third alternative: organizing teams based on innovation, differentiation and commodity. In this setup, teams have very clear KPIs to focus on, ie trying out as many ideas as possible, maximizing the value of differentiating functionality for customers and minimizing the total cost of ownership for commodity functionality. To end with a quote from A.A. Milne: “Organizing is something you do before you do something, so that when you do it, it doesn’t all get mixed up.”

Related content

Machines that think: the design loop

From research tool to software modernization service

Top jobs
Your vacancy here?
View the possibilities
in the media kit
Events
Courses
Headlines
  • Summit in Delft addresses Europe’s shortage of systems thinkers

    26 October 2026
  • Micron rules out 4F² DRAM in favor of continued scaling and 3D transition

    22 October 2026
  • Nvidia moves optical engines onto interposer

    22 October 2026
  • Melexis selects Neways for pressure sensor packaging

    22 October 2026
  • Amsterdam quantum venture wins Photondelta contest with chip-based atomic clock

    21 October 2026
  • Photon Bridge raises €10M to scale lasers for AI interconnects

    21 October 2026
  • Intel pitches 300mm silicon photonics with integrated InP lasers

    20 October 2026
  • New Origin photonics fab clears power and water hurdles

    20 October 2026
  • Quantinuum reports error correction advance toward 2029 quantum computer

    20 October 2026
  • Chinese startup presents 15-watt EUV source prototype

    19 October 2026
  • Terafab reportedly to receive first ASML EUV scanner in mid-2027

    19 October 2026
  • Cloud giants’ capital spending to exceed $1.5T in 2027

    19 October 2026
  • Fab construction on the rise to meet AI demand

    14 October 2026
  • ASML considers further capacity expansion beyond existing growth plans

    14 October 2026
  • Eindhoven-based chip designer Sciosense acquired by China’s Fortior

    13 October 2026
  • Dutch high-tech sector calls for lasting successor to Growth Fund

    13 October 2026
  • Spectacell raises 6 million euros for chip-based cell imaging

    12 October 2026
  • Globalfoundries targets physical AI with new FD-SOI platform

    12 October 2026
  • Besi and Applied deepen packaging collaboration

    6 October 2026
  • Xiver secures €28M for production expansion

    5 October 2026
Bits&Chips logo

Bits&Chips strengthens the high tech ecosystem in the Netherlands and Belgium and makes it healthier by supplying independent knowledge and information.

Bits&Chips focuses on news and trends in embedded systems, electronics, mechatronics and semiconductors. Our coverage revolves around the influence of technology.

Advertising
Subscribe
Events
Contact
Follow us on
High-Tech Systems Magazine (Dutch)
(c) Techwatch bv. All rights reserved. Techwatch reserves the rights to all information on this website (texts, images, videos, sounds), unless otherwise stated.
  • About
  • Memberships
  • Advertising
  • Videos
  • Contact
  • Search
Privacy settings

Bits&Chips uses technologies such as functional and analytical cookies to improve the user experience of the website. By consenting to the use of these technologies, we may capture (personal) data, unique identifiers, device and browser data, IP addresses, location data and browsing behavior. Want to know more about how we use your data? Please read our privacy statement.

 

Give permission or set your own preferences

Functional Always active
Functional cookies are necessary for the website to function properly. It is therefore not possible to reject or disable them.
Voorkeuren
De technische opslag of toegang is noodzakelijk voor het legitieme doel voorkeuren op te slaan die niet door de abonnee of gebruiker zijn aangevraagd.
Statistics
Analytical cookies are used to store statistical data. This data is stored and analyzed anonymously to map the use of the website. De technische opslag of toegang die uitsluitend wordt gebruikt voor anonieme statistische doeleinden. Zonder dagvaarding, vrijwillige naleving door je Internet Service Provider, of aanvullende gegevens van een derde partij, kan informatie die alleen voor dit doel wordt opgeslagen of opgehaald gewoonlijk niet worden gebruikt om je te identificeren.
Marketing
Technical storage or access is necessary to create user profiles for sending advertising or to track the user on a site or across sites for similar marketing purposes.
  • Manage options
  • Manage services
  • Manage {vendor_count} vendors
  • Read more about these purposes
View preferences
  • {title}
  • {title}
  • {title}