Why does product delivery slow down as a company gets bigger? (part 2)

Startups that were once nimble and fast-paced, and have now grown substantially in size (200+ employees), often ask why product development seems to have slowed down. People remember the startup days when they created and changed product, then shipped it, in a matter of days. Now, with more engineering resources than they ever dreamed of - they find it becoming more difficult and slower to ship - not easier. 

How and why does product delivery seem to slow down? Shouldn’t it speed up with more resources? This is the second in a set of posts that cover the most common reasons for this slowdown effect. Some of the common reasons for this apparent slow down include:

• The habit of consulting with everyone about everything
• Uncontrolled roadmap changes
• Weak product ownership
• Too many dependencies
• Lack of decision making authority (and willingness to use it)
• Not releasing the product often enough
• Lack of clarity on team outcome
• Not including time as a priority when developing solutions
• Too much technical debt
• Weak or absent project management skills

This list is put together by a combination of working with organisations first hand, and interviewing experienced hands in the industry who are working in environments that have these issues. It all comes from observation, not theory. Although the two should match :)

The good news is that larger organisations can regain their startup delivery speed with the right tactics and management. This post will look at the cost of making uncontrolled roadmap changes, and suggest a technique for managing this.

Too many (uncontrolled) roadmap changes

According to some, in an Agile world we should be able to make an unlimited number of roadmap changes at anytime and product development should proceed at full pace. In practice we see something different, and many long term advocates of Agile development will rail against unconstrained or uncontrolled change. It seems change is good and welcome, but we need to manage how it gets into the roadmap if we want to maintain speed.

Being able to accommodate frequent change is the essence of Agile development (and other iterative development approaches). Frequent change will happen whether or not we choose to respond to it. If we choose not to respond to it, we will become more and more out of touch with the environment we operate in. This is (in part) what has made waterfall style development unattractive. It makes change difficult and reduces the connection between the development process and the real world.

So absorbing change frequently seems to be better, but how frequently?

Imagine an engineering team absorbing a change every time it appeared. Remember a creative product team will think of at least 3 changes a week :) In attempting to absorb this, they would be locked into a continuous cycle of replanning, redesigning, recalculating dependencies, re-allocating work within the team, redoing prior work, re-communicating with other parties etc… Time that was being spent coding is diverted away from a stable goal to these other activities that are necessary to absorb change. The team loses a clear and stable sense of the product goals, efficiency drops, and then throughput drops.

So the question seems to be:

What is the best way to control how a roadmap changes?

What tactics could we use that allows product and engineering teams to be receptive to change, while avoiding the wasted energy of having too much change arrive all at once?

or

What tactics could we use that allow product (management) teams to inject regular change into the development effort without triggering inefficiencies?

One answer: Roadmaps divided into time horizons, where each horizon has different rules for the changes it will absorb, and makes different promises to stakeholders.

Roadmap Time Horizons

This approach divides a roadmap into 3 time horizons. You could divide it into more, 4 also being common, but 3 is the most common. This technique works for many environments, and is worth exploring if you don’t use it already.

The first time horizon - H1

Is defined as (say) the first 90 days from a planning start date - and represents what the team has committed to deliver. It is “locked in”. Stakeholders can feel confident this part of the roadmap will be delivered, and they can talk about it with confidence. It is the most detailed part of the roadmap, and has the least uncertainty associated with it. In exchange for the commitment to deliver the material in this time horizon, the team receives a reciprocal commitment from the product manager (and stakeholders) to not to change things in this window. The exact size of this time horizon can vary from organisation to organisation. It could be as short as 30 days. It could be 120. Make it too big, and you have something that feels like waterfall development. Make it too small, and you don't get the stability you need. 30-90 days seems a popular range.

The important thing is the implied contract between the engineering team (they will deliver the things defined in the immediate future) and the stakeholders (they will not change things in the immediate future). This first horizon is the most stable and unchanging part of the roadmap, and lets the engineering work proceed with confidence knowing its course is stable and predictable - at least until the next (second) time horizon is reached.

The second time horizon - H2

