Training Banner

Friday, September 25, 2015

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?


  1. Great post and point well made.

    I think most of the time when product people write about product management they write about how things should be, not how they actually are.
    During my relatively short product management career I've already encountered most of the things mentioned in this post. Nevertheless, I prefer to write about how I should've done it. It's like regular self-rehearsal to not forget the right way :)

    p.s. I would add to your list: Data driven decision making.
    It's been a buzz word of late. We all want to make decisions based on data, yet most of the times we instead search for data to backup our already made decision.

  2. I always learn something from your comments Daniil! Love the observation about people writing about how it should be, not how it is. Would make a great angle for a blog post!

  3. This comment has been removed by the author.

  4. Excellent post and I like especially the first part about understanding the difference between users and customers, and the importance of taking a really broad perspective of stakeholders.

    I like using the business model canvas for developing product strategy, and I see it this way: in the business model canvas, there is the „customer segments“ area. There, I would put in market segments. For example, for a B2B collaboration tool, I could have „marketing departments of large enterprises“, and in accompanying material I would capture the need of these departments to collaborate with external agencies regarding visual artifacts, and the problems they face doing this across firewalls etc.

    But that’s a market segment, not people.

    In order to develop compelling value propositions, and to get requirements right, I need to go a step further: identify key stakeholders in each target segment, and build people-centric models for each of them. For example, develop personas and work on a deep understanding of them through a value proposition canvas. To my understanding that’s what the startup world means when they talk about understanding „the customer“: not stopping with anonymous market segments, but instead understanding people and building people-centric models.

    Yes, some might be misled by the sloppy use of terminology and miss the distinction between buyers and users, or overlook the fact that there may be many more stakeholders involved, especially in products targeting large enterprise customers.

    The startup community emphasizes the importance of building people-centric models, not just for value propositions and requirements, but also in the metrics space (e.g. funnel metrics, cohorts etc.). And I believe that’s very helpful for building better products.

    1. Great points Barbara! My criticism is admittedly unfair as it generalizes. However, I'm convinced that there are substantive differences between the startup and "big shop" mindsets. To put a positive spin on it, these folks have a lot to learn from each other!

  5. And you thought I was exaggerating... "Roadmaps, estimates and deadlines are relics from the days of industrial manufacturing"-

  6. What color is the sky in your little world?

  7. Another might be the 'Fail fast, Fail often, Fail cheap' mantra of the startup community. While the spirit of the message is relevant for all Product teams, at the Enterprise Product end of the spectrum (mature/big IT vendors), there are additional considerations of an existing install base, brand name to protect amongst other factors that entail taking a different view of this oft-quoted statement regarding learning about customer pain points / market needs underpinning a product idea. Enterprise IT vendors face a different set of risk factors while assessing product-market fit for their new ideas.