How digital-native companies are structured?

During the course of my career, I have worked with many different kinds of companies developing digital products or services. Some of them have been more on the traditional spectrum of companies, while others are born digital.

The organizational structures of these different types of companies differ significantly, which is understandable considering their vastly different histories. When more traditional companies enter the digital product development space the inefficiencies of the traditional organization structure begin to become visible.

In this issue, I’m going to scratch the surface of this topic to highlight the key things that traditional companies can learn from their born-digital counterparts.

All aspects come down to autonomous and end-to-end responsible teams. It is a broad topic with lot of details, but I try to cover here the main aspects I see.

Full responsibility over a product or service area creates end-to-end ownership for the team. Team is responsible in all the aspects of the product, like a small business or a startup would be. Giving product teams full ownership of their product increases motivation, accountability, and alignment with customer outcomes.

I cannot emphasize the impact of this enough based on what I have seen during my career. Organizational friction increases significantly as decision-making moves further away from the core team addressing the problem.

Developing digital products is a craft of experimentation and an enormous amount of detail. Every new product feature inherently involves some level of experimentation, whether in user interface design or at the code level, generating additional data to inform decision-making.

Teams that own the entire product can make decisions quickly based on what is best for the customer or aligns most effectively with the product or company strategy, according to their perspective. If many of the the decisions need to be brought up to the company leadership team it significantly slows down the product team and kills their productivity. Building a digital product is a labor-intensive activity, and you do not want a group of skilled professionals sitting idle; that one gets expensive pretty quickly.

Company leadership still needs to establish the company vision and strategy, which the product team then develops into a product strategy to support their own decision-making.

In some circles the tenet “Fail Fast” is already somewhat of a cliche, but I think it holds a lot of practical wisdom too.

A team building digital product is on a much safer journey when they do things iteratively, small step at a time. At best, each iteration should be validated, by the target users or customers. Validating things in small steps keeps the team aligned and customer-centric. In case something does not workout or fails totally, the blast radius is small and team can easily try some another way forward. Imagine if the same team, or multiple teams working together, were to progress on a larger set of features all at once before validation. The possible blast radius would be bigger, and realignment would be much harder.

Small teams owning their product can move relatively quickly in small steps, realigning based on data from even the smallest failures. This way even a large organization can move relatively fast as all teams have end-to-end ownership to their product.

The bottom line is that the born-digital companies are structured for customer value generation, based on the evidence and experience how the customer value in digital product business is best delivered.

It would be quite irresponsible to say that all traditional companies must flip and reshuffle their organizational structure immediately when they step into digital product business. Similarly, I’d say doing nothing at all would likely be a mistake too.

Would you like to hear more about how some of these aspects could be applied in your organization? Just book a free consultation call below.

Until next time,

Pyry Kovanen,
Kaiden