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.

Requirements <> Features

Students from my software product management course would NEVER make this mistake! 

The Dimensions of Software Product Management: The Video

Thought I would address "in person" some of the topics I've covered in this blog. Plan of record is to do more! Let me know what you think!

Naivety in Product Management Discourse

As I read blogs, books and articles about product management these days, especially in the software world, mindshare seems to be centered much closer to the startup end of the spectrum than to that of the big/mature shops where I've spent my career. I guess I'm not that surprised: there are probably more startups than there are big, mature shops and, let's face it, startups are generally more exciting. However, I must admit that while I find many of the accompanying "new"  perspectives interesting, there are many topics or themes that strike me as (how to put this delicately?) a bit naïve. I'm a big fan of new, innovative ways at looking at developing software products, but for those starting their career in the enterprise space, I thought I would highlight a few areas for which some thinking popular these days doesn’t necessarily apply.

Customer = User

We are inundated in blog posts, podcasts and books with messages about "understanding the customer". I've noticed that more often than not, the expert/pundit/nameless internaut begins their post or presentation using the term "customer" only to subtly change gears and begin talking about the trials, tribulations and elation of end users. I guess that makes sense for consumer-oriented startups: the buyer is the customer. However, once you start selling to enterprises (whatever their size), you begin realizing that the term "customer", while it functions quite well as a conversational convenience, is, by itself, virtually meaningless. In the enterprise space,  understanding the "customer" means understanding a host of people, from the folks that cut the check for the product (economy buyers) to the folks that influence them to the various types of users that will interact with your product, from end users to the people who manage them to system administrators. Many of these people have conflicting requirements and, figuring out which are critical and which are merely important (or not important at all) is far from a trivial endeavor. Don't buy into the myth of the enterprise customer. Understand all of your stakeholders and manage them appropriately.

The Customer is King

The drive to be customer-focused (obsessed) in my experience has left many with an unbalanced perspective on product stakeholders, of which customers are just one. While the customer is of obvious import, the truth is, if you don't manage all critical stakeholders well, you can find yourself in the unfortunate position of making customers giddy with satisfaction and still failing! On numerous occasions in my career, I've had to prioritize stakeholders like executive management higher than customers, at least for a while. While it's not necessarily intuitive, executives, especially those whose egos have obscured their reason, can have radically different requirements than customers. For example, execs love for products in their portfolios to show thought leadership or to work well together, even if those aren't your customers' highest priority. Doing what makes customers happy while ignoring the needs of those who control your development funds can result in the swift and unceremonious demise of your product. At any given time, various stakeholders may be king, and not always the ones you expect.

Show me the money!

