Democrateyes is democratizing beauty by bringing together experts to help consumers make informed decisions about makeup and skincare products and routines.
At NYU, computer science majors take a senior-level course called Software Engineering. Based on the IEEE curriculum, we're taught the waterfall model of web development. The problem with the waterfall approach, however, is that you invest massive amounts of time and effort into building a product before ever showing it to customers, and often it fails to live up to the customer’s expectations. So, I read about agile development and its concept of only building an MVP (Minimally Viable Product), and I vowed not to make the same this mistake.
“If all you have is a hammer, everything looks like a nail” - Proverb
As CTO of Democrateyes, and a web developer by trade, the fallacy of confirmation bias has been a hard lesson to learn. A MVP looks quite different for a coder and a non-coder. Prior to Democrateyes, my co-founder Rebecca and I built a prototyped product at a weekend hackathon... and then spent the next six months building the beta before showing it to a single customer. By the time we were ready to test the beta, we realized that the product we had built was for the wrong target market, and it would have taken months to rebuild it for our real customers. Although we hadn’t exactly done waterfall development, the result was the same.
For Democrateyes, we vowed to not waste time again. We decided to only build a truly minimal MVP. Rebecca and I attended some talks on prototyping (including a highly recommended talk on index card ideation at NYU-Poly by Josh Wexler). For this product, we spent a long time brainstorming together about what the product should look like before writing any code. Months before we started in the NYU Summer Launchpad, I heard Lindsey Gray (one of our Launchpad instructors) give a talk on the importance of product validation before diving deep into building. Inspired, we decided to try doing some customer validation before building our idea. We sent out a survey and got 200 responses, validating our hypothesis that customers have frustrations buying cosmetics products. This was great! But after that, we stopped trying to validate our idea and jumped straight into building. We had hammers (coding skills), so it would be minimally viable to just go ahead and build it, right? Wrong!
Rather than continuing to validate product-market fit, we switched gears to validating whether our product looked and worked right. We thought we were being agile by iterating on the product design itself, starting with paper prototypes and high-fidelity mockups using InVision and getting feedback on the UX before coding. Then we made our critical mistake. We spent the next 6 weeks holed up coding our “sorta-minimal” (but actually fully-functional) MVP. Because if we don’t unit test it, it must just be a prototype, right? Right??
We ended up pitching our "MVP" in the final round of NYU-Poly’s Innovention Competition, but didn’t win. We had a fully functional prototype, what gives? The problem was that we had built a great product, just not necessarily the right product.
During our first week at NYU's Summer Launchpad we were encouraged to conduct 15 customer development interviews. We found from our interviews that the product we’d built, a personalized makeup review site, wasn’t something that people were interested in and have transitioned accordingly. We’re now five weeks into the program, and I haven’t written a single line of code since we started. What I’ve learned is that the lean startup methodology isn’t about making a small product -- it’s about learning. So programmers, heed my advice: put away your IDE and take out your notebook. You have customers to talk to!
This post is part of the Lessons Learned series featuring NYU entrepreneurs’ first-hand accounts of challenges faced in starting a business and the lessons learned along the way.