Is defined as the period 90 to 180 days from the planning start date, is an educated opinion on what the team will need to be working on over this stretch of time. It is “what will probably happen” instead of the “what will happen” of the first time horizon. This part of the roadmap absorbs small to moderate changes. Large changes will arrive from time to time, although they should be fewer in number than small to medium changes. The second time horizon accommodates all these changes - from the many small to few large changes.

As changes arrive in this part of the roadmap, dependencies between product components are recalculated, additional relationships the team might need are built, skills gaps are identified and addressed, rework estimated and planned. All of the preliminary work to make sense of a change, to understand its significance and impact, are factored into the roadmap at this point. Importantly, taking on these changes does not disrupt what engineering is working on right now - as engineering is focussed on the first horizon. Stakeholders can use this part of the roadmap (H2) to have conversations on a “we will probably do this - but it is not yet locked in” basis. This is enough to convey intent and direction to internal stakeholders, and most times, to customers and partners.

The third time horizon - H3

Defined as 180+ days is about sending a signal where the product is heading long term. It is an (educated) estimate of what business outcomes the product will be focussed on addressing in the more distant future. This view will include projections of core functionality, and ideas on entirely new product perspectives. This might be significant new functionality or it may be connections to new business partners and IT services. It might include the introduction of new technology, or the conversion of existing capability to a new technology platform. Depending on how far a business wishes to speculate on its future product directions, this time horizon can extend out to 1 year, 2 years or 3 - with 18 months being the most common.

Summary

So we have 3 time horizons that can be summarised as:

• Horizon 1 - What is locked in, a stable and predictable work plan
• Horizon 2 - What will probably be done, but there might be some changes
• Horizon 3 - A longer term vision or statement of intent, subject to significant change.

This provides:

1. Short term stability for engineering, as they can focus on H1 execution (while being aware of H2 and H3) - and they can trust that H1 will not change unexpectedly.
2. Medium and long term opportunities for changing product direction, so product management knows where it can inject different types of change
3. A way to communicate the roadmap that captures the likelihood of change. Helping stakeholders appreciate the different levels of certainty that exist over time.
4. A way to communicate product direction that captures the far sightedness of product management while also providing stability to engineering

In a single picture

What this means for certainty

The word ‘certainty’ here refers to how stable the goals are as given to the engineering team for building. As noted above, if we can carve out a little certainty for the engineering effort, we can avoid some of the costs and efficiency drags of taking on changes. The graph below shows how the degree of certainty we strive for changes between the horizons.

What this means for absorbing change

Not surprisingly, the degree of certainty and the ability to absorb change have an inverse relationship. Some people prefer to visualise the relationship between the horizons in terms of how much change they can/do absorb. The graph below shows this relationship.

What this means for engineering

They can focus on executing H1 with the confidence it will not be changed. After completing Horizon-1, an engineering team might be required to change direction - in keeping with the spirit of Agile development. The early Horizon-2 roadmap (which becomes the new Horizon-1) will have taken onboard changes in the product direction. This satisfies the product management need to be flexible (agile) in deciding where the product should go, while giving engineering stability. It’s a balance.

What this means for product managers

This means that changes in a product direction have a defined place on the roadmap where they should go (Horizon-2 or Horizon-3). If it is a small to moderate change that finds itself early in Horizon-2, it will be a predictable number of weeks before it comes into view of the engineering team, and usually not too far into the future. Larger changes that have a greater impact on dependencies might be inserted further into Horizon-2 - meaning it takes more time for it to arrive at engineering’s doorstep, but this is something that product management manages routinely (scheduling). The difference with the H1/H2/H3 approach is that everyone can understand the scheme that is being used to organise change.

Wrapping up

This idea of using time horizons is neither new or surprising. It is about managing how an engineering effort absorbs change. And it is about how product management organises change. Horizons help with balancing the need to be responsive without compromising the sense of stable product direction for engineers. It can buffer the changes that an engineering team experiences without locking out changes that arise as product management connects with the market. It can provide product management with a defined and structured way to feed change into engineering - and for communicating product direction to engineering.

Combined, these things can increase the throughput of product and engineering teams, and help them move at "start-up speed" like they used to.