Technical Product Owner

So here’s the problem: Some teams have stories that are very “technical” in nature. By technical I mean that these stories are usually development oriented (in language, and in subject matter) and they are hard to relate to direct customer value. Often these stories are related to maintenance activities that have a strong perceived need to be done by various stakeholders, but are not explicitly requested by our external customers. Some examples include:

  1. Stories requested by operations
  2. Stories that have to do with infrastructure improvements
  3. Stories related to technical debt

In some cases product owners have a real problem working with these stories. They complain that the stories refer to technologies or acronyms that they don’t understand. They maintain that they are a customer advocate and don’t care what the details are – just fix it. They don’t know how to judge when these stories are done.

To address this problem we have created a sub-category of product owner that we call a “technical” product owner. If you are starting to feel a bit squeamish at this point, I don’t blame you one bit. So who is a technical product owner? In this case it is usually the development lead for the team – or perhaps a director of development.

The solution is a well intentioned one, but there are consequences. The problems with using a “technical product owner” that I see in practice:

  1. The technical PO has no connection with the rest of the Product Management/Business/Customer organization. This basically sets the team up to operate without having to deliver value that the rest of the organization recognizes. It seems to aggravate silos within an organization.
  2. The Product Management (PO) team gets to ignore important decisions regarding the maintenance and upkeep of business systems. When you buy the car, you need to be responsible for it’s upkeep. All too often I know PO’s who refuse to address technical debt when it is brought to them. Instead they prioritize new features higher – sooner or later it comes back to haunt them.
  3. Teams get out of the habit of working with user stories that customers can relate too. Or they take perfectly good user stories and break them down into “technical stories”. There are all sorts of reasons this happens to teams – but we don’t want to codify the practice by creating a special “technical PO”.
  4. It can reflect an organization’s unwillingness to organize projects that are aligned across the organization rather than within technical silos.

Personally, I think that we should be able to put all stories – regardless of where they originate into terms that anyone can understand. Failure to do that may lead you down a path that leads to the “Technical Product Owner”. Watch out.

6 Responses to Technical Product Owner

  1. Alan Dayley says:

    Great article! Wish I had these points on the tip of my tongue during past conversations on this topic.

    Technical stories are where the trust between the Team and Product Owner is tested.

    Over time, the Product Owner should have earned the trust of the Team by guiding them to produce the best value for the company. Meanwhile, the Team has earned the Product Owner’s trust by delivering working product.

    Technical stories test trust the other direction. The Product Owner has to trust that the Team’s value choices are best for the company. This reversal of the value choice is hard for many Product Owners.

    A Technical Product Owner prevents the creation of this stronger trust.

  2. Sometimes we have no choice, especially when dealing with software that doesn’t nicely fit the classical IT project model. For example a user story like “as head of security I would like software to identify faces in a video feed against stored photos, to help control access to the building”

    That is a story that needs to be broken up further, but the customer is not going to be much help here. The difference is between domain complexity and technical complexity. Some projects have little technical complexity and can have their solutions expressed entirely in the customer language. In other software the domain can only reach so far as describing the problem, and perhaps forming a thin layer around the solution, and beyond that its all technical complexity.

    • Alan Dayley says:

      Your example story is an epic and does need to be broken further, as you say. Who should break it down?

      I suggest that the Team would have many questions for a non-technical Product Owner to correctly break that down.

      “How accurate does the face recognition need to be?” “How should the app notify security of a match?” “If by email, what is the content of the email?” “How many faces per minute must be recognized?”

      Such questions are customer or Product Owner focused and will lead to many non-technical stories. The stories should remain non-technical all the way down to the size that is deliverable within one sprint. This keeps the team focused on the business value and with a clear understanding of what needs to be delivered.

      How would you break down your example story? Why would it lead to “no choice” but to have technically focused stories?

  3. raghavan says:

    Nicely written.

    Sometimes the non-technical product owner would come up with a epic, ‘I want our service to be scalable in a way that it should be relatively quick and takes less effort to add more customers retaining the same responsiveness’

    The technical architect or the team are capable of breaking down into more technical stories to develop the new architecture. In this case, more input actually comes from the technical architect who decides on the acceptance criteria of each component.

    Can you suggest how else would you involve all the necessary people to complete the project?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: