Are You Lost In All The High Priorities?

As software product organisations grow, they can become the victims of their own sales success. Many high-priority customers and features put pressure on the engineering organisation to deliver, but even when using all the traditional ways to prioritise and optimise execution, you feel progress is slow and the overall “delightfulness” of your product is not what it should be.

The root cause is simple: as you grow in people and priorities, you have lost that focus you had naturally when the company was a small startup, but the commonly understood criteria for prioritisation and the execution capabilities of a more mature product organisation are not yet firmly established. The solution though, is not simple: on the top level, you know what the key priorities are, but then as you break down and distribute responsibilities, each part of the company seems to have a reasonable amount of work, and your organisation MUST now be big enough to execute on multiple things in parallel.

The Challenges

There are typically two key challenges in this situation. The first is that although the ownership of each priority is distributed, the delivery of the priority involves many parts of the organisation. This cross-team alignment typically involves the same people in each team and as they have been assigned different priorities, they will order their tasks differently. Still, everybody will try to satisfy other peoples’ needs, thus they will start up many tasks in parallel, and all priorities will slow down due to switching costs and that time is distributed across many tasks.

While the first can be seen in large, mature organisations as well, the second challenge is typically a startup/scale-up challenge: mature organisations have normally figured out their criteria for prioritising features and backlogs, how to groom the backlog efficiently, how to align dependencies across teams, basically, how to get things done through distributed mechanisms that don’t need escalations to management. In a less mature organisation, all these things are still being shaped. So, the organisation is typically less capable of executing many things in parallel.

You need to do something to ensure that the organisation increases total capacity through establishing the mechanisms that will work for you, your culture, your people, and your products. One approach that I have used successfully in both large and small organisation is what I call slicing, pacing, and themed releases. This is not a steady-state recommended scheme, but rather a mechanism to fast-track super-high priority product deliverables that are critical to your company. It can be used for a strategy pivot, building a new and different product type in a mature organisation, or to fast-track product-market fit in that critical phase where you know the high level, but need a fine-tuned product that really solves customer problems.

Slicing

The principle is pretty basic, but hard to execute on: define a very clear, very concrete priority that slices through all parts of your organisation; include at least one representative from sales, finance, sales engineering, support, UX/CX, product management, as well as from each of the engineering teams you need deliverables from. A related strategy is known as the “startup-in-a-startup” approach. However, if you isolate this new team as an internal startup, you get innovation, but you get no organisational learning in the wider organisation. This is where the first “slicing” happens: you create a slice through your organisation with hyper-focus on solving one and only one problem at the time, but you keep everybody in their respective organisations and with the mandate to shape the priorities of their home teams.

Make the on-boarding journey from signing-up to paying for our service into an interactive and delightful experience that drives conversion from today’s 1% to 5%.

Example of a charter for a slice

You should establish a “situation room” for the team, physically or virtually through a tool like Miro. This is where you have a visual representation of the concrete end-to-end problem to solve and where the team is responsible for continuously updating with plans and results as they go. It can be useful to have a concrete and representative customer used as a benchmark. The slice participants will each be responsible for working with their home teams to come up with ideas and solutions, and to bring back to the situation room the actual work done and show how it solves the defined end-to-end problem.

The end-to-end problem to solve should be finite, concrete, and need refining and iteration. The first task of the team should be to attack the assigned problem area and start breaking it down, and find out how they will attack the problem. Here, you will go different directions depending on how many engineering teams you need to rely on. If you are able to gather a group of full-time developers to work on the problem and you don’t have other dependencies, you can do agile sprints with at least bi-weekly demos to stakeholders (customer(s)!). If you have a more complex setup with multiple teams involved, you will need to introduce the second type of slicing and do pacing. This second type of slicing is done when you use the end-to-end problem and the situation room to agree to a set of common things to tackle across all the teams for the upcoming sprint. This way you make sure that the switching costs are low and that people work on the same things in the same order. If you have a back-end API team, this team should e.g. do a quick mock API to realise the proposed UX/UI, and then iterate together with the front-end team as they learn more about how to solve the problem.

Themed Release

If the problem you are solving is isolated from the rest of the products in your organisation, or it’s your entire product, you can quickly release functionality the way you are used to (and through devops and CI/CD for Software-as-a-Service products). However, if your slice is a part of a bigger product or platform where also other functionality will be released in parallel, you may be able to better scale the impact in your organisation and customer base through doing a themed release. Your slice is then equal to the release theme (to frame for other stakeholders what all this new functionality is solving), and you should release at regular intervals, not too often (as nobody will really pay attention), and not too far apart (to get the feeling of accomplishment and push towards a milestone in the team). 4-6 weeks can be a good choice as you can have 1-2 stakeholder demos and iterations to deliver something that has clear customer value.

Pacing

Finally to pacing: the more teams involved, and the more people involved, the more you will get drift in the project. Product engineers have a tendency to want to solve problems generically, so that it can be used by all customers. This is a good thing, but it introduces the risk that one team can spend a whole week on delivering something another team needs, when they could have done something simpler on Monday, unblock the other team, and then continue on making the feature more robust and generic the rest of the week. These opportunities for increased overall velocity can only be discovered across the teams. One way of doing pacing is to have pacing meetings that have a similar format to standups, but where the sole focus is to identify drift and focus on quick tasks that can unblock other teams.

If you haven’t done slicing, pacing, and themed releases before, you should probably start with only one. You will have most of your engineering resources already allocated to other priorities, so the “allocatable time” of your teams is probably far less than you want to think. Once the organisation understands how to execute on slicing and a themed release, you can evaluate running 2-3 such themed releases in parallel. Typically, over time the themed releases should be less and less an extraordinary effort, and more an approach to aligning product management, priorities, and engineering execution.