This is the first of three linked posts revisiting the product owner /agile product manager challenge: two similarly named roles with strongly overlapping demands, but which IMHO are not the same. I’ve been wrestling with this collision since at least 2009.
In this series of posts, we’ll describe different kinds of projects/products and map the product management (PdM) skills that a product owner (PO) needs on those projects. In the final post, we’ll consider how to grow – or find – such skills, and suggest some teaming models for companies doing large-scale agile.
Buckle up for a long-form, more theoretical discussion. For something more lighthearted, try this.
Framing the argument:
- All agile (scrum) software projects need product owners. In that vast universe, product management skills are most critical for commercial software product owners. We’ll call out other situations where product owners are likely to need specific product management skills
- The broad agile community has a clear picture of product ownership, but little understanding of (or experience with) good product management. Conversely, product managers have been late to agile, usually miss the transformative opportunity of good product ownership, and tend toward outdated organizational models. These two camps have little overlap or mutual appreciation.
- For commercial software, the product management role is a superset of product ownership. That makes easy recipes such as “our product managers do all product owner work” naïve and unhelpful. At larger software companies, I see weak product management organizations with underserved agile teams, over-extended product managers, and lousy product ownership. We need to create product teams with a combination of skills – instead of heroic jacks-of-all-products.
- I want the managers of product owners to ask nuanced questions: What skills do our product owners need on which projects? How can we cultivate more customer/market/economic thinking where it’s needed?
A big agenda, segmented into several posts. (Congratulations on getting this far!)
Some Terminology
Agile/scrum demands a product owner: someone who represents the project’s customer or stakeholder, maintains a vision of the solution, and drives decisions (in part) through the backlog, sprint planning and story acceptance processes. Agile emphasizes roles, not titles, and team-level exploration to identify needed skills/experience. The literature rarely makes distinctions between commercial revenue software and internal projects, and ignores all aspects of product strategy.
Product manager is a formal job title, particularly at commercial tech companies, for individuals who drive product technology and make market-facing decisions intended to generate revenue. They set product strategy as well as implement it. They are heavily matrixed, often covering aspects of product marketing, sales support, external thought leadership and corporate strategy. ”
Po-TAY-to, pot-TAH-to? I don’t think so. I annotated a work content map back in 2009 showing that product managers have a much broader range of deliverables and responsibilities. In addition to getting the right product built, product managers own its core economic rationale (“How will this make us money? How much and when?”) and a sellable customer-side economic theory (“With our solutions, buyers can achieve savings of 15-30%…”).
IMO, this creates tension between narrowly defined software product management and narrowly defined product ownership:
- A product owner who also needs to completely cover product management inherits a broad, volatile, market-facing set of problems that he may not be expecting or trained for
Or reversing this:
- A product manager who fully commits to product ownership builds a wonderfully close relationship with his development team by sacrificing the essential first-person customer/field interactions that keep day-to-day product decisions relevant.
I’ve seen heroic individuals carry the full load. But not consistently or sustainably.
Rather than argue the goodness or appropriateness of each role, I propose a capabilities model: laying out a range of product owner situations, and highlighting where I think product owners need core product management skills. What projects or situations demand more “product-manager-ness” of our product owners?
Different Kinds Of Projects
Let’s lay out a framework.
I see dramatic structural differences between building software as a core revenue business, delivering technology to enable other products/services, and working on software for internal operational use. So we’ll sort projects depending on how directly our software creates top-line company revenue. Do we charge customers (via license, SaaS, appliance), does it play a strategic supporting role, or does it deliver internal cost savings?
Our second dimension is market divergence. How many potential customers are there, and how alike are they? This ranges from a single well-defined client to a semi-chaotic mass market of strategically different segments.
So a simplified software development universe looks like this:
A lot to tackle in one post, so we’ll dive into revenue software companies first. Then deal with software-enabled services and internal application consumers in two follow-on posts.
Within the revenue software band, we can imagine classes of products along the market divergence axis:
Market Divergence Spectrum for Commercial Software
[1] Contract software development is on the far left. Each project is a one-off effort, defined by the customer, so everyone knows who it’s for. If a client will pay for this work, has provided the specs, and we can build it profitably, then it’s good business.
[2] Some markets are oligopsonies, dominated by a few massive customers. If you build cell phone management applications for major telcos (AT&T, Verizon and Sprint) or chip design software for microprocessor companies (Intel, AMD and ARM) or navigation software for aircraft manufacturers (Boeing and Airbus), each dominant customer wants a customized product – and you don’t have enough other prospects to turn anyone away. So you grit your teeth, do what each customer demands, and build 3 (or 6) unique versions. Often, the customers often supply their own detailed requirements.
[3] Niche software. Cottage industries, such as the market for dental office management software, have small vendors selling to thousands of small customers. Marketing is typically underfunded, selling is less sophisticated, and entry prices are critical. Some firms are founded by disgruntled subject matter experts (e.g. ex-dentists) who assume that all customers are “like them.”
[4a] Mass market software companies have many competitors searching for large, profitable segments (audiences). Messaging, clear benefit/features, pricing, packaging/bundling, distribution channels and competitive positioning are as important as working software. B2C and small business products need huge numbers of prospects and relatively short sales cycles. Enterprise software is bought by committees, and takes a long time to close.
[4b] I’ve split marketing-led companies from sales-led companies, since we’ll identify a special kind of organizational chaos that enterprise sales teams create for their product teams.
What’s important about this scale? As you move to the right, there are more market elements to product success. More ways to segment the market; more customers with opposing needs; more competitive strategies available; increasing amounts of financial analysis to estimate profitability; alternate sales channels or partners; complex marketing/sales organizations that need frequent technical updates and positioned competitive responses. Product success depends on strategic marketing as much as agile process expertise.
A Product Skills Map
Having expanded out our revenue software quadrant, we can identify various product manager skills moving from left to right.
Demand for Product-Manager-Ness Among Commercial Software Companies
[1] Product owners handling contract development projects may not be very different from non-revenue product owners. They can personally sit down with the buyer/user to review specs, jointly accept completed stories and manage the backlog. Their organizations focus on individual deals, correctly estimating the work, and ruthlessly managing development costs/timelines to stay profitable.
Useful product manager-ish skills:
+ Identifying re-usable technology across projects, to create development-side efficiencies
+ Spotting customer themes, to point sales reps in more productive directs
+ Improving the pre-contract estimation process
[2] Suppliers to oligopsonies often resist product management. These are sales-driven companies, so “the deal is king.” There is still a lot of prioritization to do, though, as each customer demands one-off improvements and unreasonable deadlines.
These product owners need additional product manager-ish skills:
+ Strategies for combining product releases or versions. Addressing multiple customers’ needs with one configurable product is essential, and maintaining N+1 versions is tremendously expensive.
+ Delaying technical commitments until Development can review/size them (i.e. throwing your body in front of the Sales bus)
+ Sunsetting old releases to free up scarce resources, even when customers protest
+ Lobbying for investments in architecture and quality infrastructure, which have huge paybacks next year but cost money this quarter
[3] Niche players capture more value from product management thinking. Their slow, stable competitors can be caught unaware by pricing disruptions, thoughtful competitive analysis, and a focus on features that truly matter.
Niche-revenue product owners are looking more product-manager-like as they add these market-facing skills:
+ Pricing/packaging: Splitting out entry/standard/professional editions, and putting the right features in each version. SaaS vs. licensed models, monthly vs. annual payment, hardware bundles, professional service packages, competitive upgrades. Considering a freemium offering and estimating its impact on total revenue.
+ Research-based competitive analysis: tracking features competitors introduce, and how customer reacting. Thoughtfully de-positioning other players.
+ Trend-spotting: finding strategic opportunities in emerging technologies, new regulations, evolution of customer needs, and new sales channels.
[4a] In B2B and B2C mass markets, product management reflexes are make-or-break, life-or-death, IPO-or-downsize. An ideal product owner for mass-market commercial software must have great development-facing agile chops, all of the product skills listed above, plus
+ Marketing/sales experience: understanding the selling cycle, identifying product-related issues, and effectively teaming with Marketing/Sales
+ Customer-side subject matter expertise: ability to go head-to-head with your most sophisticated users, identify unarticulated needs, and find answers (if they exist) that don’t require development resources.
+ Dexterity with financial models: revenue forecasts, clearly articulated customer ROI, justifications for additional development resources, discounting. Mastery of Software Economics 101.
+ Gravitas: speaking thoughtfully, believably, honestly and honorably on behalf of the company. A customer commitment from a product owner/manager is binding on the company.
[4a] Finally, sales-driven software companies – with enterprise-style sales forces – present a unique challenge to product owners. When enterprise customers have slow purchasing processes, buying committees and internal political agendas, it’s hard to match individual features with revenue.
More importantly, companies richly reward sales reps adept at tilting decision-making in their favor. This invites organizational gridlock, though, as each sales rep lobbies for whatever today’s hot prospect claims to want. (Sales reps are paid to close deals, not worry about market/segment strategies.) In effect, enterprise software companies reward their highly persuasive sales professionals for injecting market chaos back into product planning — continually upending roadmaps/backlogs to push “their” special requests to the top of the backlog.
Which takes us to two critical, product-manager-ish skills for product owners at sales-driven software companies:
+ Aggressive filtering of sales-initiated interrupts. Product owners need enough organizational jiu jitsu to handle the hourly barrage of escalations and demands to derail the plan-of-record. They need unemotional pushback techniques and fact-driven questions: Are there work-arounds or third party solutions to solve the customer’s problem? Do we understand the problem? Is this deal likely to close? Is this feature truly the final blocker? Does the VP Sales have this deal in the quarter’s forecast?
+ Strong personal relationships with Sales management. Escalations are exhausting, and product management can’t navigate an adversarial relationship with Sales for very long. It’s essential to find executives who support for roadmaps, strategy and long-term investments in products.
So there’s our sequenced set of product manager-ish skills. Every organization is unique, but I hope my point is clear:
Revenue software demands market-facing skills/experience from its product owners (whatever we call them) well beyond the early scrum definitions of product ownership.
Obvious On Inspection?
This should be obvious. Yet I see two consistent failure patterns:
- Engineering-led organizations that don’t see (or don’t appreciate) market-sensing skills and field experience. They routinely assign product owners who lack product-manager-ness. “How hard could it be, after all, to talk with a few customers and find out what the market wants?”
- Product Management teams that don’t show up for agile. They half-heartedly write some epics or stories, dabble a bit in backlog grooming, and fly back out for a few weeks of revenue barnstorming. They never take advantage of the development team’s ability to change direction. They force Engineering to assign its own product owners, who have to guess what their distant product manager might want.
Workable solutions in larger companies usually include some truly committed agile product managers paired with eager-to-get-market-savvy product owners.
Summarizing This First Post
IMHO, the broad definition of product owner lacks the specifics of “product-manager-ness” that commercial products need to succeed.
Thoughtful software companies look for product owners (whatever we call them) that bring not only agile/scrum skills but also substantial market-side experience. Or assemble collaborative product teams with product managers (tilted toward market-sensing and cross-release portfolio issues) and product owners (to drive sprint/release-level success).
Follow-on posts:
– When do internal development projects need product management skills? What about technology-enabled services?
– Where do we find “product-manager-ness” and how do we grow more? What’s a collaborative product team?