Early on, Marty Cagan defines the product management role nicely: “The product manager is responsible for defining—in detail—the product to be built, and validating that product with real customers and users.”
He also discusses the need to have a good relationship with engineering – otherwise you are “… in for some very long and frustrating days.” (True enough!) Marty points out one key to making the relationship work is that the product management/engineering relationship is a peer relationship; “As product manager, you are responsible for defining the right product, and your engineering counterpart is responsible for building the product right.”
It is clear the Marty Cagan has plenty of real-world experience, and he does talk about something that I’ve seen become an unfortunate reality: “Few words are more dreaded by product managers than being told by engineering: ‘No more new features! We need to stop and rewrite! Our code base is a mess, it can’t keep up with the number of users, it’s a house of cards, we can no longer maintain it or keep it running!’”
Marty places the responsibility for this squarely on the shoulders of product management, stating that, “the harsh truth is that it’s usually the fault of product management. The reason is that when this comes up, it’s usually because for several years, product managers have been pounding the engineering organization to deliver as many features as the engineering team possibly can produce.” Personally, I think that there are other contributors to this problem, including management. And the development organization should at least be pushing back and pointing out that this problem is in the making.
In terms of defining the right product, Marty has ten fundamental questions that need to be answered:
- Exactly what problem will this solve? (value proposition)
- For whom do we solve that problem? (target market)
- How big is the opportunity? (market size)
- How will we measure success? (metrics/revenue strategy)
- What alternatives are out there now? (competitive landscape)
- Why are we best suited to pursue this? (our differentiator)
- Why now? (market window)
- How will we get this product to market? (go-to-market strategy)
- What factors are critical to success? (solution requirements)
- Given the above, what’s the recommendation? (go or no-go)
I’ve been challenged with setting strategic direction for products, and I’ve had the same experience that Marty discusses – the one where it would be GREAT if all you needed to do was ask customers for what they want and they would tell you exactly what problem you needed to solve to collect a big pot of gold. Unfortunately, you usually get suggestions for incremental improvements to your existing products and not something more strategic.
Why? Marty Cagan explains: “Customers don’t know what’s possible. Most have no idea about the enabling technologies involved. Customers don’t know what they want. It’s very hard to envision the solution you want without actually seeing it.” In other words, you – as a product manager – need to combine an understanding of the user’s needs with “…an equally deep understanding of what’s just now possible.”
I also gravitated towards Marty’s notion of customers not envisioning a solution without actually seeing it. How many times in software development have projects undergone churn because users – who agreed to the (abstract) specification – apparently change their minds when they see the actual product? We’re an Agile shop, and delivering incrementally so that users can see features early helps, but it can still cause churn because you need to adapt the software to what is really needed.
And while the churn remains, Agile teams begin to understand more about what the users really want and can have better conversations about new features. The danger is that the churn gets disguised with Agile development because it gets spread throughout the process – and absorbed as the team’s “velocity.”
This is where I really like Marty’s advice: “The majority of the product spec should be the high-fidelity prototype… I have long argued that requirements (functionality) and design (user experience design) are intertwined and should be done together.”
Great stuff! Marty’s reasoning is that, “The primary reason to create a high-fidelity prototype is to help you gain a much deeper understanding of your product, and—ultimately—so that you can test your ideas with real users before you have your engineering teams take months to go build something that you have no real evidence will serve its purpose.”
As someone transitioning to a full-time product management role, I found that Inspired How To Create Products Customers Love provided me with an excellent, insightful perspective on product management from someone who has years of experience working in Agile and non-Agile environments. If you want to understand the realities of product management, I highly recommend this book!