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?