Friday, December 10, 2010

Single product owner model is broken. Problem and Solution team to the rescue?


It is more important to build the right thing than build the thing right. That's why this is important.

This post is based on personal experiences and the feedback that I've gotten from hundreds of individuals I've been working with: "Product owner (PO) model seems to be broken", "PO is a superman, nobody can do that", "single PO is bad idea" etc.

The motivations to write this is are: 1) find better models 2) provoke you to share about your experiences 3) provoke the community to challenge existing models 4) Books and courses about product ownership seem to concentrate on backlog management and scrum. I find that secondary to figuring out what should be done and when 5) .. finally describe the problem to some people asking me about "why do you think single product owner model is broken" in twitter. (@rowanb @hkokko @romanpichler @toolsforagile ...) :o)

What is a product owner by definition and how it is broken:

1. "the Product Owner, who is responsible for maximizing the value of the work that the Scrum Team does"
We together as organization are here to max value. It should not be only PO's responsibility though it might be a good idea to have one person looking after that value constantly. Team should challenge the value proposition that PO is stating in order to improve it. Team should be driven by the goal(s) to maximize the value instead of externalizing it to PO role.

2. ".. The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece ..."

This underlines the PO bottleneck problem. They are not truly POs requirements but stakeholders'/customer's requirements that are flowing trough a PO proxy. It is a bad idea to form such a bottleneck for information flow. In addition I would not like to have "one hearsay" talking about what the customer wants.

The guide and CSM courses have notion that ScrumMaster can teach PO. That's just naive - Most of the certified scrum masters/practitioners that I know have zero knowledge how to study the demand from the customer to understand how the value could be maximized. They often do know how to do backlog management.. but that is typing exercise once you know what needs to be build. Very few ScrumMasters know anything about customer development, business model generation, feature injection, defining MVP etc.

What makes this even worse is that organizations "promote" their POs from "ex-QA guy" or "ex-project manager" who has not been working with these kind of tools. CSPO (certified product owner) does not help here either - you get to hear about storymaps/product visioning, but it is not a product management/business analysis training (I am not saying it even should be).

3. "The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the Team performs."

Yes, we need one being eventually accountable might be the PO or might not.

Ensuring value is just a joke. Customer and your market will tell if you are producing value and you should not give that as "responsibility" to single person in your organization. I rather have transparency to the realized value all the time and want my people to think how to improve on it. For most of the organization "definition of done" ends to "stuff released" and they might be happy about their velocity ("we are so productive") but that all is meaningless as long as you do not measure the realized value and act on it (for instance by removing not used/invaluable features).

For project organization that works on subcontracting "stuff released" though might be "good enough" - if your contracts are not aligned with customer's goals (realized value).

4. "For commercial development, the Product Owner may be the product manager."
Not such a good idea. Here is a slide deck explaining the difference of there roles. One practical issue is that product managers are so busy on figuring out the problem to be solved that they won't be there to support the team (as PO role is defined)

5. "Committees may exist that advise or influence this person, but people who want to change an item’s priority have to convince the Product Owner."
So there we have it, we should have a team to help the PO.

PO is a collaborator for the team ... which is good ... but shouldn't he be studying and developing customers? Smell of contradicting priorities - who to serve and when. I do not want to have this bottleneck.

6. "The Product Owner identifies what has been done and what hasn’t been done."

Why? Why don't we have agree definitions and better transparency - we should all know when it is done and we all are working for the same goal.

On practical side of the things: we do not demonstrate the results of our work for our CEO (who could be the product owner) as we found that to be bottleneck for getting the stuff out. This of course requires that we have very good understanding of the goals and we have evolved our "Definition of Ready and Done" into something that our CEO can trust.

If you are subcontractor you might want to have the "demo acceptance" by "a customer representative". Context.

7. "The Product Owner is responsible for the Product Backlog, its contents, its availability, and its prioritization."

This leads to waiting as items are not available / good enough to be developed. The people doing the work are best to estimate when something is good enough to be developed - POs usually do not have that skill and if they are more than "backlog management PO proxies" they wont have the time to do this.

8. "The Product Owner keeps an updated Product Backlog list Release Backlog Burndown posted at all times."

Anyone can do this, it is about .. big word .. trust.

Context

You might find my angle weird. Take a look at this slide and ask yourself which product owner role you have in your organization. I am talking about big Ps preferably in goal driven context.

