Similarly to a modern business, running a FRC team and building a robot can run into a multitude of challenges, be they related to design, scheduling, team morale, and more. Part of this is due to the similar nature of a FRC team to a business, in this case, a startup. Both often face extreme uncertainties throughout their lifetime, in the case of FRC, what next years game will be, and how we can prepare for it. Similar to entrepreneurs in these situations, we must adapt quickly, and attempt to experiment, and to 'go with the flow', as the phrase goes, allowing ourselves to tackle challenges as they appear, and to use a fluid strategy of experimentation to overcome our challenges.
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 a key part of every business, and by extension, our team. Productivity is, depending on your current business plan and philosophy, either achieving your set goals in a timely and efficient manner, or gathering the coveted validated learning, with as little waste as possible. When we build our robot, productivity is of the second type. We must attempt to learn all we can during the build process, as well as design and build new and improved ideas and designs for the robot without wasting time or manpower. Based on this definition and explanation, our last build season had room for improvement. A lot of time was spent designing systems we would eventually scrap, discussing the same ideas with different people, and backtracking to previous designs that were not given their due process. Now, to be fair, I was not on the design or build team during this process, so my knowledge is mainly second-hand and observation, and therefore may not be the most accurate.
Chapter 2: 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?
IMVU assumed that customers would would an inter-operable IM client that could function with existing clients, as customers would want to experience IMVU with their existing friends. In actuality, customers wanted to make new friends using the IMVU service, and they would prefer a dedicated IM client for the IMVU service. A faster way for Eric and his co-founders to learn this could have been to experiment with early users of the service, and to see what they wanted, as opposed to making and acting off a plan utilizing a multitude of assumptions.
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?
One of the many aspects of the robot that we were unsure of this last season was the idea of whether or not to load from the front of the robot or the back. We spent many hours near whiteboards, CAD models, and the bot itself trying to decide which way was best to load in totes. I suppose the process could have been expedited by spending more time just collecting raw data from the bot and our model of the chute.
One of the many aspects of the robot that we were unsure of this last season was the idea of whether or not to load from the front of the robot or the back. We spent many hours near whiteboards, CAD models, and the bot itself trying to decide which way was best to load in totes. I suppose the process could have been expedited by spending more time just collecting raw data from the bot and our model of the chute.
Chapter 4: Choose the Zappos, HP, Kodak, or Proctor & Gamble case study. What assumptions did the Zappos founders make when they started their business? How did they test their assumptions more efficiently than the IMVU team?
In the case of Zappos, the founder, Nick Swinmurn, assumed that customers would want to purchase shoes in an online setting. They also made assumptions relating to how important aspects of e-commerce would be handled, such as returns and customer support. These assumptions were tested nearly immediately, as opposed to the IMVU team, who spent a while developing assumed features and a business plan. Zappos instead started with experimentation, and evolved their business plan from that point.
Summary
In summary, this section of the reading contained a lot of information and anecdotes about how and why to experiment on assumptions when running a startup, as opposed to making a complex and strategic plan. They also discussed pivoting and persevering in your plan based upon your results from the experimentation. A lot of discussion was had about why experimentation was more effective than traditional market research, and how it is often helpful to allow early access customers to use a prototype model of your product, and develop from there. All in all, there were several important core elements to these effects discussed in these chapters.
In the case of Zappos, the founder, Nick Swinmurn, assumed that customers would want to purchase shoes in an online setting. They also made assumptions relating to how important aspects of e-commerce would be handled, such as returns and customer support. These assumptions were tested nearly immediately, as opposed to the IMVU team, who spent a while developing assumed features and a business plan. Zappos instead started with experimentation, and evolved their business plan from that point.
Summary
In summary, this section of the reading contained a lot of information and anecdotes about how and why to experiment on assumptions when running a startup, as opposed to making a complex and strategic plan. They also discussed pivoting and persevering in your plan based upon your results from the experimentation. A lot of discussion was had about why experimentation was more effective than traditional market research, and how it is often helpful to allow early access customers to use a prototype model of your product, and develop from there. All in all, there were several important core elements to these effects discussed in these chapters.
I also agree with how you compared businesses to an FRC team. I also agree that we have to 'go with the flow'.
ReplyDeleteThe front vs. back load was a notable problem and while there was argument on it, we accidentally did a version of experimentation. We were able to bypass all of the argument on the subject after our prototype turned out just to small to handle back loading forcing us into our current solution due to weight.
ReplyDeleteThe front vs. back load was a notable problem and while there was argument on it, we accidentally did a version of experimentation. We were able to bypass all of the argument on the subject after our prototype turned out just to small to handle back loading forcing us into our current solution due to weight.
ReplyDelete