Digital product design. How to build a product backlog? A central challenge for success.
Maintaining product backlogs is one of the major challenges of developing digital products.
Greenfield or not?
At inPositiv, we have begun work on producing our first internal product. One of the central guiding questions is whether you can go for a greenfield approach or not. Only seldom can you go for a greenfield approach. In most cases, there is already something there - as was in our case. The existing artefacts may range from an early throw-away prototype to full-fledged legacy software.
Some people argue that a greenfield approach is easier - I would say neither nor. When going for a greenfield approach, you must perform a diligent product idea validation, which is a costly process - while not (yet) delivering tangible business value. At the same time, the product idea is still in the early stages, making it an easy target.
If you are going for a brownfield approach - as in our case - it is essential to not fall into the "all-legacy-features-or-nothing trap". We have an existing piece of software that works. It is up to us to improve it from a functional and UX perspective. We may even remove some functionality if it provides little value or is badly implemented. In fact, we intend to ship a first release that doesn't include all features our stakeholders would like to see. But this is how we will start to gather feedback and improve relentlessly.
In a nutshell: If it is your task to build up a product backlog, ask yourself if you are in a brownfield or a greenfield situation. Then, depending on the preconditions, you have to consider and evaluate the input artefacts differently. The general rule applies: Your backlog, aka output, will always only be as good as your input.
Do you understand the big picture?
Do you know in which direction your product should evolve? Do you understand the big picture? These are essential questions to build up a product backlog successfully. Of course, you can't know everything - you never will - but it is vital to have some rough guidance.
How did we solve this challenge?
We feature a brownfield approach. Therefore, it was easier for us to understand the big picture. However, we faced the same challenge when building up the backlog.
Depending on the tool you are using (we are using Jira) and the size of your product development (single team vs multiple teams), you have to consider different abstraction layers. Side note: It is advisable to start small and verify first in most cases.
In our setup, we can work with long-lived epics and stories. This structure is good enough for the size of our endeavour.
In multiple workshops, we have shaped and prioritised the epics. These represent our big picture. Interestingly, we had a vivid discussion about whether we should go for domain-driven or user-centred epics. For now, we ended up with user-centred epics.
Currently, we have 18 epics of different sizes and priorities. One is the technical enabler, 12 cover mostly existing functionality we want to improve, and 5 are brand new functionality, which will act as differentiators for our product.
It is of utmost value to share the big picture with all stakeholders. Therefore, we will continue doing this and refine it continuously.
Have you considered technical health?
Technical health is essential for a successful digital product. Have you considered it? There is often a fine line between considering technical health adequately and over-engineering.
What is technical health, and what impact does it have on your product?
Technical health considers all underlying technical aspects of your digital product. I would differentiate between technical health in the narrow sense - the topic here - and non-functional requirements / operational elements - which I will discuss later.
Technical health directly impacts the speed and quality of your product development. Therefore, consider it, but making some trade-offs is also possible.
In the section before, I mentioned the technical enabler epic in our backlog. This epic serves precisely the purpose of managing technical health and creating a space for major technical health-related tasks which are too big for daily business.
We will establish standard good practices like coding guidelines and code reviews that are beneficial to technical health.
But there are also further-reaching aspects like an environment concept, good quality test data, static code analysis and even potential moderate change to the architecture, aka refactorings.
Technical health is essential. Not considering it from the beginning will introduce technical debt, which will slow things down, generate quality issues and drive up costs in the long run.
Do you involve the right stakeholder?
Do you involve the right stakeholders in your product backlog? How can you identify these stakeholders, and why is it important?
The two most important domains of stakeholders are the sponsors and the users. Often there is an overlap here. In some cases, they might even be the same people.
The sponsors often have a higher-level perspective and are interested in seeing the product achieve its big-picture vision. Often, they may also be the stakeholder that delivers the funding and expects a return on investment. So when building up your product backlog, this type of stakeholder will be interested in aspects like shortening time-to-market, scalability and fulfilling value propositions.
The users usually have a down-to-earth and operations-driven perspective. These users can be "internal" or "external". Depending on the product setup, the internal user may be wearing an operational hat, and external users are the actual end-user who reap the benefits by consuming the product's value proposition.
These two important stakeholder groups exist in most settings, and keeping them in the loop is vital. Additionally, these two groups will have different interests throughout the product development process.
Not involving one of these stakeholder groups will jeopardise your product development efforts.
Alienating your sponsors may lead to a situation where the funding for your product development efforts will run dry before you can get to an MVP state.
Alienating your users may lead to a situation where you lose backing and demand for the results of your hard work. So the product you are working on won't get any response on the market, and the usage will stay below expectation.
Identify the relevant stakeholders, keep them close and include them in the process of continuously validating your product backlog.
Are you prioritising correctly?
Missing, unclear or conflicting priorities is one of the classic challenges when developing products. It is usually less complex if you have just one team and hold the product owner role. But it can become a significant issue.
Many concepts tell you how you should define your priorities. But, unfortunately, reality seldom works like a predefined concept - there is usually more in play than can be predicted.
I discussed the critical stakeholder groups that help set priorities straight. However, it can also become extra tricky if you have to decide against the interest of one of these important stakeholder groups.
So here are a few concepts that can help you to prioritise:
How relevant is a feature for the core experience of your product? Does it lead to a substantial differentiation?
What is the time-to-market impact of a feature? For example, does the introduction of the feature accelerate time-to-market - e.g. by convincing more potential users that the product has reached maturity?
Does the feature scale well? For example, are you implementing a custom finish, or is it something that a broad range of users can use?
Is the feature decreasing or increasing the complexity of the product? Is it a starting point that demands follow-up investment, or is it a consolidation that may even tie up some loose ends?
Considering these or similar open, shared, universal concepts as benchmarks can simplify prioritisation.
Having clear priorities and a good plan increases the effectiveness of product development.
Do you have a sound project setup?
At first glance, this may sound like a rather administrative topic. But neglecting it will throw all your product backlog efforts in disarray.
Let's assume you have a good product backlog and are on the journey to build your product. How are you proceeding on your product development journey? Can you demonstrate progress? Can you respond to change? These are classic issues that can stall product development.
To fix these issues, you need a persistent and disciplined mindset. But there is also the methodological part of the setup which needs attention. When building up your product backlog, you should actively investigate the following questions:
Who is holding which specific role when developing the product? Mainly to define and establish clear responsibilities - may come in handy if, e.g. a difficult decision needs to be taken.
Who challenges these roles to perform admirably over a longer period? Mainly to coach and challenge these roles - may come in handy if, e.g. there are some interpersonal issues in the team.
What product development setup/shared rules are we using? Mainly to measure progress and check if you are delivering according to plan - it may come in handy if a sponsor wants an update by when she can expect the delivery of a new feature.
How are we responding to change? Mainly to define when one can safely raise a flag and design the change process - which may come in handy if something in the team or the product roadmap needs changing.
A clear understanding of these questions will increase the chance that the product development initiative will succeed.
There is no need to reinvent the wheel - applying a tried and tested framework like Scrum is undoubtedly good enough.
Do you have a healthy product roadmap?
A plan is a plan - product roadmaps are tricky because reality usually does not treat them nicely. Nevertheless, it is essential to have some guidance to know where you are going.
Some agile evangelists might argue that you only need a backlog and you should "just" let the team pull from that backlog according to identified priorities. This idea sounds nice in theory, but product development doesn't work like that.
In complex settings, dependencies and stakeholders need additional consideration. For example, your product setup will depend on other solutions, teams, and external suppliers when reaching a certain size. Additionally, you will need to address and involve upstream and downstream stakeholders - like business development, operations, and product sponsors.
It is advisable to have a lightweight product roadmap to increase the chance of successful orchestration in complex settings. You should know which stakeholders you focus on and make it as simple and "universally understandable" as possible.
You can take these considerations as guidelines:
Which time horizon do I want to cover? Consider: Reality is usually more complex than anticipated. Up to two years ahead is usually a reasonable timespan. More than two years becomes vague.
Which stakeholders do I want to address? Consider: This is a critical question. It will impact everything - from detail grade to the domain language of your roadmap.
Do you only want to "send", or do you also want to "receive"? Consider: In most cases, product roadmaps "send" information to other stakeholders. But good product roadmaps are interactive; the stakeholders can also interact with them and contribute valuable data.
Which depth do you need? Consider: Has a relation to the stakeholder selection topic. For example, do you go down to feature and dependency level or are you on a higher business/value proposition flight level?
Starting from these questions, you can then design your lightweight product roadmap.
You can treat the product roadmap as a second-class citizen if you have a clear mission and closely involved sponsors - because good product development execution should always go first. But if you have room to improve these supporting elements - go for it!
Is your backlog able to adapt?
One of the most demanding challenges is balancing "backlog discipline" with good execution; this is one of the most challenging trade-offs in product ownership. However, if you can develop your product and have these two aspects in a good balance, you can proceed with the highest effectiveness.
Let me quickly describe the two anti-patterns:
I've already seen beautifully designed backlogs-big, well-maintained, and lovely stories - but these usually lack execution. You start to become defensive about "embracing change" if you have already invested "so much" in your backlog. And trying to specify too much in advance draws resources away from building and running the solution. Edge case: A setting where you can invest as much as you want - but this is undoubtedly not the highest effectiveness from an economic perspective.
And this is usually the more familiar anti-pattern: I sadly often see dried-out backlogs. In the beginning, the product is new, there is a push to build a cool backlog and convince stakeholders, and onward, it is drained. The backlog doesn't really live, and also critical new features are built in-flight, or the team might even stop using stories. This is one of the most severe product ownership anti-patterns.
As so often, the optimum lies somewhere in the middle. There should always be a slight tension.
If you have time to specify everything ahead easily, there,
is either not enough demand in the market for your product,
you don't do enough product-centred innovation,
or you have too many resources in the design process.
If you experience the situation of a draining backlog, you either:
Don't live your methodology/manage your stakeholders to the full extent
Don't have a vision/valid product,
or not enough/right resources in the product design process.
As in many entrepreneurial areas, good product development is a state of creative restlessness. But it would be best to prevent it from becoming chaotic - a welcome complex challenge.
