PRODUCTHEAD: Setting up a product support team

permanent product #

---

tl;dr

Work continues after the project ends — plan for the ongoing support of your product

A support team deals with user queries, incidents and ongoing improvement of the product

Great user support is an expectation, not a nice-to-have

Feedback from user support can identify areas of product improvement

---

a favour: please share this with other product people

every PRODUCTHEAD edition is online for you to refer back to

hello

Different organisations can be more adept at different stages of a product’s lifecycle than others. Usually teams end up with more hands-on experience of the main body of the lifecycle — maintaining and supporting products in-life — rather than creating new products from scratch or retiring them.

This is understandable: unless you’re like Google and create and kill off products with frightening regularity, you spend proportionally much more time in a product’s ‘in-life’ stage. Some product managers can be a few years into their career before they come across the chance to experience a proper product discovery or decommissioning.

Help users however we can #

My first job out of university was to join Zeus Technology, a technology startup based in Cambridge, UK. We sold high performance building blocks for the emerging internet economy: web servers and load balancers. I started on the tech support team.

On day one, I was handed a pile of books on the key technologies our products worked with, and was set loose on the simplest customer queries. We were a team of three and almost everything came in over email. We’d answer as many questions as we could ourselves, and occasionally we’d have to bother a friendly developer to check a weird edge case in the product code.

Our philosophy was to help users however we could, whether they were paying or or on a free trial. Our products were surprisingly robust, so it was actually rare for the product itself to be at fault. So we’d often find ourselves diagnosing and fixing problems beyond our products, sometimes in the operating system or in the apps they were running on top of our products.

In most cases, the cause of the user’s problem lay in conceptual misunderstanding or product misconfiguration, so we’d try to leave users more knowledgeable than when they came to us.

When you’re optimised for new product creation #

Fast-forward 15 years and I join a newly-created digital services team at the UK’s Ministry of Justice (MOJ Digital) as head of product. They had several multidisciplinary squads working in parallel. They were great at product discovery, creating something of value and getting it in front of users. But they were initially at a loss when it came to supporting a product in-life.

There’s no judgement here — it’s perfectly reasonable to be better at the things you’ve had more chances to practice. But through the lens of my own experience up until that point, I thought it a bit topsy-turvy.

Challenges of establishing a support team #

The challenges they were wrestling with were:

We have more products than squads, so who looks after a product once it’s gone live but isn’t being actively developed further for now?

Who responds to support requests from users of a live product that’s not being actively developed?

How do we resolve the conflict between ramping down a squad that’s completed its active development of a product, and still being able to make smaller improvements to the product in-life?

How do we (and should we) move responsibility for a product between different squads?

How do we plan and budget for continuous improvement of our products throughout their lifetimes?

What would a team dedicated to improving existing products look like in terms of size and skill sets?

Never-ending products? Gulp #

For those of you reading these questions and saying to yourself, that’s what a helpdesk / support team is for, you’d be absolutely right. It’s just that, at that point in time, no central support team existed yet.

MOJ Digital’s funding came from the various federated organisations that collectively make up the Ministry of Justice. At the time, funding was still broadly closed-ended and project-based, rather than the reality of funding the creation of a product with ongoing operational costs. The tricky question of how much each would contribute towards the creation of a centralised support team had not yet been negotiated.

A blog article at the time by former CTO at MOJ Digital Dave Rogers casts some light on the possible answers:

When we write a business case, we encourage a long-term funding plan which includes estimates for the 3 activities (user contact, incident response and tuning, and iteration). We combine these with the cloud hosting costs to show the long-term cost of sustaining a service.

When it comes to planning, we don’t allow a product team to move onto another project until there’s a sustainable solution for each activity. This is a crucial part of our ‘definition of done’ for that team, though of course the product itself will never be completely done and dusted.

Finally, we’re changing the way we organise our teams. We now encourage our technical professionals to move between iteration and incident response so they can experience both sides of sustaining services: making the services, and keeping them alive.

An engineer responding to incidents on new, less stable services will have an understanding of the compromises made to ensure rapid delivery. An engineer repairing a service is learning how to avoid the situation in the next service they build.

We’re still learning how to make this model work, but it’s already helping us to start solve some complex organisational, planning, and funding challenges.

“Making digital services that last”, Dave Rogers, MOJ Digital blog (13 August 2015, retrieved 15 October 2022)

Core to the success of this approach was the shift in the organisational mindset from closed-ended product delivery projects that ‘finished’ (implying no further work, staff or funding needed), to products that have a lifespan during which the organisation remains responsible to maintain and improve the product.

Final thoughts #

Ongoing funding of products can be a tricky pill to swallow for organisations stuck in a project mindset. It is difficult to predict for most products how long they’ll live, so it can be uncomfortable for an organisation to write what they feel is a blank cheque to keep funding something indefinitely. However, if this ongoing support cost is at least anticipated while discovering the product’s business model, then you can make a more informed decision whether solving a particular problem for people will be financially sustainable.

The thinking about how you support the users of your product has certainly evolved since I started my career on the tech support desk at Zeus Technology. However, I think this fundamental principle remains: always believe that the user is experiencing a genuine problem, regardless of whether it’s a product bug or simply their misunderstanding, and help them to solve the problem, even if that goes a bit beyond your organisation’s products.

Speak to you soon,

Jock

---

---

what to think about this week

Making digital services that last

We’re responsible for a wide range of services and don’t always have the luxury of having dedicated delivery teams for every project. We have to shift our focus from service to service as new ones come along, without losing sight of what we’ve already created.

Sustaining a product for its lifetime

[Dave Rogers / MOJ Digital]

Running your service in a sustainable way

Your service should be backed by a plan and budget that allows for continuous large and small improvements throughout its lifetime.

Going beyond essential maintenance

[Government Digital Service]

---

---

7 tried and tested tips for building a customer support team

Customer service and support impact everything from marketing to customer acquisition and retention to profit. Therefore, it’s worthwhile spending the time to build an excellent customer service support team.

Understand your customers’ needs

[Emily Heaslip / Vervoe]

Set up and manage user support

User support is important because it can:

• help you improve your service in line with user feedback
• allow for continuous improvement
• act as ‘eyes and ears’ to tell you what’s really going on with your service

Not only about reacting to problems

[Government Digital Service]

recent posts

Billion-dollar platforms — how they did it

I was asked recently whether platforms will conquer the world. My view? They already have. In this article I share how they’ve done it, and how you can successfully bring your own platform to market.

The ingredients for success

[I Manage Products]

An exercise in stakeholder alignment

When your stakeholders each have their own interpretations of the product strategy, this lack of stakeholder alignment will cause you no end of problems. Here’s what you can do about it.

A practical exercise you can run

[I Manage Products]

The 4 unintended side-effects of risk aversion and what to do about them

When we become more worried about risk, four unintended things also tend to happen: bottlenecking, erosion of trust, ossification of process, and a risk appetite that tends towards zero. Here’s what you can do about them.

It’s all about the safety net

[I Manage Products]

PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from ubiquitous Billy bookcases.