Why I built Autoplay?
We're in an era where building software is getting easier, but convincing users to adopt software is getting harder.
During my time at UChicago, I launched a mobile app and quickly found myself in a cycle of endless Zoom screen-sharing sessions, guiding users on how to use it. If I didn't show them how to get instant value, they would often move on. It was incredibly time-consuming, especially as the user base grew.
Later, at a high-growth Series A startup called Flowcode during my 8VC fellowship, we faced the same challenge on a greater scale, being a high-growth Series A startup iterating product quickly. We would ship features rapidly but had no way of knowing if they were being adopted optimally.
At my last company, where I met Sam, we lost a customer because of a feature they couldn't find in the settings. It was a wake-up call.
Today, building software is easier than ever, but user adoption is becoming more challenging. With user attention spans shrinking, the pressure to deliver immediate value is higher than ever. If users have to search for value in your software, they're likely to churn.
This is where Autoplay comes in, built on a few key insights:
Users don't want to use software for its own sake; they want to quickly achieve their goals. To do this, you need to understand their intention.
Users don't want to be told what they already know about your software (which explains why they ignore your tutorials and pop-ups).
Users are always more interested in learning how their peers use the same software for a specific goal.
The video game industry has some of the best adoption practices developed.