This sketch shows a customer development story, wherein Bob the entrepreneur has an idea. He gets to work…
- Customer development methodology requires Bob to focus on that stack of questions right below him*. (Who is it for, what do they need, what does it do…)
- “Mary” is his design target*.
- As Bob works through the stack of questions, he needs to check to make sure his answers are good ones. He needs to make sure his product is something Mary responds to. If it’s not, he needs to revise his idea of the user and the product until there’s a good match.
- To save time, Bob should do quick prototypes — stories, paper, clickable — that he can take into his “is this right” checking process. (Fake it, then make it.)
When Bob is pretty sure his hypotheses are good, he starts to build.
In reality, Bob started building a little at a time, long ago, as each answer was validated. Every time he takes a new version of the emerging product to Mary for validation, he’s presenting a “Minimum Viable” product candidate. There isn’t only one MVP, there are several, and at each stage, Mary needs to prove her interest by exchanging some token of value — her attention, her email address, log-in credentials….and eventually money.
- As the product comes together and Mary is clearly happy with it, Bob needs to make sure it’s viable from a business perspective. Is someone willing to pay? And are they willing to pay enough to make it work.
- If it’s not, Bob has to start over. This big do-over is a “pivot” in customer development lingo. Either way, it’s back to the beginning for a do-over. Is there a better idea…for something Mary or another user might really need?
You know that you have product market fit when Mary is willing to pull out her wallet, and she would be very disappointed if Bob’s product went away.
* Each question is shown with a few suggested “lean user experience” methods…I’ll be writing about those in the future.
** Design Target: This isn’t necessarily the biggest user type, but the user who is the harbinger for all possible users of your product. The classic example is in-flight entertainment systems — if you design it for grandma and grandpa, and they can use it, then you’re sure that your road warriors will be able to use it, too. The same isn’t true of the reverse — the system created for road warriors wouldn’t work for the occasional, non-expert user.