Alternative: Problem and Solution team

"All models are broken, but some are useful". Some are even more useful than others so here is model that I think works better than single PO model. Some might find this model familiar since it is mentioned several times in various #leanstartup sessions.

I start by sharing two diagrams: 1) customer development as a parallel process to product development. You might not be doing customer development but you are doing "something to figure out what should be done" - consider that as your parallel process.


Second diagram to demonstrate how the problem and solution teams are working on these processes:

The teams are working simultaneously, exchanging hypotheses, findings, problems and solutions.

Problem team

The goal of the problem team is to find out and define the problem to be solved. This team is all about "what".

Members:
- Sales
- Marketing
- Executive(s) (accountability)
- Technology
- Usability
- Quality (testing, QA/QC whatnot)
- Support

Solution team

The goal of the solution team is to figure out best possible way to solve the defined problem. This team is all about "how".

Members:
- Cross-functional development team including:
- Same technology representative who is in Problem team
- Same quality representative who is in Problem team
- Same usability representative who is in Problem team

Collaboration (overlapping)

Both teams try together to maximize the value. Problem team is trying to achieve this by figuring out who is the customer and what is a problem that is worth of solving. Solution team is providing transparency to the market feedback .. usually in form of solution based statistics.

.. within a context

Startup

In startup the teams may overlap heavily - it may be that the team members for both teams are the same.

Enterprise

In enterprise the teams may exist for each product line / project and the overlap might be restricted to only few team members.

Benefits compared to single product owner model

According to my experience problem-solution team model (compared to single product owner model) provides:
  • Improved information and knowledge sharing about the problem and the solution
  • Better alignment towards the goal and shared responsibility about value creation
  • Multiple views on customer's needs (for instance not only product vision but also architecture and usability vision)
  • Channel for constructive feedback (in a form of feedback loop from the solution team)
  • Multiple communication points avoiding the issue of "PO knows it all as he is only one talking to the customer"
  • Focus on shared team vision and discipline instead of "individuals and interactions"
Things to consider
  • If you are in a context where you just "execute the big-upfront-planned-requirements" .. you just need "requirements management"
  • If you need firewall for the team from several stakeholders then you might prefer single product owner model (or proxy between solution/problem teams)
  • Contracting model (in subcontracting) may prefer single product owner model
  • Maybe you do not need either models. You might have working model and your product managers in place with their MBAs - beware dogma - product ownership is a function to be carried out not a role :o)

Real life examples

Energized work product stream
Huitale's problem-solution team


Photo credit: Darwin Bell @ flickr

20 comments:

Ran said...

Instead of trying to form separate solution and problem teams I would consider cross functional product development teams. In many cases problems and solutions are highly coupled and finding a solution to a problem may redefine the rest of the problem domain.

Marko Taipale said...

@Ran Thanks for the comment.

I do not get your point. Both teams are already cross-functional as all functions are present.

The problem team is not working in _product_ development. They are doing customer development which is totally different process and contains totally different activities.

I am thinking how the standups would contain mostly irrelevant details for team members and the team would easily get way too big (for scrum atleast). Besides their cadences and workflows are different. Even co-location might not be good idea (sales and marketing speaking in the phone all the time/going outside the office)

You are right about the teams being highly coupled (in collaboration).

One might call the combination "a product team" or "stream" (See the Energized work implementation). Still that is really an artificial team as they share the common bigger goal, but are working daily for their internal goal (either figuring out what is the problem to be solved or the solution to the problem).

Would you like to elaborate how this team of yours would do their work in the team (how they would utilize the cross-functionality)?

Andreas said...

Hi Marko,

I think this is interesting, as I partly do encounter this phenomenon as a single PO. I have also had ideas about how to bring the customers (which I do not like to call the problem domain :) ) to the solution team. Petri Heiramos blog about story based vs. goal based was one insight into this, which I think partly same issue.

But I would rather not involve QA, technology, etc in the customer side, the domain. But rather make sure that the solution team comes closer to the customer, by e.g. receiving all the same customer intelligence as what you call the problem side does.

With this increased knowledge and input directly from the business, the addition of more competence to the team (user interface design primarily) and involvement in businessfollow up (i.e. realized value).

The solution team would be a bigger part of the PO role themselves and closer to the customer, having a better by-the-heart understanding of what is the right thing to do.

