Product managers come in many guises in organizations — sometimes called the voice of the customer, or organizational cat-herder — they are a thick-skinned bunch who withstand all the politics and excuses to deliver product. Rarely heroes to anyone, good product managers are behind most of the technology solutions you have ever enjoyed.

PMs are always looking for better tools to get things done. We know the competition is snapping at our heels, our customers are tired of waiting, and we constantly need to be faster, smarter and more efficient. When serverless came along, it wasn’t immediately obvious how it would fit into the product management catalog of toys, but after using it for over a year, I can see it solves some of the software problems that have always been with us.

The paradox of team size and work done

The First Rule of Product Management is that the amount of work needed to be done always grows — your product backlog always gets larger, and the only time it goes to zero is when your product is scrapped. The challenge is how to turn the most important parts of the backlog into shippable product. All things being equal, we would expect this to be true:

If one human can shovel 1 ton of dirt a day, then 10 humans can shovel 10 tons. Much resource management in companies is based around this — if you need more sales, hire more sales people. In software, as our backlog grows, the temptation is to expand the team but in complex products and services, over time you tend to see more of this:

It’s rare to see enormous teams make rapid progress, yet it’s more common to see smaller teams make staggering leaps on a continuous basis.

We often err in startups by adding more developers, managers and PMs as a product becomes successful, only to find we unexpectedly slide backwards in velocity. Why? Is it the brilliance of the early developers, or the bureaucracy of the company, or the foresight of the architecture?

I think those are symptoms rather than causes of the underlying problems, which come down to the interplay of three critical factors, only two of which you can directly control:

Fragility — the impact of new changes. If a new feature affects only one part of the machine, it’s easy to test and implement; if it affects all parts of the machine, testing becomes more critical and difficult, and implementation takes an order of magnitude longer.

— the impact of new changes. If a new feature affects only one part of the machine, it’s easy to test and implement; if it affects all parts of the machine, testing becomes more critical and difficult, and implementation takes an order of magnitude longer. Work size — the minimum unit of work that can be achieved by a team and be considered a productive feature. “Pay with Alexa”, for example, not “Meet to discuss when to implement Pay with Alexa”.

— the minimum unit of work that can be achieved by a team and be considered a productive feature. “Pay with Alexa”, for example, not “Meet to discuss when to implement Pay with Alexa”. Complexity — how much knowledge is needed to implement a feature. Can a developer who knows how to write a feature independently do the same in the organization? What extra steps need to happen that silently slow progress without adding any customer value to the output?

What’s fascinating to me is that startups begin with the optimal weighting in these three factors — nothing is fragile, work size tends to be small and understandable to a customer, and complexity is non-existent. If the team needs to make a website GDPR-compliant, for example, they can research the problem and implement a solution quickly and be very confident it will work as expected.

For larger companies, these factors combine to increase the team size, minimize the work size, and reduce the work done. For GDPR, you need legal sign-off, marketing approval, C-level awareness, A/B testing on the least disruptive implementation, a scheduling window with operations, check with any other team deployments on the website, the list goes on and on. Even with plenty of controls and processes, the team is much less confident about the impact, thanks to the fragility of unknowns in the environment.

When you expand the example to a real project that may contain dozens of features and hundreds of changes, it’s not hard to see how the interplay of these factors conspire to turn the team-size/work-done dynamic from the first graph to the second. You are forever condemned to achieve less work as the team size grows, regardless of how you coax the organizational machine. Or so it seems — but what can you do?

Hacking the three factors

I became obsessed with this problem for many years, and it led me to investigate many possible causes. Is rapid progress only possible in startups? For a while I thought so when I experienced the difficulties of managing products through larger organizations. But then I zoomed into the three factors much more closely.

Fragility is always working against you — it’s the ever-growing technical debt in every project of every size. Like an inverse half-life, every piece of software grows progressively more fragile with time and development, and it gets worse with every line of code added.

Work size is not related to the actual product feature (“Pay with Alexa”) but rather the difference to the shape of the infrastructure when you compare the ‘before’ and ‘after’ states. As the ‘after’ states become more complex, the work size shrinks. This is why in so many companies the work size evolves from customer-focused (“Pay with Alexa”) to organizational (“Meet to discuss who should be involved with Pay with Alexa”).

Complexity is a combination of social, organization and technical factors that directly affects developer on-boarding time, the ability to treat developers as fungible assets who can perform any work, and it’s the least likely part to ever become visible, documented or well understood. A developer can code and release a React application at home but there will be dozens of extra steps in any organization that slow her down with no apparent change to the customer feature. These steps will eventually absorb most of her working day.

