A Product Manager’s Guide to Breaking & Rebuilding Technical Foundations, Part III: Managing the Backlog
In part II of our Product Manager’s Guide to Breaking & Rebuilding Technical Foundations, we talked about managing cross-team dependencies and focusing on good habits for collaboration to ensure dependent teams remain unblocked during the implementation of large technical initiatives. Today we’ll look beyond dependencies at managing a backlog in this environment.
As product managers, we’re used to managing the backlog in order to maximize the value of the product. This can become a challenge when creating a new technical foundation, as dependencies, acceptance criteria, and the initiative value itself are all on a deep technical level. In the final installment of this Product Manager’s Guide to Breaking & Rebuilding Technical Foundations, we’ll dive into exactly how we manage the backlog and our tips on handling unexpected issues. (If you haven’t already, be sure to check out Parts I and II!)
Keeping Tabs Without Ownership
Tackling a tech-focused initiative comes with unique ownership and sequencing — a challenge all on its own. In fact, often backlog management on these types of projects is led by the Engineering team, instead of the PM. Given this, it’s extremely important that the engineers are empowered to manage and make decisions within the scope of each backlog milestone. That said, a product manager should not be completely decoupled from the backlog. They should still be able to understand and explain, at least at a high level, why the sequence of epics and stories within them has been chosen.
One way to keep tabs on what’s happening is to regularly ask “why.” Why has this order been chosen? Why is this story more important than that one? Asking engineers to explain their decision-making in non-technical words can help keep the whole team updated with learnings and any new dependency timelines.
Taking on Change
Another challenge we PMs face while managing the backlog (while refactoring and while replatforming) is that change always happens — and it happens fast. Moving to a new technical foundation has a lot of unknowns and uncertainties; every day you’ll learn new things to consider, uncovering new challenges and possible solutions. This can quickly lead to an outdated and messy backlog, which then needs a lot of love to be cleaned up again.
To avoid this pitfall, we suggest checking in with your team at regular intervals — every two weeks or so — on what has changed, and what these changes mean for the backlog. Make sure that there are clear responsibilities within the Engineering team to clean up tickets if they get outdated. This will help keep the roadmap, milestones, and broken-down stories updated, which makes the backlog that much easier to manage.
Automation is also a powerful tool in the fight against messy backlogs. Connecting JIRA to Slack for automated alerts can help trigger regular clean-up action items on a story that has stayed in one status for too long, for example. This type of automation can remove the human error that comes with forgetfulness by ensuring the smaller tasks don’t fall for the cracks of daily business.
Dealing with Scope creep
As we know, part of a PM’s role is to deliver on the needs of our customers. This priority keeps our roadmaps focused on solving customer pains or increasing product value. However, it is impossible to plan for all of the unknowns which will inevitably happen as a team progresses through implementation. And, to make it even more fun, these unknowns tend to be the most time-consuming to resolve — not when developing new features, but when delivering technical changes to existing features.
Technical changes, such as architectural redesign or implementing a new supporting technology, typically alter the fundamental ways in which a feature is supported. When planning fundamental changes like this, it is difficult to predict how features react. And while testing can mitigate breaking changes, it can’t catch all of the potential failure points that come with fundamentally changing a system. If a change doesn’t break a feature, it can still cause the feature to act differently in a myriad of ways.. This can be confusing to users, which, again, may not be picked up on through the testing phase.
All features are implemented with certain fundamental supporting technology and assumptions. When these fundamentals are removed and replaced with something new, the prior assumptions used to design and implement this feature often require rework. All of these changes can have an outsized impact on customers, which means resolving them quickly becomes a top priority. This further complicates planning, as the resolution often requires a revaluation of the assumptions the feature was previously built on. By reevaluating the assumptions, we must also redesign the feature from an implementation and user experience perspective. The UX in particular has multiple variables in play, adding yet another layer of complexity.
So how can a PM help mitigate all of these challenges in the planning process, without succumbing to scope creep and unexpected issues? At Personio, we make sure to include some of our highly-experienced engineers and designers in the conversations around the changes. Just including them in the conversations will often allow them to flag these risks upfront and enable a team to either react quicker or proactively plan to eliminate the problem sooner.
Product Management at Personio
So far in this series we’ve covered a lot of topics, including how to understand true value, manage dependencies across teams, and planning for scope creep (or trying to). Thank you for coming with us on this journey! As Personio continue our company-wide journey towards #EnablingBetterOrganisations, we’ll definitely have more opportunities to continue learning. Want to join us? We’re hiring multiple roles within our Product, Design, and Engineering teams. Check out our careers page to see our open roles.
