Learning how to iterate and ship quickly

My First Year at IMVU and what I learned.

IMVU is known as the company that originated thinking around lean startup and CICD (Continuous Integration, Continuous Deployment). For me, the most formative element of working at IMVU was their data driven approach to all things product development.

While Intuit was known for a qualitative approach to interviewing customers, going to their homes to see how they solved problems, and leveraging those insights to build great product, IMVU was very much focused on rapid experimentation based on hypotheses backed with data (for reference, Eric Ries was a co-founder of IMVU and many of the lean startup principles originated at the company).

When I first started at IMVU (around 2009), the biggest realization was that the company talked in data terms. When features were shipped, the discussion was always around what the winning variant was, how much of an impact it had on user revenue, retention, etc. While at Intuit, we were trying to do a complicated Omniture implementation to improve our data instrumentation. Meanwhile, IMVU had a home grown tracking system for almost everything, including revenue, A/B tests, and user statistics. Many of the things we take for granted now (A/B testing, user event tracking, etc) were built in a homegrown way at IMVU before most of the popular platforms existed (Mixpanel, Amplitude, Optimizely, Google Optimize).

Because of this, IMVU is where I learned how to do rapid iteration on products and features. It was unique at the time (2009-2012) because only a few other companies had that level of speed and focus (Zynga, Facebook, and other social gaming companies are probably the best examples). However, for a young PM, there were a number of principles that emerged from this.

For one, notions of speed and data were inherent throughout the organization. IMVU was the first startup I joined, but beyond that, due to the principles underlying the company, everyone thought about the data that would be required to understand if a new feature or test had been positive from a customer perspective. During my first year, it was a crash course in breaking down projects to smaller component parts and finding ways to ship rapidly.

This was also a time when there was less institutional focus on teams built around growth or growth hacking (a term which is now more pejorative than it was in the early/mid 2010s). Therefore, learning to rapidly iterate at the top of an acquisition funnel, during onboarding, and throughout the monetization process was critical.

It was also a time when many of the trends established since were being formulated. It wasn’t the early days of the internet, but it was a time when asking users to install a toolbar to earn virtual currency was a completely acceptable and normal monetization tactic. We leveraged toolbars, offer walls, and a variety of tactics that are definitely less used and acceptable now. However, at the time users were willing to engage with those to get more in game currency and continue to build out their avatars. In many ways, it was a win-win, even though it didn’t always feel like it.

One of the most impressive elements of IMVU was the availability of tooling. Their A/B testing system ran analysis that I haven’t always seen repeated to this day. If you wanted to know short term, long term impact of your experiment across an incredibly wide variety of variables, it was easy to access and see.

The biggest learnings from joining a fast moving yet established startup:

• Thoughtful tooling and release processes really created an environment where testing hypotheses was easy and it was possible to get to learning much faster

• Making the barrier lower for PMs to work with developers and designers to rapidly ship made teams tight. Teams celebrated wins, discussed losses, and retrospected well. Because we were making rapid progress and not stuck on incredibly long dev cycles, we always had wins or other opportunities to discuss and learn from one another

• Data ruled everything, but there was a lot of empathy for users. Even though it was a strongly data driven organization and where I really learned how to leverage data to improve as a product manager, the company had deep empathy and understanding of its users and a very strong care team that was always engaging with the rest of the team

From a PM development perspective, I think there’s huge benefit here. For me, I came from a very qualitative place (Intuit) so getting deep exposure to data centric and fast moving product management was critical to advancing my career. And the flip side would also have been true, had I come from a quantitative place (like IMVU, or maybe other examples like Facebook, etc) it’s critical that you try to find a place to round out your product education to make you more user empathetic with a focus on talking to users, qualitative analysis, etc. The best product managers and leaders understand how to marry both sides of the product skillset to mix the art and science and deliver outstanding products.