The critical accountabilities for product management effectiveness

I've written previously about product managers in name only, PMINOS. I would like to elaborate on those thoughts, this time focusing more at the organizational level. As part of my consulting practice, I regularly engage with software product organizations that have allocated product-related accountabilities in a way that I consider suboptimal. These experiences prompted me to describe the accountabilities I consider critical for product management to have the influence they should on the product business and life cycle long-term. To have an impact that significantly increases the long-term chances of product success, software products should have a product management function that unites accountability for:

• understanding customers and markets ("external perspective")
• defining and ensuring execution of product strategy
• operational oversight of development work outputs

Although some may consider the first point obvious, some organizations explicitly divide inbound and outbound perspectives in such a way that product managers spend little or no time talking to external stakeholders. I believe it is impossible to develop adequate empathy for stakeholders without direct exposure. Regardless of how tight the collaboration is with other professionals who engage with external stakeholders, PM cannot develop necessary customer understanding by proxy.

The definition and execution of product strategy may also seem like an obvious accountability to many, especially those in smaller product organizations. However, it is not at all uncommon to find product management organizations that are so overwhelmed by tactical challenges that they fail to define a compelling, explicit product strategy, leaving others to infer what they can or enabling others to define it for them. In terms of defining a strategy, I use the OMG Business Motivation Model as a reference model. It's worth noting that a lack of understanding and empathy for external stakeholders results in a strategy that is, put mildly, unlikely to increase the chances of commercial success. The product roadmap is the most practical expression of vision and strategy to all stakeholders. If PM doesn't own the roadmap, I would content there is no way for them to have the impact they should.

Operational oversight of development work outputs is a perhaps an overly fancy way of saying that someone with a strategic, customer-focused perspective needs to continuously engage with engineering as products are being developed to ensure the final product (or incremental product, for that matter) reflects customer wishes and organizational vision and strategy. Communicating insights regarding customer or market needs and educating engineering on business motivation in no way guarantees that development will stay on track as they, in good faith, set about developing complex products. Effective product managers spend a significant amount of their time assessing the work product of development and facilitating corrections as necessary. Offloading all oversight to a product owner who reports to development is a mistake that will eventually compromise execution strategy.

So there you have it, from an organizational perspective, leadership committed to long-term market success must ensure that these accountabilities are united in a healthy, empowered product management function. Would you agree? Is product management properly enabled in your organization? You can find more information on my offerings, including software product management training, on my site.

Reflections on (almost) a Year of Teaching Product Management

2015 is the first year that I delivered a software product management course that I developed. Aside from practical lessons in "instructional design"  and course promotion, experience with a multitude of students, both in public and "in-house" trainings, has given me insights into commonalities in PM experiences across countries, industries and company sizes and some surprises about the content that resonates most with folks.In terms of shared experience, it's clear to me now that most product managers are so mired in operational concerns that they've lost the reflex to take two steps back and think strategically. It's extremely gratifying to see people in the relative quiet of a classroom begin scribbling notes about strategic aspects of running a product they probably hadn't thought about in some time. Since most of my students were European, where product management maturity lags the US, it was also interesting to see them realize that they should be playing a clear leadership role in their organizations (and that no one will simply hand them that charter).

When I designed the course, I was concerned that participants would quickly become bored with theory, preferring insight on operational aspects of being a product manager. What I've found is that most practicing product managers have found their operational rhythm and can expect, at best, incremental improvements in this area. Much to my surprise, discussions about formally capturing "business motivation"  (vision, mission, objectives etc.) and aligning it across the organization generate much more discussion than approaches to release planning or managing requirements. This was a pleasant surprise as I believe thinking strategically is what separates most great product managers (and maybe professionals in general) from the rest.

BTW, at the "meta-level", I was surprised at how much value highly experienced software product managers got from an intensive three days of thinking about their job holistically. It turns out that this broad perspective (based on the ISPMAFramework) reminds them of aspects they don't typically think about and allows them to self-organize their accountabilities and priorities.If you're a practicing product manager or thinking about joining this profession, consider taking a course, even if it's billed as "basic" or "foundational". Getting out of the office and spending some time with folks who are facing similar challenges can be a great investment of a few days.

Originally posted on LinkedIn. You can find out more about me and my offerings on my site.

Will the real MVP please stand up...

The concept of "minimum viable product" has gotten plenty of press in the last several years, having become quite prominent in discussions regarding Lean startups. As I did some research for a course I'm developing, I noticed that multiple definitions have emerged which represent what appear to be different sets of expectations. In this post I'd like to share a few of those definitions and outline why I find some of the most popular ones either incomplete or somewhat naive. I'd also like to offer what I consider a superior definition. It turns out that the MVP concept is underpinned by even more fundamental concepts that require a surprising amount of level-setting in terms of terminology to be useful.

First, a few prominent definitions:

• Wikipedia: "In product development, the minimum viable product (MVP) is the product with the highest return on investment versus risk."
• Technopedia: "A minimum viable product (MVP) is a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product's initial users."
• Steve Blank: "The reality is that the minimum feature set is 1) a tactic to reduce wasted engineering hours (code left on the floor) and 2) to get the product in the hands of early visionary customers as soon as possible."
• Eric Reis: "the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

