Thursday, April 2, 2009

How Could This Product Fail?

Before you start in on a project (or a new business for that matter), do you ever stop and think, "How could this fail?" If not, you should. A product manager and I did this recently and came up with a potential way a major project my team was working on might fail. As a result of exploring this case, we ended up adding another treatment to our split-test experiment that we thought would mitigate the potential issue. Now we'll have the data during the initial experiment rather than having to burn weeks repeating it.

If you explore ways a project might fail before you undertake a project, in many cases you might be able to dig in and get some data that will either alleviate your concerns, or prove they're valid. Even if you decide to proceed, this paranoia may lead you to add additional metrics that you can monitor.

What are different ways projects can fail? Hmm, let me survey some the ways my projects have (or might have) failed over the years:
  • Lack of Distribution - Even if revenue or value per active user is excellent, overall value will be small if it doesn't touch very many. You can fail to gain distribution because you haven't inserted your product in a channel with very many users, or maybe you have, but it isn't attractive compared to other offers in the channel.
  • Customer Apathy - You get your offer in front of customers, but they just don't care. They may try it and even register, but they never come back. Many "viral" products fall into this category; their viral success gets the product in front of people who try it, and then completely purge it from their consciousness.
  • Not Incremental - The product gets used plenty, but its use displaces use of other products that generate equal or greater value per user. Inefficient.
  • Unintended Consequences - One example, to alleviate confusion between two choices you remove one, and people who formerly chose the other option now choose neither.
  • Low Coverage - Killer feature, when you have enough data to populate it, but it only shows up for one in a thousand users. No impact.
  • Too Expensive - Even if the project is considered a win, you took too long to deliver and sucked up too many resources in doing so. You'd have been better off doing other stuff instead.
Many of these risks can be surfaced ahead of time by gathering some metrics and doing some forecasting. Some can't, but you can still use fuzzy risks in your cost:benefit equation which informs your project sequencing. You can also structure your project to address the biggest risks earlier in the process and potentially fail fast if you can't surmount them.


No comments:

Post a Comment