Agile works best when a team has a product owner to help prioritize work. In a perfect world, every team will have a knowledgeable product owner who can dedicate a large chunk of time to the project. Of course, we don’t live in a perfect world and this isn’t always the case. Keep a few things in mind to deliver the best product possible when working without consistent product owners.
Keep the stakeholders engaged as much as possible.
Ideally, a product owner will be closely involved in story writing, estimation, and backlog refinement to ensure the correct priorities are in place. This close involvement allows them to account for feature complexity when prioritizing work. When these tasks fall solely on the development team, it’s not always easy to know if what you’re working on is what’s most valuable.
In this case, try to get creative with opportunities for the stakeholders to fill this role when possible. A good time to do this is during regular sprint rituals, such as demos or sprint kickoffs. Pulling up the backlog and having the stakeholders prioritize individual stories probably won’t be valuable when they’re not closely involved in the backlog process in the first place, so a more holistic approach may be more helpful. Give the stakeholders a higher-level view of what features devs are working on. Make sure to use plain English estimates of complexity and team capacity.
This demonstrates one strength of agile project management, An iterative approach to development, with frequent check-ins, can still help a team stay focused even without a product owner to provide that focus.
Deputize devs as product owners of individual features.
When the team has a high-level idea of the product’s direction, you can prioritize individual features. Picking developers to own one of those features can provide direction similar to that a product owner would provide. The developers would be responsible for gathering requirements, writing stories, and prioritizing individual stories for each one’s own feature.
A further benefit of this is it allows developers to gain more experience with the story-writing process. It also helps them learn more about the work that goes into gathering requirements and prioritizing work. We employ this strategy here at Atomic Object on larger teams, even those with a product owner. We usually call it feature captaining.
Be sure when doing so that you set a consistent standard of how stories should be written as much as possible. Using story templates within the feature tracker of your choice can help with this.
Avoid developer-designer siloing.
When the product vision already feels fuzzy, not ensuring developers and designers are working in tandem (i.e. in a silo) can make things feel even fuzzier. A team runs the risk of design and development coming out of sync. That could result in features not getting implemented as expected.
A designer may generally have a better birdseye view of the project than individual developers as well. This allows them to fill in many of the gaps a team with a product owner can have. As much as possible, designers should be involved in story writing and backlog refinement. If time allows, it’s valuable to pair with designers when working on stories to ensure design and implementation remain in sync.
The Importance of Product Owners
While keeping these ideas in mind can help, there is ultimately no replacement for a dedicated, knowledgeable product owner on a team. They are one of the most important pieces to ensure a product delivers the value most important to stakeholders. Whenever possible, ensure the role is filled when determining the makeup of a team on any large, longer-running project.