Although over 6-1/2 years old, Marty Cagan’s “Product Management vs. Product Marketing” remains the Silicon Valley Product Group’s top blog article. (It’s entirely possible, of course, that it’s popularity is self-reinforced due to its prominent position on the SVPG home page…) While I generally agree with Marty’s premise and proposed solution, I believe that the article was written primarily from a Waterfall perspective and that an Agile perspective offers a better way out.

Marty makes the point that product managers are “responsible for defining—in detail—the product that the engineering team will build.” Product marketing managers, on the other hand, are “responsible for telling the world about this product.”

He then goes on to illustrate three types of dysfunction:

  1. A single manager defines high-level requirements and then sends the product to engineering, ” bypassing detailed product requirements and the many tough decisions that go along with that.” This is dysfunctional because these single managers are often Dilbert-style managers who are “way over their heads in trying to define in detail a useful and usable product.”
  2. A product marketing manager and product manager work together, presumably either in parallel or serial. The product marketing manager defines high-level requirements for the product manager, and then the product manager defines low level requirements for engineering. This creates a situation in which there is no true “owner” for the product, and the product manager is often reduced to mindless specification generators.
  3. A product marketing manager is asked to define both high-level and low-level requirements. It’s not only difficult to find someone who can do both jobs, it’s also simply difficult to do both jobs well in any sustainable work week.

I agree that there is some dysfunction in all of these scenarios. Marty’s solution is to clearly define the product marketing manager and product manager roles. The product manager should be “responsible for defining—in detail—the product to be built, and validate that product with real customers and users.” The product marketing manager, in turn, is “responsible for telling the world about that product, managing the product launch, providing tools for the sales channel to market and sell the product, and for leading key programs such as online marketing and influencer marketing programs.”

I think the point that Marty is trying to make here is that the product manager should defines the product with input from the product marketing manager and that the product marketing manager should take an important albeit somewhat subordinate role to the product manager.

This may be the best possible outcome in a Waterfall world. I agree that it would be very difficult for one person to successfully manage product marketing, user experience, and low-level requirements.

That said, it is not only possible but even ideal for a single product owner to own the end-to-end product, from conception to testing, development to release, and marketing to sunsetting. I think Jeff Sutherland, one of Scrum’s co-founders, would also agree: he suggests that a product owner must be able to balance “what you can implement,” “what you can sell,” and “what you can be passionate about.” This product manager is thus able to balance product execution and marketability while also being able to inspire a highly-functional team with the opportunity to work on a great product.

So what’s the solution? Perhaps this is obvious: Agile!

There’s rarely a reason for a product manager to write low-level requirements. In fact, telling a high-performance development team how to build the product will eviscerate their trust. This is because a team of developers (including folks with user experience backgrounds who should also be called developers*)—as a whole—knows how to build the product better than the product owner. And if they don’t? It’s probably time to find a new team.

So if they’re not writing low-level requirements, what should a successful product owner do?

  • Deliver a on-time product that delights customers and maximizes business value. (Jeff Sutherland)
  • Respond to change faster than competitors (Jeff)
  • Spend time with internal and external customers to understand exactly what they need (not necessarily what they say they want)
  • Clarify customer needs to development teams to reduce uncertainty (Jeff)
  • Defines the product functionality
    • Conditions of satisfaction (A.K.A. acceptance criteria)
  • Supports and enforces quality
    • Helps the team avoid and/or pay off technical debt
    • Supports automated testing and continuous integration/deployment, even if this means fewer feature releases
    • Enforces the Definition of Done
    • Supports the use of a “preflight checklist”
  • Be a “shit umbrella, not a shit funnel” (Todd Jackson, Google)
  • Ultimately, the product owner is accountable for winning in the market! (Jeff)
  • Be knowledgable, available, decisive, and accountable (Jeff)
  • Inspire the team by building trust and setting great goals
  • Build (or at least demand) a great team, then make them autonomous and get out of their way
  • To the extent possible, the product owner should behave like a Scrum Master by gaining and sharing Agile expertise, supporting the process, and helping remove impediments

What makes a great product owner? Great product owners:

  • Are servant leaders
  • Are honest and have integrity so that they may inspire and win the trust of their teams
  • Understand their customers and can strategize so that they select the right subset of product features and deploy them in the correct order
  • Fundamentally understand all aspects of a product’s lifecycle from conception to sunset
  • Fundamentally understand how the product is built (this Time Magazine interview with Apple’s Jonathan Ive does a wonderful job of illustrating this)
  • Have excellent taste, even if they cannot necessarily build products to those standards on their own

Given all that, it should be no surprise that product owners are often called the “CEO” of their product. If you believe this as I do, then you’ll likely agree that a) people who are cut out to be product owners are hard to find and b) product owners should be treated like the CEOs of their products. Some companies seem to shoulder their product owners with the burden of specifying every last detail whilst robbing them of decision-making powers. If a micromanaging CEO who can’t make decisions is unlikely to be successful, why should we expect a similar product manager (whether by personality or corporate burden) to be any more successful.

Customers won’t pay for comprehensive internal documentation, contract negotiations, or rigidly following a plan (the result of low-level, detailed requirements). They pay for working software, collaboration, and the ability to respond to their own rapidly-changing needs. This alone explains 75% of the Agile Manifesto. Since waste is anything the customer doesn’t want and isn’t willing to pay for, low-level detailed requirements are waste. Only those organizations in highly-regulated industries or who have extraordinarily past-thinking, bureaucratic customers will find some value in these detailed requirements.

What’s the cost of maintaining this low-level documentation? Speed. It doesn’t matter how many people you have assigned to a project, you will almost always be slower than a lean and mean team (e.g., your startup competitors). When even seemingly insurmountable barriers to entry can be cracked with clever solutions or disruptive technologies that can make entire markets obsolete, slow-moving dinosaurs are doomed.

So there you have it. It’s not a matter of hiring one person to market a product, another to write low-level requirements, and figuring out their roles. A good product owner can build and market a product. Find one and match them with a great team. Put the product owner’s “bacon” on the line, give them respect, resources, autonomy, demand continuous improvement, and defend them from bullshit. Your product owner will do the same for their team, resulting in hyper-performance.

* There are three roles on a Scrum/Kanban team: Product Owner, Scrum Master, and Developer. Whether their specific background is in QA, back-end, DBA, UX, UI, etc, all members of the delivery team should think of themselves as developers. This is intended to stop behavior like “Bobby’s the front-end person so that’s his job” or “We shouldn’t train Julie in Python because she’s a UX person.” This behavior creates silos and discourages cross-training, resulting in reduced team cohesion, performance, and adaptability.

CC image from a2gemma