The Lean Startup is a book about 21st century management. How does building a FRC robot and running a FRC team run into the same challenges Eric Ries identified in modern businesses? How is our FRC team a group of entrepreneurs?
As with all businesses, our team is constantly running into new challenges. These range from faulty parts and poor/rushed designs to social friction and lacking time. These challenges affect all teams and some fair better than others, in particular the older teams who have a method that works. These teams are like modern businesses that have been around for a while and have a way of doing things which has kept them relatively steady while newer teams like us are like startup companies trying to find a way to "win". Without the longstanding data, teams like ours are forced to operate in uncertainty and create a great new product, our robot, in a short period of time. This perfectly matches Ries's definition of entrepreneurship, "A human institution designed to create new products and services under conditions of extreme uncertainty".
Chapter 1: What is productivity? When building a FRC robot, what specifically is productivity? Based on this definition, was our team productive during the last build season?
Productivity is the ability to progress towards what you set out to develop in a timely and efficient manner. What you set out to develop depends on the company, it can be knowledge of a subject or a product that fills a specific need. In the case of building robots in FRC the goal is twofold, to teach students about STEM principles and to make an awesome robot. An extremely productive team could, at the end of the build season, have a robot that accomplishes what the team set out to make it do and know a lot about how said robot works. Productivity does not necessarily mean success though; not all productive teams will have an amazing robot, but they will have knowledge as to what went wrong and how to not do it again in the next cycle (build season). In this way they are working towards the end goal of a great robot and they have learned STEM principles (don't use cheap mechanum wheels if you can afford it) from their failure. Based on this definition, we were mildly productive in that we made a successful"ish" robot and learned a lot about designing it, but their was a lot of time put into debating and our design process was not very efficient.
Chapter 3: What did IMVU assume to be true when they designed their product? How did customers actually behave? Was there a faster and cheaper way to learn the lesson they learned?
It assumed that customers would not want to go through the hassle of changing to a new im system and bringing all of their friends with them. It turned out that the customers actually preferred having a separate system since it allowed them to meet new people, something 3D avatars are very good for, and they enjoyed the challenge of getting their friends to join. The obvious route to have found this out would have been to release their product heavily scaled back from their goal to see if people would even download it based on its description.
Chapter 3: What is something that we were unsure of last build season that we experimentally validated? Was there a faster way to learn what we learned?
A notable worry about our robot was that it would need a wider wheelbase than could fit inside of a basic frame. This led to one of our first prototypes having wheels the extensions which removed the stability problem, but would have required a large amount of structural reworking and time to make feasible. Debate on whether or not to keep these stalled design progress until we eventually just cut holes in the base frame and tried to tip the robot. after doing this, it was obviously more tippy, but not dangerously so. We could have found this out very easily with wooden frame, a stack of totes and 6 spots to put wheels (two fro the excess stability, and two for the all in frame).
Chapter 4: What assumptions did the Zappos founders make when they started their business? How did they test their assumptions more efficiently than the IMVU team?
The Zappos founders assumed that people would pay for shoes online. This was tested simply by making a limited website and seeing if people would buy the shoes. This was much more efficient than IMVU since it tested what the public wanted before any real work was put into the product.
One of the most important lessons I took from these chapters is to always test your assumptions. It is clear from the cases studies and information that you can't assume you are always right, and you need to test things to see if they are actually true. Another importing thing I learned is to do your tests and adjustments quickly so you can come up with what you set out to make faster.