These three play together in a vicious cycle, so work size shrinks as fragility grows, which contributes less and less to feature output, and complexity becomes an invisible sludge around your product. Consequently, adding more people doesn’t help, and you can only increase velocity by cheating on how you point-score elements of work (a classic tell-tale sign: meetings start to appear in sprint stories).

There are a couple of flawed approaches I’ve seen in larger companies that try to defeat this cycle. The first is Scaled Agile, which creates vast meetings of everybody impacted by proposed features and attempts to coordinate the work by understanding the complexity. It’s a boon for catering companies providing truly epic lunches but tends to fail because the headline projects get smaller and more numerous as the scaled group grows in size, and it doesn’t fundamentally solve the fragility and complexity issues. Over time, scaled agile delivers a tactical shopping list of tasks rather than a holistic journey across meaningful features.

Second, internal “innovation groups” are often an attempt to spur changes at the periphery in the hopes that the fragile machine will absorb the work to make changes happen. This well-intentioned idea has the bizarre side-effect of cementing the notion that only the innovation groups can change anything, and the approach fails to address the problems of organizational complexity.

After seeing many failures over the years, I’m convinced you have to hack the three factors to overcome their combined effect on work done and inertia:

Fragility must not increase with subsequent versions or aging.

Work size must not be smaller than a meaningful customer feature.

Complexity must not impact the work of a single developer.

If you can embrace these ideas, you can escape the fate of every software product in the history of mankind. It sounds great but how is it possible?

Serverless breaks the constraints

The emergence of cloud technologies made important in-roads to achieving the new ‘hacked’ state. In general, the software delivery lifecycle collapsed with cloud, because so many mundane things were done for you. Before cloud, to deliver a new customer feature you had to order servers, rack and stack hardware, arrange for networking at the data center, and then maintain aging equipment over time. With cloud, you could rent all this and cut out dozens of organizational steps and months of time.

Additionally, by removing the need for in-place upgrades and allowing access to hardware on demand, fragility and complexity were reduced. It become easy to spin-up software compared to the old world. However, over time there was a growing administrative burden from managing much more virtual infrastructure and many of the old delivery practices remained unchanged. After adopting cloud, you could reach a larger team size before the work done slowed, but it still slowed nonetheless.

Serverless changes this dynamic profoundly. Serverless apps are a combination of short pieces code written by your team (the glue), and black boxes of functionality managed by the cloud provider which only accept configuration and react to events. In a well-architected app, the generic black boxes are the substantial parts of the operational burden that comprise the app’s work. The app itself is no longer a monolithic function but a federation of functions and boxes.

In practical terms this has a dramatic effect on the three factors I named above:

Fragility is reduced thanks to zero infrastructure management and loose coupling. In our projects, we have seen our code base shrink, up to 10 times smaller in some cases.

Work size tends to hover around feature size because it’s trivial to create new function versions or entirely new functions that weren’t needed before.

Complexity doesn’t impact the developer — if she can write a function that handles a credit card payment, it will be almost the same code in a serverless app without organizational wrappers and environmental factors slowing down the work.

Even in very large serverless apps, for a product manager it’s simple to zoom into features and see the few parts affected when changes are made. It’s also easy to run both versions concurrently with feature flags, and usually there is no need to ever retire old versions of the code.

With serverless, we are always building at the periphery of the infrastructure, writing the smallest amount of code possible, connecting fully-managed services that we never need to think about from an operational perspective. We are not attempting to manage a monolith, tidy up old code or gain a world-view of the entire system.

Why this matters profoundly

As the rate of change increases, predicting the future state of software or the future needs of your customers becomes much more difficult. This means building foundational code that will always work for some future state is often a fruitless exercise. We’ve seen how little code reuse really happens in most companies, and how commitment to aging platforms stymies progress.

The traditional pattern is that an old system is maintained and developed as far as possible, until maintenance consumes almost all development effort, and the company eventually starts afresh with a new system heralded not to repeat the failures of the old. When the new system is eventually strangled by the three factors, the technological forest fire comes and we start over again.

Our obsession with the symptoms of systems complexity explains why so many paradigms come and go without making any significant dent in product management. Serverless allows product teams to minimize the complexity added and continue delivering value at a fairly constant rate without falling into the classic traps that have plagued software for decades.

This is an early time in serverless but the initial signs are extremely promising. At a time when customer demand for features has never been greater, product managers might finally have a development platform that allows a feature-driven mentality that does not slow with organizational complexity nor get paralyzed by fragility.