4 tips for Product Owners on a backend product

1. Build a common language

A shared understanding of a subject or issue is critical to enabling any product team to make informed decisions. One of the most effective ways of quickly building a shared understanding is to use visuals.

For user-facing products, discussions can be contextualised using screenshots or prototypes, such that both technical and non-technical stakeholders have a shared visual understanding. In the absence of these artefacts, sketching out how the different components of the product interact together as a series of lines and boxes on a whiteboard or scrap of paper can quickly bring team members on to the same page and ensure that everyone is talking about the same thing.

Most importantly, you don’t have to produce a perfect, entirely accurate representation of the product. Providing a starting point for discussion and a common language for both business and technical stakeholders to converge around enables the team to consider all aspects to find the best solution.

2. Work out how to deliver value early and incrementally

In an Agile environment, our aim is to deliver value frequently and incrementally. This is not always as straightforward as it may seem, particularly when we are dependent on external services in order to deliver.

User-facing products are frequently dependent on the delivery of external services. Backend products are often faced with the double-edged sword of being a dependency for a related front-end product, whilst also being dependent on other external services.

Finding a way to navigate this highly interdependent environment in order to deliver value early and incrementally is crucial. The design of backend infrastructure is essential to minimising and mitigating these dependencies, and whilst technical team members are generally responsible for architecture decisions, it’s important as a product owner to understand the implications of the chosen architecture. Spotify has provided interesting insights into how it designs its backend infrastructure to minimise dependencies.

Delivering “value” doesn’t always have to mean delivering production software. It could mean resolving downstream dependencies early to enable other teams to work more efficiently. One way to achieve this is to build a mocked interface to enable external services to integrate, whilst building out the actual service behind the scenes.

3. Know your user (or know the people who do)

In order to make the best decisions for our products, we need to consider the desired outcomes of both the business and our users.

It's generally straightforward to imagine how a user will interact with a product that has a direct user interface. We research our users’ behaviour, understand their environment, and we design and build our products accordingly to enable them to achieve their desired outcomes.

It's just as fundamentally important to consider the end user when making product decisions about a backend system, although often less straightforward. If your product has a user interface, connect with the team building it. Collaborate to understand the user’s needs and drivers, and refine a set of principles that you can adapt to guide your decision-making process.

Is the user’s priority speed, security or something else? Is there any heavy-lifting the backend can do to improve the user’s experience on the front-end? Having a solid understanding of your user will enable better, more holistic product decisions.

4. Trust your team

As a product owner, it can sometimes be tempting to delve into the low-level detail of everything your team is building, whether out of interest or a desire for control. However, it is crucial that product owner's are able to take a step back from the detail, zoom out and consider the product from a wider perspective.

Rather than trying to know every last detail of the technical implementation of the product, ensure your team is aligned with the product vision. Give them the autonomy to make the technical decisions and trust that they'll make the best decisions with the context you've provided. I consider my responsibility as the product owner not to know all the answers, but to ask the right questions of my team such that I am able to assess risk and make the most informed decisions.

One way to keep the team aligned with the vision in practice is through writing good user stories. As for a user-facing product, user stories should be able to be understood by both non-technical and technical stakeholders. It's important to keep stories focussed on behaviour and user outcomes, and keep technical detail out of the story. Mike Cohn has some tips on writing user stories for backend systems.

Being a backend product owner is not as scary as it may initially seem, as the skills required are the same as those you have learned working with user-facing products. Once you understand your stakeholders, the value you're aiming to deliver, your user and your product vision, you'll be well positioned to build a great backend product.