Future Trends in Enterprise Software Product Management

It's the time of year when we become inundated with articles and blog posts about what we can expect in 2016. Some brave folks even make predictions, something I am loathe to do as, let's face it, they will be wrong and nobody will remember I made them by the middle of February. Here's a list of topics I see impacting software product management in enterprise shops in the next few years (I believe there's no shortage of similar start-up-centric discussion these days). In the interest of brevity and to stimulate discussion, some of these points are made more "matter of fact-ly" than is probably appropriate. I'm looking forward to others' chiming in.

Internet of Things and SaaS
From a technology perspective, IoT and SaaS will continue to change the way product managers work and think. One might assume that these trends are reaching saturation based on the amount of ink they're getting in ICT press. One would be wrong. There is still a huge number of product managers that haven't yet made the leap to these new technologies/approaches or the changes they will inevitably bring to our profession.

Lean Startup in the Enterprise
Lean startup thinking pervades the startup world but is still somewhat foreign to more traditional organizations, especially the really big ones. In the next year or two, we'll see these concepts evolve and mature, becoming more prominent in "big shops" (not that they're entirely absent now). Radical ideas like "learning" being a reasonable objective for an early release will gain mainstream traction and we'll see some conspicuous success stories attributed to Lean Startup thinking in big shops.

Business-minded Development
The next few years will see more and more organizations investing directly in ensuring their engineers understand the business implications of their work. This knowledge will help them build solutions that better meet customers' needs and are more flexible over their lifetime. It will also increase the conflict in many organizations regarding who defines the product and where the line of demarcation between development and product management lies.

Subscription Fatigue
For enterprise vendors weary of their customers' slow, arcane capital investment processes, the recurring revenue that comes from a subscription model was as close to a blessing as one can expect in the software industry. However, both the consumer and enterprise markets are beginning to suffer from "subscription fatigue" as individuals and organizations take stock, adding up what they are spending on software every month. We will see more companies offering traditional pricing models to differentiate themselves from the subscription soup we are beginning to drown in.

Beyond "Pure" Scrum
Scrum has clearly reached a saturation point in the software industry. Over the next few years, we will see reinterpretations and extensions of Scrum become even more prominent in the enterprise, with proper methodologies filling in white space left by Scrum's "framework". Approaches to scaling Scrum that help resolve charter conflict on development teams will get the most traction.

Addiction to Data
Delivery of software products via the Web has created an unprecedented opportunity to gather information about usage, primarily because users are blissfully unaware that their every click is being tracked! Understanding how to define, gather and analyze this usage data will become a critical competency in the enterprise. Beyond up-skilling both functional and technical roles in this area, organizations will have to be careful not to abandon other valuable channels for gathering user feedback, e.g., (snark alert!) actually talking to them.

The Role of Design
Over the next few years, we will see the role of design as a discipline evolve in software product development. To paraphrase Steve Jobs (as so many of us are wont to do), it's not just about how it looks: it's how it works. Design is a science with quite a history that, to a great extent, has been applied only superficially (literally) in software development. The ascendancy of design will create yet more confusion regarding accountabilities on product teams, e.g., where does UX design end.

So what do you think? Are these trends relevant in your situation? What have I overlooked?

You can find out more about me and my training and consulting services on my site.

Being an effective product manager means saying "no" to more than scope

It's a well-worn truism that great product managers, perhaps more than other disciplines, need to know how and when to say "no". Typically, this "mandate to negate" is discussed in the context of product scope. Indeed, telling stakeholders (not just customers) that they won't get what they want when they want is as important as it is difficult. However, in this post, I'd like to explore a few areas in which "no" is just as important but that don't get the same press as "scope no".

Say "no" to "denial of service" scheduling

As product managers, we can get pulled in multiple directions by stakeholders who aren't even aware of each other. Our central role and broad accountabilities may lead us to believe that we need to be involved in all aspects of the product, business, functional and technical. I learned the hard way that the inability to regularly perform "brutal triage" on requests for your time can unleash a chain of events that undermines your credibility quickly and disastrously. A few tips:

• You can't be involved in everything. Having someone else, even from another organizational function like engineering, represent you, even at customer-facing meetings, may help others develop and allow you to focus on more critical immediate priorities.

• Look at your schedule every day and mark-up the meetings/activities that are strategic in nature. If you're not doing something strategic almost every day, there's a good chance you've been sucked into an operational death march at the expense of what your core competency should be: defining and driving product strategy.

• Be prepared to show clearly the opportunity costs involved when you have to resolve scheduling conflicts. Most of us have honed a similar skill when it comes to adding scope to a release ("OK. Now let's discuss what drops out.")

• Keep track weekly of roughly how much time you spend on key initiatives and make sure your investment is commensurate with their importance.

