When software companies are short of developers (or architects or test automation engineers or DevOps experts or technical writers or product managers), we look internally but also recruit outside. We may poach someone good from another department or promote from the ranks, but most new talent comes from hiring. And creating an open position forces us to write down what skills/experience/responsibilities/talents/style we need.
At a wide range of software companies, though, we don’t hire product owners. I’ve seen scores of agile teams created without any product owner, or unofficially borrowing folks who keep their full-time day jobs, or grabbing random folks without regard to skills/experience so that someone can “play product owner”.
Some oft-repeated phrases that IMHO highlight a pattern of deeply dysfunctional behavior:
- “Who’s available that we can borrow as product owner for this project/product? It’s a role, not a job.”
- “Her manager won’t free her up, so we’ll make this a part-time/short-term thing.”
- “We need a super SME who knows our product better than any end user. Someone who already knows what our customers need.”
- “How hard could it be? Ask the stakeholders what they want and prioritize it.“
- “We’ll tell you what the software is supposed to do. Just write all of the stories and make sure the stuff works.”
- “The team does all the work. You make sure they meet their deadlines.”
I’m arguing for some professionalization of product ownership. Product work is important: pivotal to building the right things. Good prioritization demands context and understanding and some strategy. And we need the deep knowledge that giving users everything that they ask for, exactly how they ask for it, is our fastest path to unusable bloatware.
For me, product ownership today is where software product management was 30 years ago.
Product ownership is a craft: acquiring and applying skills to the given situation. Product owners need to build deep relationships with their teams and customers/users; apply critical judgment; become expert at their tools. They do more than regurgitate what assorted stakeholders demand. Product owners get better with experience. Thoughtfully deciding the WHAT and the WHY are at least as important as HOW the team implements.
Ad hoc internal borrowing can work well for agile pilots and pioneers. We scan the organization, grab an appropriate product manager (or business analyst or customer-savvy tech lead or support engineer), and jump into our new agile adventure. Our first volunteers are enthusiastic, energy is high, and they can ignore their “old” jobs for a while.
But this doesn’t scale to large products or large organizations. The “borrowing” model falls down, since we don’t backfill the borrowed positions. For example… product managers who are full-time product owners start ignoring sales calls, pricing strategy sessions, analyst briefings, market-relevant benefits, competitive analysis, launch planning, user group meetings, EOL/migration, RFPs, and set-up of part numbers/ ordering info. When one person does too many jobs, all of those jobs suffer.
We also hit diminishing returns with the internal talent pool. Finding a few folks with good product-owner-ness is easy. But each incremental pick gets harder: we increasingly get no customer experience, fear of controversy, or the belief that “my users are exactly like me.” Imagine if we had to recruit all of our User Experience designers internally.
Finally, internal pseudo-hiring lets us be lazy. Stealing someone internally means not having to clearly define who/what we need. Our company would never hire an Accounts Payable Manager or Technical Trainer without a written job description, but we let random folks define our product.
SO, DO COMPANIES ACTUALLY HIRE PRODUCT OWNERS?
That’s a market question. I’ve had my research team go to the job boards several times over the last year to search for “product owner” listings, and look for job descriptions with the title “product owner.” (We did something similar for “product manager” jobs last year.)
Across the entire United States, there are almost no job postings for “product owner.” On 6/3/14, it looked like this:
With hundreds of thousands of agile teams, a scant few hundred product owner jobs are open nationwide. As of this morning, Indeed showed 23 product owner listings in the SF/Bay Area — the center of the software universe. (Try it yourself.) Product owner isn’t a job that HR departments know about, which means there’s no career path, no salary scale, and an assumption that PO’s will move back into a recognized job soon. No investment in experience, training or longevity. No direct route to professionalism.
WHAT THE FEW JOB POSTINGS TELL US
We downloaded and analyzed about 40 product owner postings specifically from tech companies (i.e. software/systems vendors, not internal IT organizations) to hear what the market says about product owners:
- About one third look like classic tech product managers: technical plus business background, previous roles as product manager/owner, MBAs, need to interact with multiple customer segments and understand market needs. This looks like title substitution.
- One third specifically say that the product owner works with an existing product manager. These are delegation-of-execution roles: deeply engineering-process-focused, working at the sprint level, with product-level prioritization and strategy set by a product manager. More junior, with limited ability to influence product direction.
- The rest are a mixed bag of sprint-level activity with no connection back to customers, products, markets or strategy. Hermetically sealed within engineering teams and providing scant market direction.
Most striking to me: most of these postings did not specify any job experience or actionable hiring criteria. Almost half did not ask for any agile experience; half didn’t call out any previous positions or degrees. If you were interviewing candidates based on these job descriptions, you’d be lost. This reinforces the idea that anyone can be a product owner with a few days of training.
WHAT ARE COMPANIES DOING INSTEAD?
If companies aren’t hiring product owners, they must be doing something else. Here’s what I’ve seen recently at large software companies with dozens/hundreds of agile teams:
- Some teams have don’t have any product owner. I get mostly shrugs or confusion to “Who is your product owner?” When pressed, they explain that a development manager or architect is writing user stories and lightly prioritizing the backlog.
- Absenteeism. Some product manager (or SME or analyst or stakeholder) is supposed to be playing product owner, but doesn’t show up very often. User stories are crap, the backlog is a mess and there are no acceptance criteria, but the team continues to churn out code and track story points.
- Fatally time-sliced. One product owner is assigned to four teams — or two teams plus a pre-existing job. Late nights, short tempers, mediocre stories, and trending toward absenteeism.
- Revolving door. Volunteer product owners come in for a few sprints, and then go back to their “real jobs” as fresh volunteers arrive. No continuity, inconsistent priorities, disagreements about intended users, endless splashing at the shallow end of the agile experience pool. Engineering does what it thinks is best, as it always has.
Hint: I’m not enthusiastic about any of these.
Development teams should be rioting in the hallways about underpowered product ownership. (Perhaps some are.) Absenteeism means we’re wasting precious energy building wrong things for misunderstood users. Rudderless agile lets us build the wrong products twice as fast as we did before. And developers rightfully hate that.
By the way, a US-based scrum team of 8 costs your company about $1.5M/year. If you have 20 teams with insufficient sprint-level and product-level direction, your CFO and VP Engineering should be asking some uncomfortable $30M questions.
WHAT TO DO?
This is a problem at multiple levels. We should…
- When we (as executives) decide that a huge engineering organization will “go agile,” let’s do the up-front math. 1000 developers implies ~125 scrum teams, which screams for 75+ full-time product owners. Not time-sliced, not borrowed, not interim, not hand-waved, not hypothetical, not covering their old jobs during nights/weekend, not budgeted for a year from now. A few of these may be borrowable, but most are incremental heads. Do we want to spend $200M/year on agile teams but not allocate any headcount for product direction?
- Decide if this is a delegation-only role (with a product manager or stakeholder to make all of the product-level decisions) or if our product owners will have to make politically astute trade-offs among market segments and competing sales teams. That should dramatically change our selection process and how much management access they need.
- Ask what skills and experience we need. At a minimum, non-newbies should have some agile experience; some time as a product owner/product manager; enough technical chops to avoid shunning by the development team; and some subject expertise. Heaps of empathy for real customers; great communication skills; decent organization skills; and experience quantifying value would all be handy. Write a job description, even if it never gets posted. Be thoughtful, be selective.
- A two-day CSPO workshop does not make anyone a product owner, any more than a weekend at a dude ranch makes you a cowboy. (Sorry.) Build a plan to help new product owners learn their craft. Look inside and outside for product-specific coaches/mentors. Spend some training money on LeanUX, product management, quality metrics, financial modeling and why enterprise selling is hard.
- Don’t let your customer request list become your roadmap. Kano analysis teaches us that letting current customers prioritize your backlog for you leads to market failure. Don’t let your product owners confuse “this is what the enhancement request says” with “understanding and solving real customer problems.”
- Ask teams if they can name their product owners. Then ask those product owners if they are dedicating the majority of their time/energy/love to the new role. If not, hire someone who can.
SOUND BYTE
We’re filling product owner slots internally, without much regard to skills or long-term success. Or leaving these slots open for development teams to fill as they may. That’s a road to market failure. We need to be thoughtful, intentional and organizationally savvy about picking and mentoring product owners.