I’m now one month away from the start of my senior year in college. The summer has gone by incredibly fast. I think it was around this time last summer where I was floating around the idea of trying to do my own EdTech thesis project.
I’m really glad I did it— I learned a lot about alternative education and met some really generous people along the way who I still keep in touch with. There was a point though where I started to wonder if there was something more to this than just writing about EdTech. How could I actually get involved with these ideas that I was excited to write about? There was also a bit of a credibility issue that I was guilty of — how could I really know what I was saying if I hadn’t ever worked at a startup? What did I know about creating a successful business? I had learned a great deal about industry insights and macro-level trends, but when it came to the nitty gritty of startups I was clueless.
So this summer I started interning at an edtech startup called Edgi Learning. In a way my EdTech project had come full circle when I joined Edgi. I first spoke with one of the cofounders last September when I was just starting out exploring the alternative education space. That same co founder is also an adjunct professor at NYU, and I took one of his classes in the spring semester before asking to join his team. Had I not done this EdTech project I probably would’ve never heard of Edgi Learning.
I’m learning a lot this summer and I wanted to start documenting these learnings.
As soon as I joined Edgi, I was immediately struck by the rapid pace of experimentation and iteration that was happening. There’s constant brainstorming of new ideas to improve our product, user onboarding, activation, and retention. I couldn’t keep up at first. And I still struggle to.
But that was my first lesson that I learned about operating at a startup — there’s an incredible amount of experimentation and iteration that goes on at the early stages.
The second lesson I learned was that there’s a quick pace to the experimentation, but it’s also not chaotic. We’re not trying to make changes to our product or onboarding all at once and hoping that something changes in our engagement metrics. Because if our engagement went up or down we would have a harder time identifying which specific change we made led to that increase or decrease. Experimentation is intentional, and making one / a few changes at a time allows you to truly know what changes actually make a difference.
You see this same experimentation process in baking. I don’t bake and will likely never, but my mom and sister bake very frequently and I sometimes join (I’m usually assigned the simplest tasks).
My mom and sister are very meticulous when it comes to baking — and they have to be because the smallest change can make the biggest difference. For example, my mom has been trying for the longest time to create the perfect croissant. Once she got the initial process and recipe down, she’s been trying to improve it slowly over time. After each bake she’ll analyze the results and think about what changes she wants to make on her next attempt.
But she’s careful not to make too many changes at once. Because how will she know which change was responsible for an improvement or worse result? Or was it all of them? If she doesn’t know which change or combination of changes are responsible for the improvement / worsening of the bake, she hasn’t made any progress towards the end goal of creating a repeatable recipe that produces great results. She might also take away the wrong lessons, further delaying her progress.
I think at a startup you have a similar goal of reaching that growth machine that keeps working or set of product features that increases retention dramatically — a repeatable recipe.
And to do that requires a lot of experimentation, but it’s preferably controlled experimentation with limited changes, so that you can come out with the right takeaways.
Update: Another good reason to not implement too many changes at once is that you’ll minimize confusing your users. This is definitely more applicable to consumer facing products, but if you’re making too many changes at once, it might overwhelm and confuse even your most loyal early adopters. At Edgi I’ve begun to learn the importance of always thinking about how a user might react to a change we make, and making clear and concise announcements to our community when we do make changes.
Let’s talk about education, startups, NYC, or if you’ve read other pieces that talk about the baking-startup analogy!
You can email me at alexyyang15@gmail.com or find me on Twitter.
