This completes a long three-post series (1,2) proposing a skills model for product owners, partly borrowed from market-facing product management responsibilities. I’ve tried to reach beyond simplistic role descriptions, to map skills against real-world organizational needs.
Re-summarizing these thoughts:
- Software projects come in all varieties. For some projects, product owners need market-facing skills as well as core agile practices (release/sprint planning, story writing, prioritization, backlog grooming).
- Organizationally complex internal projects demand some market-facing skills, listed below
- Revenue software demands a specific mix of technical and market/business skills which the job market calls “product management”
Here’s the project map I’ve laid out, spanning internally consumed software to revenue products (bottom to top), and known single users to conflicting user groups /mass markets (left to right).
In the lower left corner, I see projects where by-the-book product owners succeed: where it’s enough to do core agile well by representing known sponsors and stakeholders; translating needs into stories and backlogs and release plans; accepting good software; making feature-level trade-offs.
At the top right is commercial software, explicitly exchanged for money. Software companies know they need a mix of technical, market and organizational skills to drive revenue software, and label that job “product management.” Hiring, training, mentoring and reporting models are uneven or poor, but we mostly know what we want.
In between, I see talented product owners (whatever we call them) executing beyond their narrow role definitions and struggling with organizationally complex roles. For now, I want to ignore philosophical discussions about role-versus-title, instead focusing on what these hardworking folks have to do – or know – to succeed.
So here are five market/business skills that product owners probably need on projects that live in the fuzzy middle ground.
1. Telling Both Sides of the Economic Story
Roughly, how much money will this software save our users (customers), and how much will it cost to build? Companies don’t write software as a charitable exercise, so these questions should come up often. The person prioritizing work should have an estimate, at least to one digit. (Sounds simple, but I almost always get a blank stare or an excuse instead of a thoughtful answer.)
Something like…. “This improved technical support software will speed up resolution of customer cases. Support thinks it will save them roughly $500k next year. Licenses and internal development should be about $100k. And we expect faster resolutions to boost our NPS.”
Economic buy-in from the intended users is crucial, since the savings is theirs – and ideally gets measured. It’s also a good indicator that your users still want what you agreed to build last October. Purely qualitative justifications (“this is part of our corporate-wide mandate to improve customer satisfaction”) are weak, and invite cancellation.
[On the revenue side, we call these thumbnail business cases. “This product fills a $20M hole in the market, confirmed with multiple prospects. We can build v1.0 for $5-7M, probably hit breakeven with the year.” Every competent product manager knows how to create a back-of-napkin business case.]
2. Segmentation, and sorting outliers from core users
Your app may have only a handful of users, which makes identifying them easy – and weighing their feature requests straightforward. The one guy in Logistics who uses weekly shipments-by-destination-country reports knows what he wants.
If your app serves many departments, though, with users at various goals or skill levels, you need to understand an assortment of intended “customers” and typical user profiles. [On the revenue side, we call this segmentation.]
This helps savvy product owners plan a successful internal roll-out. Which departments need this the most, are willing to be trained, and have strong director-level support? Which groups are handling standard transactions, versus boatloads of exceptions? We might want to deploy to typical or strategic departments first, take our learning lumps, and defer the naysayers until we have strong buy-in elsewhere.
And sorting enhancement requests gets easier. That Blackberry user whining about our “Android and iOS only” app support? Helps to know if your entire Canadian sales team is on a long-term BB contract. The Director of Finance wanting cheat sheets showing the company’s chart of accounts? It matters whether the new AP Reporting Module is for executive dashboards or heads-down use by dedicated AP clerks who can recite the chart of accounts in their sleep. Not all requests – or requesters – are equal.
Product owners or business analysts who talk about a singular customer (“what the user wants” or “what the business said”) are probably on lower-left-corner projects. Or blending dissimilar users into one persona. Or leaning on someone else to sort core users from outliers in a diverse population.
3. Marketing / Selling the Solution
You and your team are going to spend months (years) building out some great new internal solution. Then you’re going to send a few emails to the users and expect them to excitedly grab the next new thing? Not a winning strategy.
[In the revenue software world, this aligns with developers who believe enterprise selling is bringing factually correct data sheets to unemotional prospects, and letting them objectively pick the best product.]
So someone, probably the product owner, has to create internal promotional content. Revenue folks call this product marketing. At a minimum, carefully crafting:
- Department-level adoption rationale, based on your economic logic above. (“This new technical support software will speed up case resolution, improved Customer Sat, and save us a lot of money…”)
- Clear user-level benefits, selling individuals on why this makes their daily lives better. (“You’ll spend less time searching for similar cases, which means shorter wait times for customer and fewer late nights for you…”)
- Incentives aligned with the behaviors we want. (“You can learn the new system in under 10 minutes, and we’re giving away a pair of tickets to WICKED to one of the first 75 support techs to close out a case with the new software… remember that we’re retiring the old system on December 15th.”)
Your internal sponsors and stakeholders will probably send out the messages, but the content needs to correctly “sell” the new thing. More important (larger) projects usually get proportionally more internal marketing.
4. Beyond v1.0.0: a Multi-Release Plan
No software is ever complete the day it ships. There’s some amount of bug fixing, postponed features, enhancements, general sustaining engineering and platform upgrades in the wings. Nevertheless, some internal development teams are disbanded as soon as the new stuff is accepted by its user representatives.
As product owner, you’ve been consistently moving things to the backlog and keeping a tight focus on short-term value. (Remember all of the savings we’ve claimed to capture in #1!) In a project-driven model, someone needs to anticipate what’s next.
- What’s our post-release staffing model? Ongoing release cadence, continued participation of the development team, backlog strategy? When will the new system achieve its intended return to company?
- What software is being replaced? Have we announced an EOL for the old thing, and started forcing users to migrate? When can we turn off those lights?
- As other systems change (new CRM vendor, cloud security mandate, Red Hat version), how will we update, test and deploy? Who owns this?
Whether you stay assigned to this software or not, someone has to be the responsible adult and have a plan. If it’s not you, then you owe the company a thoughtful recommendation (or escalation) so that most of the business value isn’t left on the floor.
5. The Portfolio View
Humbly, here’s where I see the biggest gap between narrower (by-the-book, sprint-level-focused) product owner roles and (quixotically broader) product management responsibilities. Real-world product owners are typically assigned to projects that are already approved, with known sponsors/ stakeholders who have already decided this work should move forward based on guesttimated budgets/staff/timelines. Product Owners “own” relative feature priorities and satisfying identified users, but mostly act as representatives or proxies of the folks who actually make product/resources decisions.
[On the revenue software side, I expect product managers to be constantly pitching new products, proposing re-allocation of staff, justifying new headcount against revenue, and occasionally recommending that their own products be EOL’d. They have to answer for the ongoing economic justification of their products as well as its technical needs.]
So as we move upper-right toward complex, costly, cross-business-unit programs, I look for product owners who push the tough portfolio and economic issues that users/stakeholders rarely raise:
- Is this still as important as when we started? If we had to cut 10% of our current projects, would we drop this one? (i.e. should we cancel this effort entirely?)
- How does this fit our technology portfolio or system strategy? Are we building the wrong thing? Is there a viable third party solution at 1/10th of the cost?
- What are the non-technical risks and opportunities? Are we in danger of delivering perfect software and still failing, because (for instance) users have an incentive to stick with the old solution?
I’m always hungry to find (and promote) product owners who exceed their nominal scope… product owners who are more than technical representatives assigned by Development, more than neutral translators between designated users and agile teams. Product owners who see the broader context, identify organizational barriers, and attack the meaty parts of the problem. Everywhere I look, I see organizations desperate for whole-picture product folks who act on behalf of the larger business.
Roles and Titles?
I’ve tried hard to sidestep “role versus title” distinctions. Whether you’re a business analyst in a product owner role, a veteran product manager finally adopting agile, or your business card actually reads “product owner,” I want to focus on skills and success criteria: when picking someone for this particular hot seat on this kind of project, what skills and experience do we need? Are we writing these down, asking candidates about them, and hiring for success?
Standard practice seems to be picking a subject matter expert who’s available, asking her to “play” product owner, throwing her a book or two, and tossing her into the pool to acquire on-the-job swimming skills. IMHO, engineering organizations don’t fully understand, value or teach market-facing skills, so product owners need to learn them elsewhere. Those of us with one foot on the business side and one foot on the development side need to help.
[Thanks for making it to the end of this long, nuanced argument.]
Sound Byte
Software projects vary widely in their diversity of users and organizational complexity. Agile product owners may need a range of market-facing and business-side skills to guide complex projects. Commercial product management is one good model to borrow from.