What do you think it means to be a product owner — not simply the product manager, but a true product owner?
You can Google the term and find plenty of definitions, but for our purposes here we can think of a product owner as the person directly responsible for ensuring that a product gets built as closely as possible to the company’s strategic vision for it.
a
And the best way to ensure you are acting as a true product owner is to always think of yourself as a member of your agile development team and not a product manager outside that team. That means you work closely with developers. You always confirm that they understand the vision and strategy before they begin building. Finally, you’re always available at all times to answer their questions.
Tweet This:
“Work closely with your developers to confirm they understand the strategy before they begin building.”
The problem is many product managers, even great ones, often misunderstand or neglect this part of their role. They might perform phenomenally in carrying out their other responsibilities — communicating strategy to stakeholders, overseeing budgets and resources, synthesizing user feedback and competitive intelligence to create a product development roadmap, etc.
But when it comes to the day-to-day responsibilities of real product ownership, many product managers simply fall short. It can be risky to let this aspect of the role fall through the cracks in any company, but it is particularly dangerous in an agile development environment.
That’s because the less you behave as a member of your development team then the longer you go without communicating with them. That means you have less input over what they’re building and they are more likely to drift away from your strategic vision for the product.
5 Things a Product Owner Must Do
Here’s a quick way to determine how well you’re meeting your obligations as a true product owner. Ask yourself if the following statements describe you:
- I think of myself as part of the product development team. I’m not simply a product manager who writes specs, delivers them to our developers and then waits for them to build something. I am an active member of that team, from the initial product kickoff meeting, through launch and beyond.
- I attend and actively participate in all sprint planning sessions.
- I attend and actively participate in all sprint demos. (In fact, our development team won’t hold these demos without me.)
- I am always available to my developers for questions or discussions about the details of the product they’re coding.
- I review every story (which usually must include a mock-up) before it gets into a sprint.
One way to know that you’re succeeding in your role as a product owner, then, is that it will feel like you might be over-communicating with your development teams.
3 Clues That You’re Falling Short in Your Product Owner Role
By contrast, here are a few clues that might suggest you’re not fulfilling your all-important role as the product owner. Ask yourself if these statements sound familiar.
- When I review what my developers have done, I often find myself saying, “No, that’s not what I meant in my spec.”
- I also often find myself saying, “Can we change this? Now that I see it, I realize this wasn’t exactly what I had in mind.”
- I don’t need to approve screenshots or mock-ups before my developers are able to push new code to the live product.
What these clues have in common is that they suggest the product manager (or other person assigned the role of product owner) is thinking of herself not as part of a cohesive agile team, but rather as someone separate from that team whose job is simply to deliver a one-way, high-level communication to the developers about what to build.
It’s as though she’s saying, “Here. Read this detailed spec, and get started. We’ll meet again when you’ve built it.”
But in an agile environment, one of the real advantages is the tight feedback cycle for both developers and product owners, particularly in sprint reviews. These will be opportunities for product owners to give developers directional feedback on what they’re seeing, and for product managers to receive frequent updates on the progress of development.
Tweet This:
“Frequent review, communication and course-corrections help teams build better products.”
It’s this cadence of frequent review, communication, and course-corrections that helps teams build better products. So by falling down on your role as a product owner — by not actively participating in story reviews, sprint planning, demos, and creating a culture that makes your developers feel comfortable asking you questions along the way — you will be missing out on the real power of the agile development methodology.
Product Roadmaps are Key in Sprint Reviews with your Agile Dev Team
As a product owner, you are often in a head-up position. You look at your market, talk big-picture strategy with your product team and stakeholders, and discuss your product’s key benefits with your user community. You get enthusiastic about your product and hear directly from the people using it.
On the other hand, your developers spend much of their time their heads down thinking about the products they’re working on not only from a strategic perspective but also from a ground-level tactical one: fix this bug, finish that story, and get the code ready for QA.
Review with your engineering team, not just the backlog but also your strategic roadmap. Give them your big-picture plans and let them review your strategic roadmap. Doing this you’ll get a lot more value from your sprint planning sessions than just giving engineering a to-do list.
Value of bringing an agile roadmap to your meetings:
- Tap into your development team’s collective creativity (even genius), and discover new ways to get things done.
- Get your engineers more enthused about their work. They’ll see how the small items they’re working on for this sprint will be serving the product’s long-term health and creating a better user experience.
There’s a strong correlation between your roadmap and your team’s human capital. The high-level nature of your product roadmap makes it the perfect tool for communicating the meaning behind the work at hand. Tap into the bigger picture with the help of your roadmap, and increase your chances of striking a chord with the people pushing your product forward.
You hear stories all the time of engineers coming up with innovative ideas for their companies’ products. That phenomenon can happen in any organization—assuming the product owner sets the stage for it. This includes inviting the development team into the strategic conversation. Use the tools at your disposal to constantly remind your entire team what it’s all for, and the genius will follow.
All of which is to say you can’t simply put in general requirements and send your developers off to work in a silo until they’ve built a completed product (or finished an epic or story). You need to be right there with them at every step.
Why Do Product Managers So Often Fail at This Part of Their Job?
Okay, you might be wondering, if becoming a product owner is so important for your product’s success, and if it really boils down to simply embedding yourself in your development team, as opposed to keeping your distance and checking in with them only once in a while, then why do product managers find it so difficult? A couple of reasons.
First, taking on the product owner role is time-consuming. Really time-consuming.
Remember the section earlier, about the things a product owner must do? You’ll need to attend and be an active participant in every sprint planning and in every sprint demo. You’ll need to create an open-door policy for all of the developers working on your product, where they can come to you anytime with questions about your strategic thinking or what you’re expecting from some aspect of the product. And you can expect a lot of these questions.
Finally, you’ll have to review the mock-ups or screenshots your developers prepare for each story prior to placing that story into the sprint. This is the only way to know if a) your developers clearly understand what you were envisioning, and b) you’ve been unclear in preparing that story, which has translated into your developers not quite nailing it in the mock-up they’ve prepared. This will be where you stop development from building something incorrectly before they even begin.
Clearly, these are valuable steps to take. But if you add all of these responsibilities to your already-full plate of PM tasks, you’ll find it’s a lot to handle.
A second reason it can be difficult to take on the role of the product owner is that product managers can often be intimidated to work closely with development because they worry they aren’t technically savvy enough to ask the right questions or to understand the answers.
But you can’t let that slow you down. When you become a true product owner and “join the agile development team,” you’ll need to become comfortable saying things to your developers like, “I don’t understand what you mean. I’m not a developer, so you’ll need to explain this to me in layperson’s terms.”
But there are plenty of benefits to approaching working with development this way. First, you’ll often find that when your developers say no to a request of yours, it’s simply because they don’t understand what you’re asking. (They’re not product managers, after all, and aren’t necessarily fluent in your language either.)
Also, when you make yourself part of the agile team you’ll quickly learn a lot of the technical details that might have previously intimidated you. That’s an enormous benefit both to your product’s success and ultimately to your career — because it means you’re learning to bridge the divide between product management and engineering that so often prevents organizations from delivering the best products possible.
Do you have any experience working as a product owner with agile development teams? Please share your thoughts, insights, and suggestions in the comments section below.