Say "no" to other professionals who expect you to do their jobs

Lots of lip service is paid to product managers' standing up and doing whatever's necessary to ensure product success, including doing marketing, support, sales or whatever else is required in a given situation. While these heroics may indeed be necessary from time to time, given the workload of all the product managers I know, consistently picking up the slack left by other disciplines is a recipe for disaster. Much better is to clearly articulate what you expect from these people and organizations and work with these other functions and their leadership to secure the necessary commitments. If these negotiations don't bear fruit, be prepared to articulate the impact of this work's not being done. In this unfortunate case, prioritize the gaps and do what is reasonable to fill them, never forgetting that neglecting your core duties to compensate for lack of organizational interest or investment is yet another (typically even more painful way) way to fail.

Say "no" to forgoing your life for your job

This one obviously isn't specific to product managers (perhaps the others aren't either). One thought that helps keep my priorities straight with respect to work/life balance is the realization that my grandkids won't care a bit about the projects I delivered during my career. Truth be told, there's a really good chance that I won't either! How much of yourself you give to your job and how much you give to the rest of your life is, over time, a decision.

What do you think? What other "dimensions of no" can you think of?

See my site for more information on my consulting and training services.

Titles related to product management matter and should reflect accountabilities

I enjoyed Hans-Bernd Kittlaus's blog post on titles ("names") and their significance (as I do most of what Hans-Bernd writes!). It turns out this subject is very topical with me as this question inevitably comes up when I'm working with consulting clients. My personal theory is that titles are important, but clear accountabilities in the organization are critical. When you consider that I believe that titles should reasonably reflect accountabilities, it becomes apparent why I recommend that software organizations not take this topic lightly.

I can remember in the 90s there was a brief trend to give oneself unconventional titles like "CEO and Bottle Washer" or "Chief Inspiration Officer". This relatively short-lived fad underscored one of the most important functions of titles: to communicate to internal and external audiences what you do (note the previous counter-examples).  Industry-standard titles like "product manager" or "solution manager" compensate with utility for their lack of sex appeal. These titles, however, beg more fundamental questions: What is a product and what is a solution?

I am consistently amazed that so many organizations that I encounter have no clear definition of what they take to market. I wrote an entire post on this topic almost a year ago, in which I proposed the following simple taxonomy:

• An offering is an umbrella concept representing anything that your organization takes to market for customers to consume. The rest of the concepts in this list are types of offerings.
• A product is a good, virtual or otherwise, that is developed and delivered to multiple customers in essentially the same form. Managing products throughout their life cycle presents challenges that I believe are an order of magnitude greater than managing deliverables from a customer-specific project. Transitioning from single-customer project deliverables to product delivery is a topic I've addressed previously in this blog.
• A service, in the context of offerings, is work performed by people for customers, whether it involves "knowledge work" or physical labor. Services are an under-served offering in many organizations, representing a way to add incremental customer value while strengthening customer relationships.
• A solution bundles products and services (and other solutions!) to solve customer problems. Solutions are very often customized heavily for individual customers. Market solutions are defined a priori and promoted in the market. Customer solutions are an instance of a solution delivered to a specific customer

I am a firm believer that from a functional definition perspective (product managers functionally design their product), it pays to be clear about your accountabilities. Are you defining a solution? Call yourself a solution manager or something similar. Same goes for products.  BTW, you should think about what you take to market from the perspective of you consumers. Even though a SaaS offering could be considered a service from a technical standpoint, per the definitions above, it is more likely to be considered a product by its consumers.

Does your title reflect your accountabilities? Do you have to explain what your really do every time you give someone your business card? Does the taxonomy I've proposed resonate with you? You can find out more about me and my offerings on my site.

SPM Intersections Video Blog: Is PM in the driver's seat?

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

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.

The Prioritization Matrix: Do spreadsheets really suck?

I'm a big fan of Roger Cauvin and his blog. If you don't read his stuff regularly, you should! He recently published a provocative blog post regarding spreadsheets (tables) many people use to prioritize product investments. I've had very different experiences with (and probably different expectations of) these tools so I thought I would share my personal findings. Not to sound defensive, but I consider this post just part of a conversation, not a rebuttal. BTW, my post will make much more sense if you read Roger's first.

I've been using an approach similar to what Roger describes for years. I call it a prioritization matrix. It's basically a list of things you want to prioritize scored based on a set of criteria. I'll structure this post based on the "three fatal flaws" Roger identified with this approach.

Organizational Dysfunction

In my experience, a simple, transparent method for prioritization helps address one of the key types of organizational dysfunction that leads to sub-optimal (read that as bad!) prioritization: political power or strong personalities trumping data and rational decision making. I've used prioritization matrices both for software investments and for investment decisions regarding entirely new businesses. On more occasions that I can count, I've seen senior leaders or overzealous advocates back off of entrenched positions when their pet investment fared poorly relative to others based on the matrix. This effect is partially dependent on the practice used to complete the matrix. More on that later.

