Let’s fund (specialist) teams, not products

Felix Tomlinson
Nov 22, 2017 · 4 min read

GDS’s picture of products progression has come in for some criticism. The argument against it goes something like this. These processes encourage a way of thinking which says that all products have essentially the same lifecycle. A single product must flow through these stages and follow the same progress. It is a linear picture where a single thing passes through a set number of phases and then is done.

Image for post
Image for post
A product from start to finish in GDS’s digital service standards

In this characterisation the new agile world is not radically different from the old ways of doing things. It becomes more of a cosmetic than a fundamental change.

In government this way of thinking is often compounded. This is in part by having to deal with political priorities and commitments. There is also sometimes an attitude where, in a world of severely restricted resources, digital leaders are reluctant to spend money on something that they are not pretty sure is going to happen.

This means that discoveries often have a slightly artificed quality. ‘We’re going on a user need hunt. We’re going to catch a big one!’ Then lo and behold a few user needs are ‘discovered’ and the product is built.

This is not just a problem of leadership, but also one exacerbated by psychology. We have teams, many of whose members will have followed products through alpha and beta. They don’t want their products to go the way of the dodo.

A major reason this problem come about because at the moment we have a single type of team. That team can have more or less members. It can be operating more or less autonomously. Yet fundamentally teams exist in the same structure, often with the same personnel, in their early stages as they do going into live.

What would happen if we created more than one type of team and broke our digital structures into these distinct groups?

  • a group that solely looks at discoveries,
  • a group that turns those discoveries into prototypes,
  • a group that builds on the successful prototypes,
  • a group that maintains live products.

The solution isn’t dissolving the structure, but building teams that specialise in delivering the outcomes of each phase. We turn the process of building products into a ‘pull’ system, with each team empowered to recommend their product be closed or continued.

This would not stop teams from killing their product at any point in the journey, rather it would provide specific moments where ideas can be looked at again with fresh eyes. At the end of each stage work could be reprioritised and reevaluated.

This could happen once a month, where all the products in a specific phases are subject to a prioritisation process. Whatever is going to deliver the most value to users could be kept and everything else dropped.

There would be no team whose future depended on any specific product. There would be a freedom to keep good teams together within each group and to bring in only the best from previous ones.

It would introduce a structure whereby ideas were not expected to move seamlessly from Discovery to Live. Quite the opposite: the majority of ideas could and would be expected to fall by the wayside.

This removes one of the major barriers to successful agile products: emotional investment. People are psychologically attached to something they have worked on for a long time and are thus unwilling to kill it.

Obviously this would mean that some domain knowledge is lost. If teams work through from alphas into betas they will pick up more information about the area than starting afresh in beta. But having teams looking at things with fresh eyes can also be helpful. Furthermore there will always be a need to overlap and collaborate between groups and teams.

Image for post
Image for post
A project from start to finish in ‘PRINCE2’

This might seem like a rigid thing to do. I’m certain the first comment I get on this will be a comparison to PRINCE2 or waterfall methods. There are similarities, but the key difference is that waterfall projects tend to be 1-to-1. One idea to one product. A death march from idea to delivery so long that by the time it arrives the user need has simply disappeared.

This approach keeps agile methods and workflow. It keeps user interaction, constant iteration and crucially the ability to dump ideas that are not going to deliver user value. It is a way of giving due importance to the Discovery and Alpha phases rather than destroying the good practices that are currently happening in Betas.

We introduce an element of rigidity into our workflows all the time to increase efficiency. This is no less rigid that dividing your work into quarters of the financial year. Or splitting work up by existing institutional structures.

One of the excellent things about this is in the civil service we would have the scale to test. A brave senior manager could run their traditional operation alongside one which was structured in this way. Then we could see which part of the organisation delivers more value to users.

If we believe that the best products come from continual iteration and experimentation, then we should apply that thinking to the processes themselves.


Apply4 Technology makes licensing easier for everyone

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store