Br,
Andreas

Marko Taipale said...

@Andreas

Thank you for the insightful comment.

I think the "amount of overlap" (bringing QA/tech/... to the problem team) in contextual. The key is to understand that we need more bandwidth than single PO in order to create good products.

Ryan Shriver said...

Good read, I tend to agree that the expectations that the PO will figure it all out are beyond the grasp for most PO's I work with.

You may be interested in my work on Value over Velocity - the argument that teams over-focus on building features and under-focus on value creation (or even defining what value is!)

This is a model I'm using to help PO's (and the team) understand clearly what we're trying to accomplish before diving in and figuring out all the features we need to build to get there. Most teams start with features and ignore the real problems facing their stakeholders.

IMO, Agile's notion of the goal being "working software" just further re-inforces this problem.

-ryan

Marko Taipale said...

@ryan

Thank you for contributing.

I took a look at your presentation: Fixed link

#leanstartup talks a lot about the issue you raised. It's manifesto somewhat contradicts with agile manifesto:
* Validated learning over working software (or comprehensive documentation)

* Customer discovery over customer collaboration (or contract negotiation)

Personally I think your value delivery process could work in context of enterprise, but for startups it is all about getting out of the building. The tools we use in startups "before items hit the backlog" are mainly Customer Development (as defined by Steven Blank), Business Model Canvas for Business Model Generation.

Anyway, you are describing pretty much the same issue with a possible solution that I am concerned about.

Ran said...

@Marko Many of the problems in product development are communication problems. Having separate problem and solution team will create an organizational barrier between people that work in separate teams. I think this barrier is not needed.

I am just wondering what prevents the persons (sales, marketing, executives) in solution team to work directly with the problem teams when their input is needed.

Marko Taipale said...

@Ran

I agree about communication issues.

What do you mean "directly" and how that differs from the overlap I presented here?

I have not presented that team members (of each team) should not talk directly to the other team members (they can even be part both thanks to the the overlap), but that is different than "being one product development team".

The reason why they are separate teams is due to the difference in their internal goal and activities within.

Marko Taipale said...

@Ran

Just for an example: we have problem team that our solution team meets on regular basis (for brainstorming / designing the product increments) and yet there are members (including myself) who are part of the both teams. The interaction between the teams is pretty much daily, but still they are not the "same team" as the problem team needs to do lots of "figuring out the next problem to be solved".

That said I cannot really see the "barrier" that you are talking about.

Still all the models can be abused: if you form two teams (no individuals who are part of the both teams) and you establish strict (stupid) protocol (or even product owner role in between) then naturally you will hit the communication issues.

I am also interested to hear how do you do this today? Do you have single product owner model or something else?

Ran said...

@Marko I am happy that this solution works for you.

With "directly" I meant "without anyone or anything intervening".

I would be careful if the teams have different internal goals this could lead to suboptimal result for the company. I have seen this happen when there are different teams working in solution and problem space.

I agree that there is no model that is the silver bullet.

I have been working with several Product Owner models and to me they did not have much effect on the outcome. The main contributor of success in my experience has been collaboration, communication and common goal so I am trying to maximize them in any ways possible. Thus I am recommending as cross functional teams as possible keeping in mind that teams can not grow too big.

Niklas Kari said...

Very interesting post. Working as a PO and product manager I really know how much pressure the PO can be under from several directions. Your proposal of a problem and solution team sounds much like the way I am working with stakeholders and the development team, with the exception that apparently you don’t have a single person deciding the prioritization and the product vision. I am curious how you handle these issues and how you feel it works for you?

Some other reflections based on my experience. Since I am very busy, I have tried to have somewhat more light touch approach to the PO role in that I give the team a lot of responsibility in solving the user stories. Thus, my schedule doesn’t look anything like this: http://www.slideshare.net/mobile/Enthiosys/pm-and-po-at-agile-bazaar#13. I prepare and participate in sprint planning, grooming, review and retrospective, but much less in the actual implementation of the user stories although I am available for the team’s questions. I encourage the team to propose how to implement a story and I can then approve (or disapprove) the solution or help select between different alternative solutions.