Product Strategy Void

Roger contends that using the matrix exposes a lack of strategic alignment on the team. That hasn't been my experience. As a matter of fact, I've always used alignment with product/organizational strategy as one of the criteria. In my experience, some investments are clearly more "on strategy" than others. For this criterion to be meaningful, an organization must have an agreed upon strategy (something sorely missing all too often). I've written on the topic of the "business motivation model" before. This criterion becomes particularly relevant when some investments are being considered due to strong pressure from a single stakeholder like a key customer or highly opinionated exec.

Distraction from Unique Value Proposition

I agree with Roger's emphasis on the unique value proposition. Interestingly enough, in my experience at "power vendors", the unique value proposition rarely involved features and functions (often, prospects would rather do business with a name brand than a relatively small and unknown company, even if the latter has a superior product!). Regardless, much like product strategy, I would suggest making contribution to the unique value proposition one of the criteria.

I think my perspective on the flaws Roger enumerates is strongly influenced by the guidance I give clients and students regarding the use of such matrices and general expectations regarding the use of this kind of tool. Here are a couple points I consider critical:

Tools Can't Make Decisions

It's unrealistic to expect any tool, much less a simple one, to single-handedly drive complex prioritization. These tools are simply an input to the decision making process and can support a transparent process that makes decision making faster and more effective. As the person that is accountable for product success, you as a product manager will still have to make the final prioritization.

These Tools don't reliably do stack ranking

Far from truly stack-ranking proposed investments, in my experience, these tools tend to identify the following brackets or "buckets" relative to the items being prioritized:

• Investments that are clearly priorities
• Investments that probably aren't wise relative to other investments
• Items that need more thought or research

Put simply, a score of 39 (random number) doesn't mean an investment item is clearly superior to one with a score of 38.

Here are a few other relevant observations about the use of these tools that I've experienced:

• The key to using these tools is to have the right people at the table when using them and making decisions collaboratively (with time for discussion). Too many folks tends to lead to least common denominator decisions. 5 or so folks representing product management, development and executive leadership is usually a quorum.
• Once the team has used to the tool, scoring is extremely quick and efficient in my experience. I was on a team that prioritized relatively complex potential business ideas in 5 minutes or so per item. I'll write more about the practice we used in a future post.
• Assigning weights to the criteria and doing a weighted average can be valuable, although I've had really good luck using a simple average of 7-9 criteria.
• The process of completing the matrix and discussing it should be open, with efforts made to minimize undue influence by executive leaders. This is obviously a sticky wicket.
• The type of “items” being prioritized is important. Avoid prioritizing features as the matrix typically does a poor job of managing dependencies between them. From a product management perspective, I’ve had much better luck using user stories/epics etc. identifying a goal a type of user would like to achieve.
• I would consider using a scoring scale of 4 or 5 (not more). 4 is nice as it provides no “middle ground”.

In summary, I’ve been extremely happy with my use of these matrices. I've found them invaluable in keeping prioritization discussions structured and reasonably fair. Of course no tool or approach is perfect, so I think Roger’s post is valuable in identifying risks that should be considered and mitigated as necessary.

What is your experience using spreadsheets to prioritize product investments?

A simple exercise for pricing new products

In most of my product management experience, I have been spared much of the difficult work of defining my products' pricing model. The truth is, in big shops like IBM and Microsoft, there are dedicated professionals who have forgotten more about pricing than most of us will ever know; they are the ones that set the price (often against the complex backdrop of a huge, multi-faceted portfolio and opaque strategy). However, with smaller companies and startups, pricing can be a very difficult exercise that can easily take on the feel of "Voodoo Economics".

If you're product competes in a mature market, pricing is often fairly straightforward as your competitors and industry norms and history provide some guidance. In these instances, disruptive business models that change the pricing model can be fertile ground for innovating and avoiding simple (margin-sapping) price-wars.

If you're in a new market or even one that you're creating (the kind of "Blue Ocean" opportunity we should all be pursuing), defining a pricing model (metric, price point and discount schedule) can be daunting. In this post, I'll propose a simple practice that can provide some guidance, primarily in the B2B world where products must be positioned with prospects by sales professionals (solutions addressing complex problem spaces rarely go viral!).

In the case of complex B2B sales, a great way to stimulate creative thinking on pricing is to work backward from the sales pitch. I know this sounds obvious, but this approach is often overlooked. By definition, complex sales involve multiple decision-makers and influencers. There is a high probability that beginning with the first pitch, sales professionals will have to gradually refine a business case that begins with a concise expression of value. A crude example would be "Our product will save you around X Euros/Dollars/Won per year but only costs [some fraction of X]". In practice, the value proposition of many products isn't so clear, i.e., reducible to a obvious monetary value. Regardless, this type of logic will almost inevitably be employed.

