Can Product Squads Improve Your Agile Development Process?

Squads are a relatively new methodology for product development popularized by Spotify. Actually, popularized might be too strong a term for it. Since 2012, when Spotify restructured its development organization into functional, eight-person squads — developers and a product owner — much has been written about this novel approach. But it seems few organizations have actually adopted it.

There are several legitimate reasons why a product squad structure might not make sense for your organization. I’ll discuss those below, along with the reasons it might indeed be a way to improve your product development.

But first, let’s take a step back to discuss how we got here. How and why has the process of product management and development evolved?

From Waterfall to Agile to Squads (or Maybe Not)

Waterfall is a very linear approach to creating products. Much of the work is done upfront, with product managers working in a clear sequence of steps. First, they plan, design and document essentially everything they can think of with regard to what will be needed for their product’s development. When that is complete, they hand off this documentation to their developers for execution.

And although it is still popular in some larger software organizations — primarily because it allows for strict deadlines and managerial controls — waterfall has several drawbacks.

In many software organizations, waterfall product development has given way to agile.

The agile development methodology emphasizes people over processes, and communication and testing over documentation. As the agile thinking goes, let’s be collaborative and quick. And let’s let the market itself tell us whether or not we’re succeeding — rather than simply deciding we’ve executed successfully because we faithfully stayed on track with our product roadmap.

That’s where the concept of product squads comes in.

In a way, Spotify’s squad approach is the next logical step in further streamlining the agile method.

The way Spotify has set them up, each of these squads consists of a small team of developers and one product owner — usually, but not necessarily, a product manager. What makes these squads unique? A few things.

First, squads are responsible for functional areas of the company’s product line; they do not work across entire products or on ad hoc projects assigned by management. For example, one squad might focus on exclusively search technology. This allows the company to develop significant expertise and intellectual capital across each functional area of its offering. In other words, it can build teams of true industry experts, rather than a single large team of coding generalists.

Photo Credit: Spotify

The second way squads deviate from traditional product development approaches is that they are given real autonomy. In fact, Spotify thinks of its squads as independent startups.

What does that mean in practical terms? It means that a squad can select its own areas of functional responsibility to work on. Once it has taken on such an area — again, search technology, for example — it can update the production version of its product anytime. It can push work out to users without waiting for approvals from anyone outside the squad.

So the basic idea is that product squads can lead to much more efficient product development, teams who are highly knowledgeable about the product’s various functional areas, faster development cycles, and ultimately more successful products.

Is the product squad approach right for your organization? It depends. There are benefits and drawbacks, and it isn’t a clear fit for every organizational culture. Keep reading to get an understanding of whether or not it could work for you.

Two Reasons the Squad Method Might Improve Your Product Development

1. It can generate true in-house expertise.

The product owner in a squad has a much greater ability to learn about his functional area than he would if he were responsible for an entire product. Sticking with search as our example, a product owner at Spotify can become an unrivaled expert on the technology — how search can be used to improve the overall user experience, best practices, and all of the latest industry improvements.

If that product owner were responsible for the entire product, however, he would only be able to spend so much time on search — or anything else for that matter. He would also have equal responsibility for learning about partner channels, pricing models, securing music contracts, researching the latest developments on UX, and on and on.

By assigning squads to complementary areas of functional responsibility across your product line, you can allow for tremendous knowledge among both your product owners and developers. In fact, this can be a key differentiator for your company, because your competitors will likely still be developing in the everyone-works-on-everything model.

2. It can speed everything: development, feedback and learning, and updates.

Because squads are permanent, small teams, its members get to know each other well, developing a chemistry and a team shorthand that can speed the work.

Also, because the squad has the authority to release its product updates directly to the market anytime it wants, it can more quickly learn what’s working and what isn’t. It can then autonomously make improvements and push right back out to its user base.

The squad approach can in some cases be a perfect addition to an agile environment because it supports one of the most important agile principles:

“Working software is the primary measure of progress.”

The more quickly your squads are able to update the product and push those updates to market, the more quickly they’ll be able to determine if they’re working or how they can be further improved. Ultimately, that will generally lead to a more successful product.

Three Reasons the Squad Method Might Undermine Your Product Development

