9 Things Every Product Manager Should Know about Being an Agile Product Owner
Congratulations. You’re now an agile “product owner,” the champion for your product. No biggie–you just have ultimate accountability for the health and well-being of your product. You “own” the product vision, deeply and emphatically understanding customer needs, keeping pulse of changing stakeholder values, and making continual decisions on what to build (or not), and when. This is a tall order.
Maybe you came into this work from being a product manager, having been in marketing, customer service, finance, business analysis, engineering, sales, or some other business or technical area. Or perhaps you came into being a product owner directly from one of those roles. You likely understand the aptitudes and aptitudes of a great product manager.
What essentials do you need to know as an agile product owner?
1. Put the Ends before the Means.
Agile focuses on value, and delivering the highest value features as soon as possible. To do that effectively, everyone—from the c-suite to the engineering team—needs to have their eyes fixed on the prize. One of your many jobs, and perhaps the most important, is to share, over and over, the vision, goals, and objectives for your product. Better yet, build a collaborative product visions with representatives from cross-functional disciplines, including engineering.
2. Build Empathy for Your Customer.
Share what you are learning from your customer visits, research, feedback, and interactions. If at all possible, bring your engineers, testers, business analysts, user experience, and any other members of your delivery team to your customer to observe, shadow, or apprentice. Invite them to read customer service and complaint emails or sit in as operations or customer service addresses customers needs. Have them experience walking in your customers shoes, just as you do.
3. Stand Up.
Attend daily standups. Don’t look at them as status meetings, but as daily planning session that require facilitative leadership—yours.
4. Cozy Up.
Make yourself, or someone you explicitly designate as your tactical “product owner,” available every day to answer questions about work in progress. Be available to clarify acceptance criteria and to review prototypes, completed stories, or other evidence of acceptance before the demo. Until you’ve seen it, the team can’t really consider it done. Don’t wait until the demo to see what the team has accomplished—otherwise you and they will lose opportunities for real-time refinement and gain potentially embarrassing demo-day surprises.
Always, always, always attend your teams demos. Better yet, facilitate the demo where customers or proxy customers demo the completed work. Even better, I challenge you take it one step further: “invite the world”. Market your demos. Get colleagues from other areas. Encourage engineers to invite others. Bring in colleagues from other product areas (product champions), engineering teams, operations, and so on. A standing-room only demo not only showcases you and your team’s work but also demonstrates accountability and invites powerful feedback within your organization.
5. Fess Up.
You are part of the team, so be part of the team’s retrospectives. Be ready to give and receive feedback. You are integral to the team’s—and your own—learning about the process and product. Be there, be engaged, and expect retrospectives to be well facilitated, engaging, and transparent. Each retrospective should conclude with one or two specific actions for improvement.
Some people might argue that retrospectives are for the team only. Push back. You’re part of the team—and have a right and an obligation to be there. And remember: retrospectives need to be facilitated by skilled, neutral facilitator, which can be ScrumMaster from another team.
6. Decide How to Decide.
Don’t relegate decisions about what features to build and when to the engineering team. That’s your responsibility. Do, however, encourage them to share and express their opinions (hopefully backed by data). Ultimately, however, the decision about what to pull from your product backlog lies with you.
You can choose to delegate decision-making authority tactically to a business analyst, tester, tech leader, or ScrumMaster (whomever has the right skills) when you, like many typical product champions, are overloaded with strategic responsibilities and discovery responsibilities. But once you delegate that responsibility, don’t come back and overrule or second guess the decisions that were made. Your surrogate must have explicit and transparent authority to choose. Otherwise, the engineering team will quickly lose faith.
7. Move in Measurable Inches.
Think small: small slices and small tests for small slices with clearly defined desired outcomes. Create your product inch by inch. Teams need clear, measurable acceptance criteria so they can create the tests necessary to ensure that what they deliver is what you need.
8. Develop Telescoping Vision
While you may move in inches, you still need to see the yards. On an agile project, you don’t attempt to understand or predict all product requirements up front. But you do need to sketch out the long view of the product to establish a common focus and marshal organizational resources (people, money, space, governance). From that vantage point, you define what to build in each release, and then in each iteration.
These three levels—product, release, and iteration—correspond to three views (the Big-View, the Pre-View, and the Now-View) of the product.
The Big-View includes the overall understanding of what the product will be and the sequence of delivery. The Pre-View outlines what product functionality to deliver in a given release, and obtains agreement on the backlog items to deliver in the first few iterations in the release. The Now-View defines the items the team will deliver in an iteration.
The best product owners are able to keep the Big-View in mind, even as they progress through the Now-View and the Pre-View.
9. Use Roadmaps as a Guide, but Don’t Pave Them.
Agile projects need a planning and analysis tool called the product roadmap. A product roadmap is an evolving plan of product releases, with brief descriptions of their themes, features, and anticipated outcomes. A product roadmap is intended to realize the product vision over time and satisfy goals and objectives.
Please note two things in that description: Evolving and over time. These are two key points that the best product owners keep in mind. As the product is developed, the roadmap must be revised to include new technologies, emerging opportunities, response to market conditions and customer feedback, team cycle time (or velocity), and new learning. If you create one roadmap at the beginning of a project, freeze it, and never stray from the original path, you will miss the chance to discover and deliver a product that will truly delight your customers.
Product Managers Make Great Product Owners
At their core, being a product owner (a.k.a. product champion) means doing what great product managers do naturally: lead a team toward a vision, in small steps, with regular stops along the way to check in, adjust, and move forward.
To help those making the transition from product manager to product owner, and you will be joining us at the Product Management Festival in Zurich, you’ll find our Agile Open Jam a good venue for exploring this topic. Also check out EBG’s Essential Product Owner: Championing Successful Products on-site training offering. It equips you with knowledge and skills for discovering and analyzing your product backlog, making difficult and effective value-based planning decisions, and continually refining a lean product backlog.
As me being an owner these 9 points are really very informative and very helpful.Thank you.I Really appreciate it 🙂
These 9 gems of knowledge are very helpful in performing my job role as a Product Owner.
Thanks,
glad you found them useful, Paul!
thanks Steve. appreciate your kind words. writing it was a ‘labor of love’ 🙂
‘
Thanks, ellen, these are really useful. So just a couple of controversial questions (I hope 🙂 ) …
Is the PO a career PO, and not necessarily a real end-user of the product?
Is the PO in fact the old BA or BSA role in disguise?
or is the truth somewhere else?
Dot: thanks for your comment and questions. of course these questions come with the “it depends”/contextual frame.
PO career PO vs real-end user of the product: i’m not sure those two things are mutually exclusive. Being a real end user of the product gives a product owner the empathy for the end user that all POs need. If they are not “real” end users, they need to learn how to get that empathy through direct interaction, observation, inquiry, modeling, and experiments.
People doing the work of product ownership who have a proclivity for product management (more strategic, outward facing) may find that career path both logical and satisfying. They may move into ‘uber’ product ownership/championship for multiple product lines or a portfolio. Or even move into a senior engineering role – that helps bring the product and customer voice to what might be a classic engineering or delivery mindset. Some POs would benefit by moving into product specialty areas such as marketing, pricing (for commercial products), customer service or operations.
I don’t prefer disguises 😉 If an “old” BA or BSA is the recognized leader of the product — guiding product vision and articulating and hunting for value — and if this person has been explicitly delegated decision making authority for deciding which items in the product backlog will be prepared for and pulled into delivery — well then that person is the PO.
Analysis needs to happen – regardless of role (as Mary Gorman and i have said and written about: “Its’ the Goal, Not the Role” ( http://www.agileconnection.com/article/its-goal-not-role-value-business-analysis-scrum ).
Teams lucky enough to have people with great business analysis skills built into the mix of people do indeed find these skills essential to smooth flow and delivery of value.
Furthermore, agile analysis skills are incredibly helpful for pairing with time crunched POs. People with those analysis skills often have the job title in many orgs of BA or BSA. These “BAs” often need to have “T” skills with testing and Ux. In sum, We want these folks to be “tied at the hip” with their PO and Product Mgrs while also able to solve the tactical, day-to-day questions about product requirements details.
thanks for the questions!
Love this, I wish all product owners understood just how important their part of the process is. Next time I am asked what does a PO do I am sending them here 😀
thanks Andrew!