Being a Product Owner (PO) on an exclusively backend product can be a scary prospect. Coming from a non-technical background, when I first joined a backend product team, the technical jargon and acronyms were overwhelming. I also found it difficult to visualise what we were building, as there was no user-facing “app”, screenshots or prototypes to familiarise myself with.
I realised that if things weren’t clear to me, then how would the business value be clear to non-technical stakeholders and key decision makers?
Additionally, I was considering how to get technical & non-technical team members and stakeholders to speak the same language. How were we going to deliver value incrementally within the constraints of such a complex system? If there’s no direct UI, then who's our user, and how can I build for them? How do I write user stories for a backend system?
The key lesson this experience taught me, is that the principles of product management are adaptable across any type of product you're building. However, I found some tools and techniques particularly useful, which I've outlined below to help other POs navigating 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 PO 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 PO, it can sometimes be tempting to delve into the low-level detail of everything your team are building, whether out of interest or a desire for control. However, it is crucial that PO'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 are 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 PO 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 PO 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. If you're interested in joining our Product team, check out our open roles.