If I'm being direct (as I am wont to be), I, as a PM with experience in big B2B shops, find at least some aspects of almost all these definitions silly for a variety of reasons. To wit:

• Wikipedia says that MVP is a "product or Web site". Can't a Web site be a product? What is so special about a Web site that it should be distinguished from other products?
• In an apparent attempt to further fowl already murky waters, Technopedia labels MVP as an "engineering technique" and in the next paragraph calls it a "pared down version of a product". 
• The definition I infer from Steve Blank's blog post tells me that MVP is a "tactic" and (I guess) an approach to get the product in the hands of early adopters. It seems to me he's trying to describe why we would build an MVP (minimum feature set) without a precise definition of what it is. I also ask myself if MVP is relevant when I'm not concerned about early adoption. I contend it is.
• Eric Reis's definition is the one that resonates with me the most, although the special emphasis on learning rather than other business objectives seems a bit naïve or oversimplified outside the context of startups (I'll elaborate more on this point in a moment).

I think part of my dissatisfaction with popular definitions is that they seem overly startup-centric to me. I can assure you the MVP is relevant to virtually all software product organizations and absolutely critical in the complex enterprise B2B space. I also think the traditional concept is focused on the first release of the product, even though the underlying philosophy is hugely important throughout the entire product life cycle. I toyed with the idea of defining a "minimum viable release" (or something similar) but don't think an additional concept is really needed.

To derive what I consider a superior definition, I think we need to deconstruct MVP as a phrase, providing definitions for each word. I address them out of order to underscore which I consider to be causing the most confusion.

• product: In the software world, a product is software that I intend to ship to multiple customers in the exact same form and manage it throughout its life cycle. Shipping good software for one customer can be tough; doing it for multiple customers, especially over a set of increments (releases), is astronomically more difficult.
• viable: Here I interpret viability in the spirit of Tim Brown's innovation drivers, meaning that it represents the potential of the product to meet business ("economic") objectives
• minimum: While I don't think most folks have taken the time to provide clear definitions of the other parts of this phrase, I believe "minimum" is the word that causes the most divergence in terms of both definitions of MVP and people's intuition thereof.

So, here we go. Based on my experience shipping commercial software and in the light of the deficiencies I perceive in current definitions, allow me to present my definition of MVP as it relates to software (and a bit of decomposition for clarity):

The minimum viable product is the smallest increment of a product that is reasonably likely to produce desired business objectives, where:

• A product is software that is intended for delivery to multiple customers, where it will be managed over its life cycle.
• An increment is a version of a product delivered to customers that differs in terms of feature set from previous versions (typically implying an increase in feature scope and including no previous version at all)
• An objective (per OMG's Business Motivation Model) is a statement of an attainable, time-targeted, and measurable target that the enterprise seeks to meet in order to achieve its goals.
• I use the phrase "reasonably likely" as the use of the term "product" implies that we must define minimum scope before we deliver the product and thus cannot know if it will meet sensible business objectives
• The term "minimum" refers to the smallest functional increment of a product relative to other alternatives

A few relevant corollaries/elaborations:

• If it ain't delivered to customers with the intent of its passing through its life cycle there, it ain't a product. POCs, prototypes and other toys, while valuable, are not products by my definition.
• It is critical that we explicitly define "measures of success" (objectives) long before we deliver software to customers. Any other approach reduces product development to a hobby rather than a business.
• The term "minimum" implies that we are leaving features out that may cause customer dissatisfaction. Anticipating the degree of that dissatisfaction and its impact on our business objectives is a skill which often separates commercial success from failure.

I would say Eric Reis's definition comes the closest to my own if we acknowledge that learning is a legitimate business objective in some contexts. Thinking back on management teams I've worked for over the years, imagining my telling them that I'm going to invest months (or more) of development to deliver a complex enterprise product that will help me learn entertains me to no end. The idea of creating a prototype (as opposed to a product as I've defined it) to drive learning would have gone over much better with this crowd.

Digging a layer down regarding the motivation for defining MVP at all, I believe the fact that there is so much discussion on this topic is an acknowledgement of some hard-won lessons from commercial software development since its inception, namely:

• Most of us are in the software business, so product scope must be defined in the context of our commercial objectives
• The less we deliver, the less we tend to invest in development and the more likely we are to maintain commercial viability
• Shipping features should be avoided when possible as every one you deliver is a potential liability in terms of:
• Initial development costs
• Support costs throughout the product life cycle
• Security vulnerability
• Complexity that will eventually negatively impact business performance.

I could easily write more, including further definition of underlying terms like goals, life cycle etc., but alas, I am weary and want to digest this post myself before elaborating on it, likely in future posts. I would add that I believe profound discussions on this topic are valuable although the points may seem pedantic on the surface.

So what do you think of my definition? What is yours? What are your experiences shipping MVPs? You can find out more about my offerings, including software product management training, on my site.