Product Owners – What kind of product risk are you dealing with?

Posted on February 7th, 2011 in Agile, Kanban, Lean by siddharta || 5 Comments

I often meet Product Owners who don’t really understand the product they are building. This is sad because it means the product is doomed for failure right at the start. This is a single point of failure. All the benefits of agile software development and agile project management rest on one critical assumption – that the product owner understands what is being built. If the product owner doesn’t do a good job with managing the backlog, then it doesn’t matter if you have a the best agile team doing continuous deployments and one week sprints – you’re just doing to deliver the wrong product faster to market.

“What kind of product risk are you dealing with?”

This is the first question I ask when talking to a product owner. If you don’t understand this, then the project is in deep trouble right from the start.

Essentially, there are two types of product risk: Market risk and Technology risk

  • Market Risk is when you deliver a feature, but you aren’t sure whether the feature will be accepted or wanted by your customers.
  • Technology Risk is when there is a big question mark whether you will be able to build the technology in the first place.

Steve Blank has a great writeup about these two types of risk.

There are also two types of projects

  • Strategic projects are projects that have a key impact on the business strategy of the company. Most strategic projects have an unknown element to them.
  • Commodity projects are well understood, and are implemented to cut costs or increase efficiency, but do not have a direct impact on business strategy. Many enterprise software fall into this category, eg: Payroll systems or human resource management systems.

Strategic projects are generally exposed to either market or technology risk. In markets like Web 2.0, you mostly have market risk. There is no breakthrough invention or R&D you need to get the project out the door – most of the risk is whether you build the right product for your market or not. Other projects may have obvious markets and customer demand, but may involve a lot of technology invention and IP creation – these have primarily technology risk.

On the other hand, commodity projects are mostly well understood, have been implemented many times before, and have neither of these risks.

The reason product owners need to understand this is because it determines the base strategy for the release plan.

In commodity projects, the base strategy is to order the backlog based on business value. In fact, if you look at most scrum literature, this is the strategy that is usually described – put the highest business value items on top and the lowest at the bottom. Then all you need to do is to work through the backlog and build the software incrementally, making a release every sprint.

On the other hand, when the project is exposed to market or technology risk, then the primary focus should be on risk mitigation. In this case, the focus should be on learning and validation.

  • For market risk, you’ll want to build out cheap prototypes of core features and get potential users to use it and get their feedback.
  • For technology risk, you’ll want to focus on spikes that explore the solution space in a quest to understand how the product can be built.

In both cases, iterations are more important – you want to get the cycle time really short so that you can iterate on the right solution. The early backlog will have a lot of spikes. Quality is secondary. There is no point taking extra time to build a better quality prototype using test driven development or write a whole lot of automated functional tests, because there is a high probability that you will need to throw away many parts of the solution and start over again. Similarly, don’t get stuck up on the fact that you haven’t delivered end user business value for a few weeks, because thats not the point here.

Once you are confident that you have the risk covered, then the strategy can be switched over to a more conventional business value focused backlog. The interesting point here is how the process itself changes as the project goes along.


I’ll be expanding on this idea further in an upcoming webinar on Using Class of Service to Manage Risk. The webinar will happen on the 16th of February, 9:30 PM IST (See time in other timezones). Sign up for the webinar to join the discussion.

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

5 Responses to “Product Owners – What kind of product risk are you dealing with?”

  1. toolsforagile Says:

    Product Owners – What kind of product risk are you dealing with? –… #agile #scrum #kanban

  2. abuzitos Says:

    RT @toolsforagile: Product Owners – What kind of product risk are you dealing with? –… #agile #scrum #kanban

  3. Tweets that mention Product Owners – What kind of product risk are you dealing with? » Silver Stripe Blog » Blog Archive -- Says:

    […] This post was mentioned on Twitter by Nelson Abu S. R. Jr, Tools For Agile. Tools For Agile said: Product Owners – What kind of product risk are you dealing with? – #agile #scrum #kanban […]

  4. ScrumDog Says:

    RT @toolsforagile: Product Owners – What kind of product risk are you dealing with? –… #agile #scrum #kanban

  5. Elena Says:

    Thanks! Thats a great article!

Leave a Reply