What is the difference between a value proposition and positioning?

Help keep the social in social media

Your company's most important business process

The future of product management: Part 1

As a long-time product manager, I think it's only normal that I ponder the future of this fascinating discipline from time to time. I actually began this journey a few years ago when Prof. Dr. Alex Maedche and I wrote an article on the topic. Interestingly, we had trouble finding the right publication for the article. As far as I know, there are still no traditional publications, e.g., magazines, dedicated to PM (please correct me if I'm wrong).

In this post, I'd like to lay the foundation for this discussion by describing what I consider a fundamental challenge to our profession. I first need to describe an age-old paradigm for reasoning over almost any activity: the why, the what and the how. These dimensions are particularly important to the accountabilities associated with product development. "The why" describes our motivation for performing an activity. From a product development perspective, it encompasses questions like "What do we want to accomplish by developing the product?" and "What difference to we hope to make in the markets we serve?". "The what" refers to a functional (outside-in) description of the offering we'd like to take to market. For product managers, this means describing our product in enough detail that engineering can implement it (which we refer to as "the how").

Conventional wisdom holds that PM "owns" "the why" and "the what", with engineering carrying "the how" banner as previously noted. Herein lies the problem. It turns out that both "the why" and "the what" can be more than full-time jobs. The former involves defining the business motivation (strategy etc.), managing strategic relationships and doing business planning; the latter involves managing requirements, scoping releases and creating the roadmap. The following figure depicts these accountabilities graphically.

A natural question that follows from this paradigm is, "Would product teams be better served if there were independent disciplines accountable for each element?". I know this assertion will seem like heresy to many.

To repeat, the upshot of Part 1 of this series is that covering both "the why" and "the what" is a ton of work and, in practice, may stretch what is feasible for a single person. In my own experience, I found that at scale, much of the "driving" associated with the why was done by management while I was overwhelmed simply defining a product I thought the market would love.

What is your experience? Have you seen or been a victim of "why-what" overload?

Is product management art or science?

Are product managers confined to the problem space? PUH-lease...

Your approach to validation is broken

There's been tons of buzz about "validation" in the past several years. Lean and design-centric approaches such as Design Thinking encourage entrepreneurs to build things and incrementally validate them, correcting course as necessary. When I think about how, at the beginning of my career, we worked for months before validating anything, this increased focus on getting feedback from those who will use our product is most welcome. However, this obsession to validate what we build has, in practice, at least a couple of massive flaws that I'd like to highlight.

Firstly, I see almost exclusive focus on end users. While the people who directly use our products are important, the fact is that they are just one type of stakeholder. This point is a little less obvious in the Internet-based consumer space, where the user and economic buyer are the same and the buying process is much, much simpler than in the enterprise space. An individual consumer paying a couple of bucks for an app may (often?) make a decision based on little more than impulse. Those toiling away in the complex problem space where millions may be invested in a solution and with a fiduciary responsibility to stockholders tend to have buying processes that are dizzyingly complicated. We, as product managers must, therefore, validate ideas not just with end users, but with most or all stakeholders. Have we expressed our value proposition in a way that resonates with executive leadership? Do we have the right business model? Does our pricing model provide enterprise purchasing departments with the required financial flexibility? Overlooking these types of questions for these stakeholders may result in massive failure of a product that delights its end users.

Secondly, I find that most of what's written about validation focuses on the solution space. The idea is to build something quickly, test it, and "pivot" while it's still relatively cheap to do so. The problem is that we rush through our analysis of the problem space without validating that we clearly understand our stakeholders' key pains. Just like in solution validation, we rarely get it right on the first pass. Often, our understanding comes from anecdotal evidence ("I was talking to a customer the other day…") and flawed intuition. The first thing we should validate with stakeholders (not just users), is that we truly understand their problems. And here I'm not just talking about the problems we intend to solve. Understanding stakeholders' pain broadly helps us uncover acute pain we may have overlooked and helps put the problems we intend to solve in proper context. Laser-focused on our objectives, we begin to assume we are solving stakeholders' most critical problems although in many cases our solution, although important, is way, way down on our stakeholders' list of most pernicious issues. Before we even conceive of a solution (much less validate it), it is wise to validate our understanding of the problems that are holding our stakeholders back.

Problem validation entails the following steps:

1. Open, problem-oriented discussions with all important stakeholders
2. Distilling problems into a concise, consumable form
3. Validating our understanding of problems directly with stakeholders
4. Adapting our expression and understanding of problems as necessary

Just as fixing a prototype is far less expensive than fixing a shipping product, correcting misinterpretations of problems is much cheaper that reformulating a misguided solution, even as a prototype, later. I've blogged previously about the "Problem Profile", a valuable tool for considering problems holistically and validating them with stakeholders.

Your challenge is to resist the urge to validate too late, once you've already invested in the solution space. You will find that problem-centric analysis will yield insights that will never come from a solution-oriented approach.

What is your experience? Do you have practices in place to ensure you have a grasp of stakeholders' problems before you begin trying to conceive of and develop solutions?

You can read more about my strategic approach to product management on my site.