Most of the readers are familiar with Agile methods, and most companies even know how to implement them in practice. (Not all do, but that is another topic and another post). Agile methodologies have improved SW development efficiency as an operation, one can argue. But how to be sure that what one develops delivers the best VALUE? Or that one creates truly innovative products, not just copying features from someone else? In short: how to succeed?
I told in my last post that even if one has a proper agile operation with themes, Epics well basically PO (product owner) and prioritized backlog, one can miss the mark. WHY? You might have the wrong backlog or the wrong product.
Lean startup methodology has a few but important, interesting concepts to add in to your product development front-end. Let's examine them further:
Of course, one should always to have a vision to start with. You have an innovation or an interesting concept you think will be big. You might be right, but how can you tell? Ask the user? But what and how? We do not have any customers yet.
In lean startup methodology one creates a set of assumptions that one tests with a MVP - minimum viable product.
Lets take an example. I have this vision that people could pay their bills straight from their email. The insurance/ gas etc company emails the bills, and they get paid digitally by users. First I create a set of assumptions that I need to test:
1. Banks would like this as less people would visit their physical branch offices and payments would happen remotely. Less money spent on bank walls.
2. People would like this as they would not need to visit the banks in person. Better experience as one needs to queue for a long time to get the turn at the bank desk.
3. Both banks and people would be willing to pay for this.
Now I need to test my assumptions, as we know not all we dream about are actually true. I need to build a MVP or several to test out my assumptions. You might spot that all the assumptions are on a quite high level, and a likely answer to those might be "yes, but it depends". The real product innovation lies in the implementation, and a more concrete test MVP is needed.
Let's assume I build a MVP, a product which is an email extension that fires up by clicking the bill attachment, and then guides me through the login process to the bank etc and lets me pay the bill.
OK, now I need to get feedback to the concept and assumptions by interviewing people. As this is a fictive example, I do not have the real data.
But I would argue that answers would be:
Yes, this is fine, and the Bank likes this concept, but the innovation here is only that the attachment opens the bank's web service. No more. One can open the bank's current web bank page even without and pay the bill.
Not enough willingness to pay for the service. Users would think that banks would need to offer this kind of service for free or as a part of a service package. No space for startup revenue here.
As a total summary of this innovation it is unlikely that the assumptions would be met. People with a laptop and an email account, is not probably that segment of people that visits the bank offices and builds the long queues by wanting to pay for their bills in person. So even with an innovative implementation the end benefit would not have been fulfilled. So people with email account can use the bank's web service.
NOTE that the strategy of asking the users which features to add, we would be after the wrong segment. (We look this in more detail in the next post).
So it is time to PIVOT. Pivoting is a lean startup term, and means that one needs to change the course - meaning to change one or several assumptions.
In the next post we figure what to do next. This spec did not work for us.
ps. Google is working on this kind of banking service - you might want to google Pony Express
ps 2. Note the question 3. Not many innovations and startups have a solid concept for monetization. You should build that in to the set of assumptions. You test, you know.