Speed Layers: The Secret Sauce of Product Management

Petra Färm article

The world is spinning faster and faster, tech changes are exponential and disruption is the new normal. Product management needs to be fast, but to be fast, you sometimes need to be slow. It takes time and long-term thinking to create ecosystems, build platforms, and do APIs for customization. All of which will enable speed. 

In the 21st century, the secret sauce of successful product management is speed layers, a concept that will use speed as the driver for product architecture, team collaboration, and investment decisions.


Already in the beginning of the 20th century, big city people were stressed because horses were replaced with cars, business correspondence and letters were distributed overnight with the new railway and evening posts started to come out. Suddenly you had to consume two papers a day instead of one to stay up-to-date: That is an exponential change. No wonder city people were feeling stressed, just imagine how they would feel today or how we will feel 10 years from now…

On the other hand, complexity is increasing and slowing us down. The financial system of the world is so intertwined and intricate that no single person can understand it all. It’s hard to predict how a slight change in the corner of the system might ripple through. Today, it takes longer to build a skyscraper in New York City than it did 100 years ago, mostly due to logistics but also things like electricity and plumbing.

We have standardization and ecosystems. Collaboration takes time. So, how can we manage the different speeds a product has to operate in?

Speed Layers

Part of the answer was provided already 2011 in the wonderful article “Speed, rhythm and time-space” where Dr. Nick Prior presents research on the notion of time in conjunction to museums. He explores the various rhythms and how they require different ways of thinking and acting.

Let’s build on that thought and think speed in time-space when we think product management. How many different speeds does a product have to relate to? Based on research and our many years of industry experience, our answer is two to four, and most commonly three, for well-established organizations.

One long-term ecosystem creating, platform building speed, one market-driven where your product has to have the same beat as the market, and finally, a fast, responsive and explorative layer.

Foundation Layer: Stay Grounded

If we take a step back and look at product companies with a speed perspective, we can see that there are things, ecosystems, processes, maybe platforms, that are slow moving, and that need a long-term thinking for strategy and investment. Here we do want to take our time. This is described a bit in Gartner’s bi-model IT and McGrath Platform companies.

In this layer, you should build long-lasting teams with platform and complicated subsystem team topologies and use API or X-as-a-Service collaboration models. Investment decisions are made on the basis that this is the ticket to compete. No investment in the foundation layer means no sustainable revenue.

Product Layer: Keep the Edge

Then we have market-driven speed, our product releases, the beat, how we keep our edge, communicate, stay relevant. This pulse is dependent on the market. Here we can make classic business decisions and think roadmap rather than strategy. 

Stream-aligned team, organic organization – what do we need right now. Teams can have intermittent tight collaboration for certain releases and then move on to other collaborations.

Fast Layer: The Need for Speed

Sometimes we have to fix something, test something, or do customization or…  Part of this layer will be sales-driven and should be funded by the customer. Part will be explorative, maybe driven by a need from the other layers; then those should fund it.

Here it is possible to work in initiatives, projects, task forces as well as more long-lasting customer success teams. 

The Magic Happens Between the Layers

As always, the magic is not in the boxes but what happens between them. How do we move things from the product layer to the foundation layer? How do we learn from the exploration, and understand how to productify?

There must be rules of engagement between the layers. For example, the fast layer can never be allowed to corrupt the foundation layer.

At one tech company we worked with, an innovation/demo capability was created that operated in two speeds. One slow, foundation speed with a long-term team and one high speed included the various functions that needed to use the capability. They collaborated for assignments, the foundation layer being the permanent force and the fast layer rotating. We have seen the same in other tech-heavy companies.


The Speed layer model has been implemented at a number of organizations and also subjected to light research. Some of the identified challenges were:

Needs to be tailor-made

The speed layer model requires thinking and iterating when implementing. There are some guiding principles for identifying the drivers and the keys of each layer, but many things will be unique for your market, your company and your product.

Requires a mature organization

Since the model needs to be tailored for your needs it can be tough to do in an organization with high turn around, lots of consultants or junior people. It will require thought leadership in the product.

To be fast you need to go slow

In some organizations with complex products there might be a need for nested speed layers. 

Key Takeaways

  • Use speed layers for your product architecture, team collaboration, and investment decisions.
  • Look at your ecosystem through the lens of speed. It takes long to create an ecosystem, but you need to respond fast if an ecosystem dependency breaks.
  • Setup different team topologies and collaboration models depending on the speed layer.
  • Look at investments in the foundation layer as a ticket to compete.


1 Prior, N. 2011. Speed, Rhythm, and Time-Space: Museums and Cities. Space and Culture

2 Gartner glossary. Bimodal. Gartner.com

3 Skeleton, M and Pais, M. 2019. Team Topologies. IT Revolution 

4 McGrath, M. 2000. Product Strategy for High Technology Companies. McGraw-Hill Companies

Previous article41. Jonas Thordal , Co-founder & CEO, Weld – How to leverage Professional Service to accelerate Product Sales!
Next articleDebunking Three ABM Myths (Or is ABM The Right Strategy for my Team?)
Petra Färm
With a Ph.D in electronic system design, I have climbed my way up the SW stack from firmware, operating systems, and virtual machines to applications and finally product management and business. I had almost all roles there in product; developer, product owner, product manager, architect, CTO... And in many industries. Been around, picked up a few things but still my learning curve is as steep as ever. There are many contributing factors to my learning curve; the exponential change of technology, the never-ending update in the way we work but foremost my job as one of the hosts of the world famous ProductBeats show (productbeats.com). In the show I get to meet and talk with product people cross the globe, with a great variety in perspectives, topics, challenges and solutions. Now its time for me to give some of that learning back and what better platform than SaaS Nordic where some of the hottest SaaS products hang out. My interest is anything product related which is rather broad. So from me you can expect product management frameworks, why product strategy is a thing of the past, all about nailing that positioning and maybe something about architects being the product manager's best friend?