There are many assumptions we make about the product or the customer problem, which makes us develop solutions that may be really more complicated than required.
A friend and fellow entrepreneur I met on Friday was showing me a prototype (HML mock up with transitions, with some simple functions implemented) of this SaaS application. He had used a developer on hire at UpWork to develop the initial version. After speaking to and confirming the mockup (wireframes) with 10 different users he was off to develop and deliver the MVP. Overall he had spent about $8000 in design and development and had taken about 13 weeks to develop the MVP. Most of the time was spent back and forth with the design team for the HTML / CSS and the development team for confirming features and transitions.
Of the 13 weeks, his development team spent 2 weeks just implementing a sign up process, a user cancellation process, a payment process, a refund process, a login process, a password retrieval process, etc. Which he did not realize was the tax of developing a SaaS solution. Instead he took the 5 step approach to building a SaaS application and followed it religiously.
The critical mistake during customer development that most entrepreneurs make is to lead with the solution or product instead of spending time learning about the current solutions.
When he was showing it to potential customers, he found that most of them liked the product and said they’d use it and pay for it, if they could find value in 2-3 weeks. He was pretty happy given that most users were ready to pay for the product, which he did believe would solve a critical problem for them.
After developing the MVP and letting his users know about the product, he followed up by asking them to start to use the application. The first two days were great, with lots of feedback and improvements that they gave him about the product.
Then for the next 3 days there was radio silence. Even after his prodding and cajoling, most users were not using the application.
Instead of talking to users face to face, he instead decided to spend time with them (3 hours each user), shadowing them to understand why they were not using the application.
Turns out most of the users needed his product, but either A) did not remember it existed or B) were used to using their workaround – largely using a combination of email and cut and paste into Slack.
The biggest barrier to his adoption and usage was their existing process (although inefficient) was something they were used to and so were able to “optimize” it to make it quick and “fast” for their own usage. So much that they felt that using his product (which I can assure you would be vastly superior) would slow them down.
He then pivoted his product (not idea) to implement the one feature they all wanted as a Chrome plugin. Which worked like a charm.
He then had to remove the top 3 features and undo all the user login and management, infrastructure code and other remaining features, just to support the user behavior for their existing process.
The big takeaway for him was that when you have a hammer, everything seems like a nail.
The biggest takeaway for his wife (who is his cofounder) was not over engineer the solution.
The big takeaway for me was the failed customer development process. With all our biases (which all of us have) – we always tend to lead with the solution (“let me show you a demo”), instead of understanding the problem better to focus on delivering the one feature that matters, without all the bells and whistles.
Image From: http://www.ritholtz.com/blog/2010/05/the-visual-guide-to-cognitive-biases/
