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?