Product Owners and Progressive Elaboration

I’ve recently heard challenges to the validity of the product owner role’s relevance.  Given that we “don’t know what the product needs to do up front” and we encourage teams to collaborate to detect “what the product needs to do” during the process, why do we need product owners?

I believe this challenge is one that makes sense deep within the process and the team – when looking at what the team is doing, from one sprint to the next.  However, I challenge the premise of the argument – but to do that, I need to shift your context from “inside the team” to “thinking about the firm.” 

The product owner role – in my opinion – makes sense in terms of the contributions to progressive elaboration.  The team “does know what the product needs to do up front,” even when it doesn’t.  Let me explain – it will make sense once you shift perspective.

I’ll describe what I mean first in a “firm-creating-a-project” setting, and follow that up by looking at the “firm-focused-on-IT-so-intensely-that-it-forgets-it’s-creating-a-product” setting.

Someone at the firm sets a strategy. They want to achieve X, or solve for Y, as part of realizing the vision of the firm.  A product manager devises the set of markets in which to compete, and how to approach each one of them.  Then the product manager determines the appropriate competitive market position for how the firm believes it can succeed.  This is “placing a bet.”

A product manager will determine how their product will achieve this particular market position. If we frame the problem from the “outside-in” we can begin to visualize it in three parts.

• Part One: Discover UCD approaches to discover which problems are important to solve, for the customers who have been deemed important.
• Part Two: Identify the alternatives those customers have as choices to solve these problems.
• Part Three: Speculate on what those competitors will be like in the future – at the point in time when the firm’s product will be released to market.

As the product manager, these inputs lead to a point of view about how “capable” your product needs to be, in the future, at addressing the specific problems you choose to focus on. These inputs will help you determine an approach to help you achieve X, or solve for Y,  for the customers you believe are important to your positioning strategy and who are important to your desired market presence.

Now with this strategy of “be better at problem Q for customer M” at the top of the list, you can progressively elaborate what exactly this means.

My assertion is that you do “know up front what the product needs to do” – it needs to help customer M be better at solving problem Q.  What you don’t know up front is how the product will do it.

How capable are you, as a firm, of being able to realize this strategy? Do you have the people in place, with the skills, who can be available to make it real?  Do you have and will you make available the resources to make it real?  How confident are you that you can?

A product manager (or  a product owner, precisely where the hand-off happens is something I’ve seen vary and I don’t have a strong point of view in 2017 about where it needs to, I think it’s too contextually dependent on the specifics of each firm to make a sweeping statement) can progressively develop the next level of detail.  Specifically, what does it mean to be “better at solving Q for M” and how much better does the customer need to be?  Hypotheses are better when they include both product management and UX disciplines of discovery – this is product-market-fit work, if I had to put a label on it.  It lives in the context of determining the market in which you want your product to fit and how.

Next up, your cross-functional team will propose solutions which are intended to achieve Q for M. This includes the product owner, providing clarification and specificity about Q for M and helping to shape the hypothesis that solution W will achieve Q for M given the customer’s perspective and environment.  This includes what most people not doing UX think of as UX.  I often describe it as developing innovative solutions to well-defined problems – which is a bit misleading. The feedback loops here are intended to assure problem-solution fit.  Specifically, how confident is the team in their belief that W will achieve Q for M_.  Add in the complexity of thinking abstractly – for any given problem/solution fit, how confident does the team need to be?  There are times when the risk of being wrong matters, and times when it doesn’t.  You can use the same approach when selecting Q for M in the first place.

Now, in the process of building W for Q for M, there is ongoing collaboration and clarification. The product owner role is there to provide answers to both emergent and latent questions from the rest of the team. Answering predictable questions which are now appropriate (time and context), and answering questions which have emerged as a function of the approach the team takes and what the team learns on the way.  This requires collaboration with the product manager for assuring answers are consistent with the strategic context.  Feedback on a prototype is either:

• (A) answering questions from a product owner/manager, or
• (B) getting better user experience inputs from a customer.

It almost always impacts problem-solution fit (W for Q for M), but only occasionally provides insight into the hypotheses that  Q for M  is the right problem to solve, or we know how to succeed in the market at product-market fit (Q for M).  I’ve yet to see anyone use this data to say, “we need a new strategy.” The greatest impact I’ve seen is “we now believe we cannot develop W for Q for M, we need to go find a different W”

That’s how I think about it – progressive elaboration.

Strategy > Market > Customer M > Problem Q for Customer M > Solution W for Q for M.

In the context of working without a net, when there is no articulation of vision, market strategy, or product strategy within which all of these decisions are being made – then yes, product owner role feels like order-taker.  I think that feeling comes when we try to learn the context in which W for Q for M makes sense, and we discover there “is no ‘there’ there.”  I believe this is the consequence of a problem upstream, not a structural flaw with the product owner role.  The lack of strategic guidance creates a flaw in the progressive elaboration model.

I started this article by saying I’d talk first about firms creating products, and secondly about IT organizations “doing stuff.” That was me being a bit cheeky.  The scenario is exactly the same for IT organizations.  The work being prioritized is still oriented around solving problems for customers /users, as a means to an end of realizing a strategic vision.

You’ll have to decide how many grains of salt with which to take this.  As I prefaced, this is a snapshot of my point of view in 2017.  Five years ago, the answer would have likely been different, and five years from now it’ll probably change again.  I would love to hear your thoughts on this – especially if you disagree – you will help me take the first steps on the journey towards my “five years from now” point of view.