To draft this pitch you should enlist the help of a sales professional. Before you do that though, you need to have dissected and decomposed the mythical entity known as "the customer". The truth is, when an organization buys your product, there are many stakeholders that, by definition, impact the sale: the economic buyer, influencers, end users, administrators etc. You need to understand each of these constituencies and have a solid idea (later to be validated with them) about "what's in it for them" relative to your product. Armed with these hypothesis and an intimate understanding of your product, you are now ready to speak directly with a customer-facing sales professional to draft a high-level pitch. In my experience, it won't take them long to identify the pricing messages and positioning they think will resonate with prospective customers.

Once you've elaborated the pitch a bit, you (with the help of sales, ideally) should do some direct validation with folks in your target market(s). Your goal is to find out if you understand their perception of value and which messages are most convincing. The variables in the equation can be tricky to determine, but its basic structure is simple: our product can generate a value of X but will only cost you some fraction of that amount. If you have close relationships with some members of your target market (clearly the right goal), you can begin analyzing what metric works for them, e.g., per processor, enterprise-level, and get their reaction to your proposed price point.

Coal Chutes in Your Software Product

I live in Heidelberg, Germany, an "old" city (since the 5th century!) that wears many of its "wrinkles" with pride. Plenty of old buildings in the oldest part of town have coal chutes that were used years ago to deliver fuel for long defunct heating systems. Staring at one of these anachronistic mechanisms as I write this, I've begun thinking about how many things that were once an absolute necessity are now obsolete. What can software product managers learn from these quaint reminders of a bygone era?

1. As your product evolves, the value of many of its critical features will erode

Keeping yourself aware of your product as a whole rather than focusing on its newest, most exciting features will help you identify its "coal chutes". Paying attention to trends in users' needs and habits can help make you aware of the darker corners of the product that are collecting cobwebs. Having statistics related to users' habits can provide critical data in this respect.

2. It's impossible to foresee all the features that will become obsolete, but that doesn't excuse you from thinking about them

As you design your product, ask yourself what assumptions you're making about what users need and how they accomplish their goals. Revisit these assumptions regularly to identify those that have been invalidated and begin planning the best ways to address these changes.

3. Sometimes out-of-date features represent threats

Just as some nefarious types will use an old coal chute as a point of entry for questionable activities inside of the building, your out-of-date features may provide unforeseen access points to your product or at the very least least project an image that isn't consistent with your product's current value proposition. Think seriously about the threats these old features represent and the cost of continuously mitigating them. Sometimes "bricking them in" or removing them all together is  a wise choice. These "remodels" may be expensive but can pay off in the long run.

So what do you think? Does your product have a coal chute or two that require some of your attention? Are you aware of the assumptions that underlie your products features and functions, including its UX? What is your plan to deal with them?

Agile development isn't enough

I was talking to a board member of a mid-size company a few weeks back about his biggest challenges. After over a year of struggle implementing Agile and changing a couple of products to be delivered as services (SaaS), one of his biggest pains was keeping marketing, sales and support up to speed as the release rhythm accelerated. After asking him a couple of questions regarding how product management engaged with these "functions" (luckily, he has an effective, empowered product management team), it became apparent to me that while PM and development had made great progress with respect to adopting Scrum, the other functions had been left behind!

On the surface, it seems obvious that if development is delivering releases at a higher frequency, sale's needs are going to change with respect to enablement and demos, for example; marketing's needs are going to change in a similar fashion. The same can be said about support, who moves from a model of "handover" a couple of times a year to continuously absorbing new changes, including new problems. Put simply, if you want to realize the benefits of Agile/Scrum or Lean or SaaS, the entire "train" will have to get on the track. That means frequent, managed engagement with all internal stakeholders, including IT. On that note, DevOps is the area that I see the most conspicuous acknowledgement of the need for the entire extended product team to adapt to new development approaches and techniques.

The days of waterfall development taught us that pulling in sales and marketing toward the end of the release is a mistake. These problems are exacerbated when release rhythm picks up. The answer? Creating continuous, efficient engagement with all stakeholders; it is probably the most important step you can take to ensure alignment, effective collaboration and maximum "throughput" end-to-end. The importance of making sure the leadership of these organizations understands what the change in development approach and product delivery means to them cannot be overstated.

What's your experience? Have you seen organizations that have gotten development on the Agile track but have left other parts of the organization behind?

Previous post: Balancing Release Investments with Simple Analytics

You can find more information about me (including upcoming training dates) at www.prickril.com.