How do you define your backlog when your team's work involves refactoring or is architectural in nature?
At Hivekind we like to use Scrum. One thing we like about Scrum is the roles it places on software teams. The three key roles you'll see on a Scrum team are:
- Scrum Master - owns the process, ensuring it is followed and that it evolves with the needs of the team
- Development Team - own the implementation, ensuring the product is built correctly and robustly
- Product Owner - owns the product, and is in control of the backlog of work which the team implements.
The Typical Product Owner Role
We typically think of a Product Owner's role on a Scrum team in the context of building a product for end-users. Users who are perhaps paying a subscription to use the product. Users who are not employees of the company who own the software.
The backlog the Product Owner defines is essentially a roadmap outlining the future features of the product being built. They do this by:
- Being well versed in the business domain of the product. For example, if the product is educational in nature they'll make sure they know all about the EdTech space.
- Understanding who the users are, what their problems are, what problem the product is trying to solve, and which other products the user might use to solve this problem.
- Supplying the Development Team with design prototypes which show how the next set of features will behave and should be implemented.
- Gathering feedback from a wide range of stakeholders and incorporating this feedback into their plans.
Looking Inward
But what happens when the team's focus is something different?
Another thing we like at Hivekind is to work on projects which are internally facing. Projects which involve refactoring or architectural evolution. For instance, migrating a database system from one technology to another, rearchitecting information flow within the product's stack, or moving one business component from an in-house to a third-party solution.
How does the Product Owner role differ in this case? It turns out that it changes quite a bit. Let's take a look at how.
Enter the Technical Product Owner
The business domain becomes the technology stack in which the product is built. The Product Owner must understand the technology stack very well. Their role is therefore highly technical.
Describing the roadmap via design prototypes is often irrelevant. The scope of work will more likely be a series of refactorings. The project might depend on the choice of a key technology like a database system, data bus or analytics platform. The Product Owner needs to know this domain deeply and be able to make lasting business decisions based on this understanding.
Users of the software being created tend to be internal to the company which owns the product. More often than not they are technical people: developers on other teams, operations engineers, etc. If not technical, they may be members of sales teams, marketing people, customer support reps, data analysts, etc. These people are stakeholders. The Product Owner needs to communicate to these users using language they understand, again often technical in nature.
The Product Owner may need more input from the Development Team than they would otherwise. In order to figure out feasible and appropriate solutions, they may need the Development Team's expertise. They may be a developer themselves, having stepped into the role for the duration of the project.
Traits of a Good Technical Product Owner
To excel in a role like this, a person will typically be good at:
- Understanding technical concepts and discussions.
- Gauging another person's level and explain a technical concept to them in a way in which they'll understand.
- Navigating an organisation's people and teams, in order to "sniff out" who the users of the team's output will be, talking to those users and incorporating their needs into the product backlog.
- Translating a high-level end goal into a discrete number of actionable steps.
- Holding the state of the project in their mind at all times, adjusting that mental model (and related project roadmap) based on new information, and explaining the state of the project to any stakeholder extemporaneously.
The Missing Piece
Oftentimes a medium-sized software company may be missing this role and suffering as a result. The tech team's Scrum teams may have Product Owners. Teams may be able to define user-facing roadmaps and implement them.
But when it comes technical debt repayment, refactoring or significant architectural changes, they stumble. Oddly defined initiatives (sometimes comprising of team of only developers, working apart from the way other teams work) get underway and eventually fizzle out.
What's needed in these cases is a regular Scrum team with a Technical Product Owner.
Is technical debt bogging down your development effort? Do you suspect you need to repay that debt but aren't sure how to get started? If you'd like to hire a team who can help (complete with a Technical Product Owner to boot) let's start a conversation.
