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.