Article summary
Making custom software products is extremely difficult and rife with risk—technical risk, business risk, etc. The Product Manager’s job is to see the big picture, manage the risks, and help the whole team make smarter decisions.
Managing Risk at Atomic: A History
Since we opened in 2001, we’ve helped clients reduce technical risk through our strong Agile roots and by growing a team of the best engineers. We later built a team of amazing designers to help clients reduce the risk that their product may not be usable or solve the intended problem.
However, one category of risk largely remained in our customer’s lap—the risk that the product might not have the most valuable set of features possible.
Practically speaking, this is less of a risk than an opportunity for optimization, since Atomic’s Project Leads always collaborate with our clients to help them make high-level prioritization decisions. But the larger the project gets, the more complicated this becomes. And not all clients can dedicate the time and attention it takes to do this well.
Since Atomic is always looking to learn, grow, and improve in everything we do for our clients, we’re adding a new tool to our belt which will reduce this risk for our clients—the Product Manager role.
Shepherding the End Product
At Atomic Object, a Product Manager:
- manages a list of all features (the product backlog)
- ensures we have an idea of the cost of each features (a relative points estimate)
- ensures we have an idea of the value and priority of each feature (through stakeholders and research)
- makes sure the product dev team always has well-defined, top-priority work in the backlog
- decides when a feature in the product backlog is done
- tracks progress to calendar/budget goals and intermediate milestones
It’s a difficult pair of shoes to fill.
On teams of more than two people, or on projects that last more than a few months, the role is often shouldered by client stakeholders or dev team members—or split between them. This can work for a while, but it’s suboptimal, and can prove to be unsustainable if those people already have another full time job or role.
We believe that, on larger projects, this role should be filled by a dedicated client stakeholder or an Atomic Product Manager. 50-100% of the Product Manager’s time would be spent working directly with the product dev team, and the product manager would need to be 100% available for questions from the dev team. Ideally, the Product Manager would be co-located with the product development team full time, except when working with stakeholders and end users.
The role is complex—in part, due to the rich context of tools in which we’re introducing it: product backlog, points estimate, velocity, sprint, backlog grooming, etc. It can feel overwhelming for someone to get started.
As a primer, I’ve found the video below to be an excellent resource. It uses the SCRUM term product owner instead of product manager, but the role described is one and the same. If you’ve made it this far, I highly recommend you watch the entire video. It not only describes the product manager role, but the core tools of the Agile process we practice at Atomic.
I’m excited to continue working with our clients and teams to bring this role into complex projects.