As a product manager, I hear a lot about "maximizing the profit" of a product over its lifetime. Recently, I hear about the value of learning, particularly from the startup camp. The truth is, for product managers in the enterprise space, your goals may be centered somewhere between these two extremes. On more than one occasion in my career, revenue and profit weren't nearly as important strategically as adoption. And I'm not talking about burning through investment capital while I figured out how to monetize my customer base or sell to the highest bidder. In big shops, goals like maintaining account control (by shipping products that prevent other vendors' getting a foothold, for example) may trump the pursuit of the almighty dollar (or Euro, or Real or Yen). That doesn't mean you should be aware of the revenue your product is generating: more often than not, management will eventually gauge success in terms of dollars and cents.

Product Management Owns the Product

We read about product managers'  being the mini-CEO of their product, accountable end-to-end for its success. The truth is, the level of accountability varies wildly between shops. Even in large, mature organization, a legacy of development-lead thinking can result in the PM finding themselves on the sidelines, making suggestions when given the opportunity and relegated to non-strategic tasks like creating sales collateral. I wrote about this unfortunate situation in my post about being a PMINO (product manager in name only).

In my consulting practice, I regularly engage with ostensibly successful companies with a relatively weak PM culture. In some cases, there is a power struggle that pits product managers against development, an ironic situation given the importance of trust and collaboration between these two disciplines. The upshot here is that you should understand to what extend the PM organization is empowered before signing on to join it. If you're happy  being a PMINO, then there's not much to think about. If you really want to take the reins and drive the product, you should prepare yourself for a typically complicated and lengthy change process.

Roadmaps are Overrated

I regularly read blogs and articles that treat roadmaps as relics of a bygone era, an artifact that represents outdated thinking that should be avoided. In many cases, customers in the enterprise space make multi-million dollar decisions based on what's committed to on a roadmap. While it's true that versions of the roadmap for different audiences are common in the enterprise space, dispensing with them entirely strikes me as a pipe dream, the current fascination with agility notwithstanding.

Quality is non-negotiable

While I don't hear this much from the startup crowd, who often value learning over revenue in the short-term, it's a refrain I've heard my entire career. While quality pundits make a convincing case for the criticality of high quality, I've learned the hard way that in the rush to get a product out the door, quality may be the first casualty. It's not fashionable to talk about, but at many times in my career I felt like my job was to ensure we didn't dip below the absolutely lowest level of acceptable quality. In the real world, time-to-market or not holding up the entire train (in cases when a portfolio has the same release heartbeat) trump quality way more often that anyone likes to admit. The lesson here is NOT to accept bad quality, but to accept that the level of quality can be a strategic consideration in ensuring the success of your product, especially short-term. BTW, over time, we, somewhat by necessity, got quality right, but, as they say, it's a journey.

So what differences in mindset do you see between the start-up crowd and folks in the enterprise space?

Product Management, UX and the Organization

I recently ran across a blog post from the great minds at brainmates regarding UX and the organization. This topic was top of mind with me as I had some deep conversations last week with students in my software product management course. I thought I'd chime in with my two cents on the topic and also address an area of traditional friction between product managers and UX.

Firstly, a definition may be in order. Although I've been working with UX professionals for over a decade (and have generally loved it), I still encounter people who have never had the opportunity to work directly with UX or are from an organization that doesn't have a UX function. In general, UX is a growing field that is responsible for creating the best user experience possible for software. Going well beyond "just" defining the user interface (UI), UX encompasses activities such as defining personas, designing prototypes and executing usability tests. I find the definition here reasonably complete. Even those of us with experience working with UX can be forgiven for sometimes being overwhelmed by the new UX-related roles that have developed over the years (and continue to). You can find an impressive list of roles/titles here.

I get a full body shudder when I think that at the beginning of my career (in the early 90's), I, as a developer, was expected to create UIs for the software I was coding. To my way of thinking, it was akin to asking a mechanic to design a beautiful car. Needless to say, end users suffered the now obvious down side of this arrangement.

Organizational setup is always a tricky topic. Let me start with my usual caveat: any organization structure can work. Organizational structure must be optimized for a variety of factors, including available skills, organizational legacy and even egos. In this post, I'd like to share important considerations for creating an organizational structure that is sustainable, i.e., one that is likely to survive the tribulations of changing priorities and personnel. In my courses, I always begin discussions about software product-related organizations making the distinction between the functional and technical perspectives. Essentially, the functional view is outside-in, the way a customer sees a product. The technical view is related to implementation or how something is built

Based on this distinction, it is clear to me that the vast majority of UX professionals are functional, i.e., they create designs for implementations but do not implement software themselves. In my mind, this means that having UX report to development (an organization with a technical perspective) is a mismatch. I think the best product decisions are made when there is a healthy tension between functional and technical perspectives, each keeping the other in check (within the context of shared goals). Ideally, UX, as a functional discipline, should be separate organizationally from engineering.

Does that mean UX should report to product management? I'm not so sure. In my (big shop) experience, UX professionals reported into a central organization, with a certain number of UX designers having a strong affinity with a product or set of products while the others floated around as needed. For example, experts in designing usability studies would engage with product development teams as necessary.

I've seen this centralized setup work well -- it provides consistency at the product level but is flexible enough to respond to changes in priorities and release schedules. When you consider that many UX organizations also play a role in UX governance (ensuring UI consistency, appropriate branding etc.), a centralized organization makes sense. In contrast to the brainmates post, I have never seen UX reporting directly to product management, although such alignment makes much more sense to me that their reporting to development.

UX reporting relationships can have important implications with respect to a typical source of conflict with product management: product accountability. I believe products are most successful when a single person is accountable end-to-end for their success. I would propose that product management should assume this accountability. However, UX is a well-evolved art and science and is often very highly empowered with respect to UX design (as they should be). This high level of influence begs the question, "When PM and UX disagree on something, e.g., how much investment to make in UI improvements in an upcoming release, who prevails?". While that question merits a blog post in itself, I can tell you that having UX report to a technically-oriented organization does not make resolution of such impasses easier. In cases in which product management is struggling to assume accountability for the direction of the product (as is often the case with product management is introduced), having UX in the development organization can seriously compromise PM authority.

By the way, the statement in the brainmates blog concerning "UX {being) closer to the customer" followed by a reference to "user goals" made me a bit uneasy. In the enterprise space, the term "customer" is almost meaningless. Typically, the people who buy and use the software are different and can have conflicting sets of perceptions and requirements. I plan to write a post about the "mythical" enterprise customer in the coming weeks.

In summary, while I think any organizational setup can work (at least for a while), I believe that the long-term benefit of having functional and technical concerns separated organizationally is a compelling reason to ensure that UX (clearly a functional discipline by my definition) doesn't report directly into engineering. In mature shops, I've seen a centralized, empowered UX organization function reasonably well, although issues like sufficient product knowledge and right-sizing of governance efforts must be closely managed. Finally, UX reporting to product management could make sense, but I simply haven't encountered it in companies I work or consult for. I'm curious if this is a trend in markets outside Europe or if it's simply a matter of chance that I haven't encountered such organizational setups.


What is your experience? Do you have a strong opinion about where UX should report? What is the organizational setup of your UX team? You can find out more about me and my offerings on my site.