Where’s the Product Management?
Henrik Kinberg of Crisp Consultants recently published a thorough, entertaining explanation of Agile Product Ownership in a Nutshell that I encourage product professionals to read/watch. It covers the activities of product owners really well.
It also serves as a good introduction for those not familiar with agile:
Kinberg touches on how to break up stories into bite-sized elements, how to use velocity and WIP limits as ways to manage capacity, how to impact velocity using automated testing, how to improve story size estimation, how to project when the engineering team will finish some amount of work, and how to communicate a projection back to the stakeholders. I really like the “communication back to stakeholders” approach, and I plan to try to use that at the office. But there’s a giant hole in the introduction:
“She doesn’t know the details of what her product is going to do, but she knows why we’re building the product, what problem it is going to solve, and for whom.”
This passage represents a common area of confusion between the software development role of “product owner” and the business role of “product manager.” One of the most insightful and worthwhile reads on that topic is Saeed Khan’s The Scrum Title ‘Product Owner’ Must Die!
B2B Product Development != Custom Software Development
The single product owner model is great for custom software being built for a single customer, and helps to solve the problem of product managers throwing a book of requirements over the wall to engineering and not helping solve the obvious follow-up questions about what is really needed. However, this model faces stiff challenges when scaled to commercial software shops, particularly in the B2B world.
Within that diagram, it is apparent that Product Management’s interaction with Development is only roughly a third of the product manager’s work. Let’s take a brief look at a few of those areas in more detail, and how they impact the way Kinberg sets the stage in that early statement:
1) “and for whom” – Let’s start here. Commercial software shops aren’t selling to a single customer, they’re selling to one or more market segments. Depending on the industry, these market segments differ from each other in usage or buying behavior, if not both. These distinctions may matter greatly or not at all depending on the industry, but should clearly be taken into account before decisions about product offerings are made. A further “for whom” distinction is especially relevant in B2B that results in a great deal of additional work:
- The User –This is the person using a piece of software, and is frequently the domain of the user experience team. Interaction design considers the nature of people using applications.Lots of detail can fall from identifying “the user,” a term which is too vague for proper interaction design. User personas should be identified and features should be crafted to target those personas and the relevant workflows (which must also be analyzed).
- The Buyer–This is the person(s) making buying decisions, who in B2B are usually NOT the same people who are using the system. Product marketing considers the buyer in great detail when it comes to messaging about the product, and understanding the buyer’s budget and buying process, so that the right messaging can be crafted. There may be features that the typical “user” won’t touch, but which are required to win over the buyer—for example, reports and dashboards.
2) “what problem it is going to solve” – Once the target market and market segments are identified, it follows that we can identify what problem needs to be solved for that market. It has been said by many—including Pragmatic Marketing, among others–that a product manager’s primary responsibility is delivery and market success of solutions to pervasive market problems that customers will pay to solve. Several parts of this definition are too important to simply be a small part of someone’s job:
- We may be talking about a number of problems, which should be solved with one or more products. This speaks to the role of product portfolio management, or offering the right combination of products to provide a cohesive and complete solution for one’s clients. Proficientz, among others, educates about this topic.
- If the problem(s) isn’t pervasive, you might build a product that solves a problem only a handful of customers have. Maybe it’s only a small market segment, or the squeaky wheels that call your support desk frequently, but pervasiveness of the problem cannot be assumed.
- If the problem is pervasive but people won’t pay to solve it, serious consideration should be given to whether a solution should be built at all. Early in my product management career, I led a team to define and build a product that the company decided to shelve before releasing to the market. The demoralizing lesson was that the reason I couldn’t write a convincing business case was because there wasn’t one to be made. Company leadership failed to demand we complete the business case, but passed us through the gate anyway.
3) “she knows why we’re building the product” – This implies understanding of who and what problem, and that build-vs.-buy-vs.-partner analysis has been completed. Companies offering more than one product have to consider core competencies, and think about the various options for acquiring capabilities. The current landscape offers the opportunity to find many capabilities in open-source toolkits to provide capabilities that aren’t core to a company’s value delivery. Making the right choices can speed time to market and help win in the marketplace.
4) “She doesn’t know the details of what her product is going to do” – This is generally true. Features aren’t broken to extreme detail until the detail is needed, as stated in the Kinberg presentation, to take advantage of learnings and to avoid detailing features which might be deprioritized. That said, a good deal of what the product is going to do is based upon who it’s being built for, and the problems it’s solving for them.
This video is a wonderful explanation of the agile product owner role. But it falls woefully short if one assumes that it covers everything required for the product manager who is serving as a product owner.
TL;DR Don’t forget about product management responsibilities if applying the agile product owner role in B2B!