Don’t Build That Product
At the Agile Chef Conference I facilitated a workshop where participants could experience how Aikido can be used to resolve conflicts on the work floor as well by applying verbal Aikido. At the end of the session someone asked me to demonstrate the best defence against a sword attack; I responded by turning around and running as fast as I could.
So how is that in Product Management? what ideas are ideas you should really run away from?
The Three Amigos
As described in the Product Samurai, the three parameters for Product prioritisation are:
- Urgency (how bad is the problem we are solving)
- Pervasiveness (how big is the market segment)
- Willingness to pay (do people actually want to scratch that itch)
There is however a missing criteria that I deliberately left out: “can we make a business out of it.” I left it out because often it is too early to tell. What may seem like peanut business may grow to overtake the existing business, so one must give it a chance to grow. In the enterprise world, new products are often too small to make a dent (in the beginning.)
So be cautious, but there are however a few things to watch out for.
It’s the ROI stupid!
We looked at the why and the what, but we deliberately did not look at the how. That’s the responsibility of the Scrum team right? Well it turns out that it’s not all black and white. There are certain boundaries and guidelines that the Product Owner should know and use to guide the development.
Imagine a Customer Acquisition Cost (CAC) of x and an Average Monthly Revenue (AMR) of y over an typical time period that the customer is with you of z. It means that the Life Time Value of the customer (y * z) must exceed the CAC (x) plus the operational cost and a portion of the development.
For high churn products (low z) with low monthly rates (y) the CAC can’t be high, however it frequently is, especially in the beginning. Thus without a strategy to drive down the CAC or increasing the LTV, you simply can’t spend the resources.
(Geckoboard has some nice examples)
It can be a pervasive problem, and even and urgent one, but how often does it occur.
At one client the Product Owner had developed a great tool to help with the tax cycle at the end of the year. It focussed on addressing the anomalies that would not fit in the regular process, filing those improperly would have large implications.
It turned out, every department recognised the problem, but the manual entry they used was good enough. Furthermore, the problem was not exactly the same for all departments, hence the solution quickly spun out of control.
The Problem You Didn’t Know You Had
Then there is that unique thing that you found and that surely must be a disruption, it’s just that nobody is aware that the have this problem. Uber, the iPhone, Amazon, etc. Yes there is tremendous potential there, but reaching those customers (who are not looking) has little to do with technology, but everything with marketing.
Don’t build something awesome unless you have a way of attracting your customers. They have a way of not magically showing up on your doorstep.