But your organization might, for several reasons, not benefit from adopting the squad approach. In fact, for many types of companies this method can even harm your development efforts. Here’s how.

1. Your product line might not support this model.

Remember, the product squad approach was developed, or at least popularized, by Spotify — a SaaS company. They obviously coded their product in a framework that allows for tinkering and tweaking here and there without negatively affecting any other parts of the product.

Because their code is segmented to such an extent that they can modify the radio functionality without touching their search code, for example, the squad method of autonomous team updates makes perfect sense for Spotify.

What if you sell multiple interrelated products and services, and they were constructed such that an update to one area of a product might affect everything else?

You probably wouldn’t want to restructure your development and product management organizations into squads, because you couldn’t give those small groups the autonomy to update the live products. Otherwise their updates could jeopardize the stability of the rest of the product.

Additionally, if your product has many components with interdependencies, you would often have instances where one squad had to wait for support from another squad. And this would remove much of the value of operating under a squad model in the first place.

2. You risk breaking your in-house product knowledge into silos.

In an agile context, a product manager’s primary role is to educate the developers on the product’s personas and the problems the product should solve for those personas. In other words, product managers should have a comprehensive understanding of the product as a whole.

But if you break your resources into squads responsible for functional areas, you are in effect dicing up the overall, strategic-level product knowledge across several product owners. Although they might become unrivaled experts in their functional areas, these product owners likely won’t have a full strategic understanding of the entire product. That’s risky.

Additionally, by making your developers hyper-specialists in a few functional areas, without also allowing them to work at times on other projects, you risk isolating your company’s coding talent from the big-picture view of the product?

So if your squads don’t interconnect well and often, then you run the risk of information silos. Who at your organization will have full product knowledge? Which product managers? Which developers? Will any of them?

3. You could lose some of the advocacy from both product management and development.

A third reason squads might not work is that a product’s success often depends on maintaining some distance and objectivity between product management and development. The product owner should be focusing on product vision, strategy, the what. They should then be communicating this to development, who should focus on the how.

So it’s not necessarily a bad approach to have a little tension between product management and development. Product managers should be looking to push boundaries, try new things, and implement themes that might not be so easy for development.

Developers will be motivated to complete the challenges put before them as efficiently and quickly as possible. But the product manager will at times have strategic reasons for wanting to execute on an initiative in a given way — one that might be at odds with the development team’s way of thinking.

But if the product manager is on the same team as the developers, you run the risk that she won’t ask for X because she knows that within her team’s functional area of responsibility, the framework will make it easier to implement Y instead.

Think of the embedded-journalist problem. When war correspondents embed themselves with a military detachment and go out on missions under their protection, you can imagine how difficult it can be for those journalists to then report the facts objectively, particularly if their report would portray the military team unfavorably.

The same potential problem exists with embedding a product manager on a development team.

The product will likely enjoy more success when both product managers and developers are advocating strongly in favor of what they see as best for the product — even if doing so creates a bit of tension between both teams.

Product Squads: Interesting Approach to Product Development, But Not Right for Everyone

Product squads seem to be a great way to build strong, knowledgeable development teams.

They also offer perhaps the best development framework yet to allow companies to quickly and efficiently build and release products, and then improve upon them based on how their markets react.

Moreover, they seem to be a logical extension of the agile philosophy. Indeed, one of the more important agile principles is: “The best architectures, requirements, and designs emerge from self-organizing teams.”

And remember, agile development itself is all about doing what works best rather than adhering to any process or development rule.

If the product squad approach sounds like a fit for your organization, it might be worth a try.

But if you’re not sure to what degree your product can handle independent updates at various times, or you worry about sacrificing overall product knowledge to build up your organization’s functional expertise, then you might want to investigate the squad method more deeply first. Implementing the wrong product development strategy can create more problems than it solves.

Post Comments

One Comment

Great article. For sure the software architecture allowing great decoupling and independence over components is essencial, I think that’s the cat’s jump Spotify didn’t talk about.

Also, I don’t believe they’d release a new build every day and another. Users won’t be happy to have to download new updates so often. Might they have a group of senior testers that keep testing the RC product and deciding when to baseline a new version and release it to public?