Reflecting on "The Lean Startup" by Eric Ries

 Eric Ries, the author of “The Lean Startup”, explains that a functional specialist is accustomed to defining their efficiency by looking at how much time they’ve spent doing their work in each day. Meetings take them away from completing specific tasks therefore are considered wasteful. When co-workers come to their desk to ask questions or have informal discussions, they believe that their efficiency goes down. I, as an engineer, certainly have fallen under this category. For six years now I’ve worked for various organizations that rated my performance by measuring how many tasks I was able to complete in a period of time. That never sat well with me, because of my questioning attitude: “Why are we doing things this way?” Completing an MBA for me was a necessary path for my career objectives. I always knew I wanted to start my own company, but I always assumed I needed the perfect idea. I told myself “If only I can come up with that golden idea, I’ll quit my job and I’ll make it happen.”

“The Lean Startup” by Eric Ries and the MBA 6262 Entrepreneurship course opened my eyes to a different way of thinking about start-ups and entrepreneurship in general. Being an entrepreneur is not about executing an idea that you think is great, nor is it about convincing consumers that they want your product. In this course we learn that it’s a process. The main objective is that the entrepreneur tries to solve a pain point for a particular customer segment. You need to find alignment between their pain point and your value proposition. In his book, Ries presents a quote from Mark Cook (Kodak’s vice president of products): “Success is not delivering a feature; success is learning how to solve the customer’s problem.” My MBA 6262 group came up with an interesting idea for a start-up to develop a piece of software that would help people with their research. During our brainstorm activities we immediately jumped on the solution, the software. We came up with great features such as a plug-in that would track each article that the researcher reads and summarize its content. Another feature was an AI tool that compiles the articles you’ve read and gives the researcher a Cole’s notes, a summary of multiple articles. Our group was assuming that our customer segment included any student pursuing research and we expanded that to research professors and educational institutions. The biggest problem with our first approach here is that 1) we immediately started designing the solution and 2) we really had no idea who the customer was or what their pains were. We only had our own biased view of who the customers were. So, we incorrectly built a landing page from the first week. Before proceeding to validate our assumptions. As Ries put it, “no amount of design can anticipate the many complexities of bringing a product to life in the real world.” So, we were wasting time trying to come up with product features or trying to show potential customers an ‘image’ of what our product would be. Nonetheless, we had an initial idea: “A software that helps researchers”. As we were taught in the course, we developed a business model and in it we identified various value propositions for various customer segments. For each customer segment we had a differing revenue stream whether students would pay a subscription, or the software would be free, and we would include ‘Google ads.’ The entire business model relied on a minimum of 13 assumptions. An example of one of these assumptions was that the early adopters for our product will be professors and students. We included this assumption because in Ries’ book, he explains that we need to develop the early business model or solution not for the average customer, but for the early adopters. Those who will need your solution the most, those more willing to give feedback and those who tend to be more forgiving of mistakes. In my personal experience students and professors tend to be more liberal people. When completing my undergraduate degree, I worked with a group of 5 engineers and we decided to use a new software named “LateX”, a document processing software. The software was in early development but had been around for about a year, and I believe we were using their MVP. Consequently, we ran into a lot of issues, but that never deterred us because we thought the benefits outweighed the pain from the learning curve. We even reached out to the developers frequently and had open discussions about the problems we were encountering and the features we would love to see. For this young company, the information we were providing was very valuable. They proved that to us by giving us access to the software for free when it launched. The point I am making here is that this company was putting in conscious effort into getting to know us (the users) and they were trying to find out what a good product meant to us. As Ries puts it “If you don’t know who the customer is, you do not know what quality is.” Someone at that young company was successfully driving the message that it was important to have discussions with customers and not just concentrate on writing code all day.

Back to our MBA 6262 group project, we had that exact issue, we did not truly know who our customer was. We only had assumptions based on our own anecdotal experiences. The MBA 6262 course teaches us the process to use; hypothesise, discover, pivot, repeat, launch. We had identified our hypotheses (or assumptions) and we were now in the discovery phase. We reached out to potential customers through the use of surveys, and we conducted interviews through immediate contacts and through LinkedIn connections. We asked questions that directly helped validate our initial assumptions. If the question did not help us validate, it wasn’t worth asking. As Ries rightly put it, the conversations should not delve into the product features of our proposed solution and that’s exactly what we tried to avoid. In all, the validation process took us two weeks. During these two weeks we validated six assumptions, disproved one, and six assumptions must still be validated. Through this first validation exercise, our team concluded that the idea is still viable, and we subsequently updated our business model to version 2. In my opinion, the first validation cycle took too much time than it should have. As I mentioned above, you must get to know your customer, and what we found out was that the potential users of our solution are at their busiest at this time of year. In fact, over five people responded, “I’m sorry I’d love to help, but I’m writing my thesis defence for the next few weeks”, or “I’m sorry I’m right in my exam period”. So, we placed ourselves in their shoes and realized that January might be an even better time to get survey responses and interviews completed. Coming back from a break, students and professors would be well rested, clear minds, and have low stress levels. This, in my opinion would be a great time to get valuable feedback and complete the build-measure-learn cycle as many times as possible. As Eric Ries put it, the entrepreneur’s main objective should be to reach the pivot point of each cycle as fast as possible. You don’t want to be wasting resources on solutions that customers don’t want or need.

In my opinion, the hardest part of the process so far has been to focus on asking unbiased questions. It is difficult to ignore your proposed solution or at least not let it influence the direction of your conversations too much. Being myopic about your solution is all too easy, because after-all, to be an entrepreneur you must be passionate about what you are doing. You just have to be passionate about learning and identifying customers’ pain points.