Nevertheless, the PO work takes a lot of my time, and I have challenges doing all the other things that I am supposed to do (that superman comparison is spot on!). One of the things I try to get rid of is as much as possible of the ad-hoc tasks whether it comes from customers or executives, because such task can really spoil the fixed commitments that I have or make me work long hours or both. When feasible I try to delegate such tasks to my colleagues in product management. Instead I try to fill my calendar with predictable tasks such as updating product materials in conjunction with a release, preparing launch activities, engaging proactively (when it fits my calendar) with customers, sales and other stakeholders and so on.

Another way to save my time is to delegate PO responsibility for a user story to a subject matter expert. That person can then work closely with the team and approve the user story (although, if absolutely necessary, I could overrule that).

One alternative to the single PO model could be a duo consisting of a “small p” PO (dev team focus) and a “big P” PO (customer focus), with very close cooperation and clearly defined responsibility of who has the final say. Such an arrangement would alleviate at least my time pressures.

Marko Taipale said...

@Niklas

Great comment, thanks.

As a start-up we have the founding team that shares the product vision.

In case we have priorization issue (we seldomly have, but still), then our "shrinkable neck" is the CEO and he makes the final call. Our problem team is pretty happy with the current lead times so being "second" in the backlog / queue is not such big deal (average wait time for an item is 6 days).

Sounds that you are pretty much goal driven by letting the team to come up with best solution(s). Thank you for sharing your experience.

Andy said...

This seems similar to Pragmatic Marketing's Triad http://www.pragmaticmarketing.com/publications/magazine/7/5/product-management-triad

bendre said...

Hello - I am looking for advise and discussion on responsibility of Multiple product owners.

Definitely a good start and read here.
Question I have: Did you face situations where in multi PO scenario, only ONE PO is taking decision?

I don't think it's a right way. Cause even to create a Product backlog, the PO's must work in sync and have their definition of Done if they all are creating various deliverables that feed into product backlog.

What are your thoughts on this?

Marko Taipale said...

@bendre

We do not have multiple POs but actually a team of people who define the (valuable) problem to be solved and a team of people to solve the problem. That said we do not have the described issue.

In case we WOULD have multiple POs pushing items to the prodcut backlog we still have common definition of value (and risk). The priorization would be based on the value (/risk) instead "one making the decision". Things like Cost fo Delay would be considered.

I agree that POs (or problem team) must work in sync, but I do not get what do you mean with "they have definition of done".

We have Definition of Ready (DoR) for the BL items (to be ready to be pulled to the development) and then we have DoD for the items that are put into production. The DoR is common for all the items and is respected by everyone (PBL items must be compliant with it beore being pulled to the dev).

Colart said...

@colart

Thanks for this blog post!!It's both timely and very applicable.

It may just be a weird coincidence but I read "4 steps to epiphany" recently and have been moving towards setting up a Customer development team to support the PO function.

I'm assuming thats where you got the 'problem' half of the diagram from.

All the best

Colart Miles
Agile Evangelist @ Clarus

Charles Bradley said...

I'm not exactly sure how what you describe here is all that different from what the Scrum Guide describes.

You mention the PO as a proxy but it doesn't have to be that way.

The PO can lead a Customer team (or as you call it, a Problem team) where knowledge is gained and used as input to the Development Team (or as you call it, a Solution team).

The Scrum Guide doesn't go into detail about how the PO measures feature value, but just because it doesn't mention it in detail, doesn't mean one can't do it.

As a rule of thumb, I generally coach Product Owners to spend about 1/3 of their time in each sprint working with stakeholders to gather and assess the value of PBI's, 1/3 of their time working on PBI's for the next sprint, and 1/3 of their time working with the dev team on the PBI's for the current sprint.

These activities do not necessarily mean that the PO does all of the legwork, just that they lead the effort in that area.

Anonymous said...

A question: what is "usually in form of solution based statistics"?

Are you saying that making solution based on statistics data?

John Peltier said...

Thanks for sharing this via your comment! This problem/solution team concept is similar to the Product Discovery Team that Marty Cagan advocates. Both of these approaches are food for thought.

Most surprising to me is when I hear the SM should train the PO - as you state, SM is usually not of product management background so that just doesn't work.

gothandy said...

What a great post!

We have been trying to get our teams to engage directly with the stakeholder in our user stories, i.e the "As a ..." which is working very well in improving the flow of value through our business.

However we then struggle with the big picture. At the moment we're trying to grasp the concept of a "shared vision" to ensure the solution and prioritisation of the backlog meet the long term desired outcomes, early days.