IMVU: “But Does It Scale?” from Startup Lessons Learned Conference

  • 7,749 views
Uploaded on

IMVU: “But Does It Scale?” from Eric Ries' Startup Lessons Learned Conference, April 23, 2010 in San Francisco. The video presentation is available at http://bit.ly/bBpUcm

IMVU: “But Does It Scale?” from Eric Ries' Startup Lessons Learned Conference, April 23, 2010 in San Francisco. The video presentation is available at http://bit.ly/bBpUcm

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
7,749
On Slideshare
0
From Embeds
0
Number of Embeds
6

Actions

Shares
Downloads
105
Comments
0
Likes
13

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. An online community where members use 3D avatars to meet new people, chat, create and have fun with their friends
  • 2. Video of this presentation from the April 23, 2010 Startup Lessons Learned conference is available at http://bit.ly/bBpUcm 1
  • 3. But Does it Scale? The Evolution of Lean at IMVU Brett G. Durrett, James Birchler, Timothy Fitz IMVU, Inc. 2
  • 4. Introduction • Assumption audience is quite familiar with Lessons Learned blog • IMVU sometimes referred to as the original Lean Startup • Talking about how we now work and the learning that lead us here 3
  • 5. Quick Background • Customer Development & Lean principles lead company to tremendous growth • Fast development – everybody focused on getting new things into customers hands • No “golden gut” - customer metrics beat grand product vision • Inspirational environment – everybody empowered to make product decisions 4
  • 6. Success! IMVU Revenue by Quarter (in millions) $3.0 $2.5 $2.0 $1.5 $1.0 $0.5 $0.0 Q1'06 Q2'06 Q3'06 Q4'06 Q1'07 Q2'07 5
  • 7. Scaling Our Success • Product Owners for R&D, productizing, monetizing and keeping things running – Smaller, independent versions of company • Same successful philosophy and practices – Ship fast (but 2 month cycles feel slow) – Anybody can make product decisions – Customer-facing over infrastructure 6
  • 8. Not So Much IMVU Revenue by Quarter (in millions) $3.0 $2.5 $2.0 $1.5 $1.0 $0.5 $0.0 Q1'06 Q2'06 Q3'06 Q4'06 Q1'07 Q2'07 Q3'07 7
  • 9. Not So Much • Revenue dropped even though we were the using exact same philosophy and practices that delivered success • Product becoming “bucket of bolts” – Features abandoned because development teams disbanded / moved to new projects • Emphasis on customer-facing changes leads to increased technical debt 8
  • 10. Scaling This Success: Plan B • 7 “customer experience” product groups – acquisition, discovery, connection, etc. • Persistent feature ownership • Each group has key business metric – Conversion, retention, # chats, etc. – Combined metrics ultimately drive revenue 9
  • 11. Again, Not So Much IMVU Revenue by Quarter (in millions) $3.0 $2.5 $2.0 $1.5 $1.0 $0.5 $0.0 Q1'06 Q2'06 Q3'06 Q4'06 Q1'07 Q2'07 Q3'07 Q4'07 Q1'08 Q2'08 10
  • 12. Again, Not So Much • Revenue flat • Product still a “bucket of bolts” • Technical debt continues to pile up – Build infrastructure hindering development – Can’t iterate on IM client • Lack of progress leading to morale issues 11
  • 13. Key Failures • Didn’t align everybody for success – Competing metrics = adversarial owners – Authority disconnected from responsibility • 7 product teams = too small to be effective – No desire to apply limited team to tech debt • Focus on immediate customer feedback prevented “big bet” improvements – Bias favors features over infrastructure 12
  • 14. Scaling This Success: Plan C • Align organization for success • Strengthen product ownership – Support it with effective project management • Allow “big bets”, not just optimizations • Don’t lose the things that make us great! 13
  • 15. Getting Aligned • Officers determine business strategy – Shared (repeatedly) with all employees • All employees have same incentive plan – 2009 targets for profitability and revenue • Authority consistent with responsibility – Drive accountability – Required difficult changes to culture 14
  • 16. Stronger Product Ownership • VP Product clear mandate – Determines long-term product strategy – Aligns product owners to company strategy • Three product teams: product, monetization, keeping things running • Product Owners determine all product changes 15
  • 17. Project Management • Needed visibility into: – Where we spend development resources – Better ROI assessment when planning (the “I”) – What others are doing (transparency) • Resource Allocation – Product decides % of resources to each area – Engineering determines actual people • Variation of scrum, 2-3 week sprints 16
  • 18. Scrum at IMVU – How it Works • Product Owner, QA, Tech Lead pre-plan • Full team reviews detailed project planning • 3 engineers agree on task duration • Template tasks for all projects, esp. “Technical Review of Code Once Shipped”, which leads to work added to “Engineering Project Follow-up” lane • Engineers hand off code to Product Owner/QA with a feature demonstration 17
  • 19. Seeing the Big Picture • Passion for customer validation great • Obsession for immediate validation can distract you • Easy to lose sight of: – Product opportunities requiring a big bet – Increasing technical debt – Infrastructure needs 18
  • 20. Customer vs. Infrastructure • Customer facing features prioritized over infrastructure critical to early success • When it compromises ability to rapidly iterate a key strength is lost 19
  • 21. How Do You Know? “We are hiring smart people that can’t make changes to our code” 20
  • 22. Payback of Technical Debt • Dedicated technical investment projects • Some systems get a technical debt “tax” applied only when product changes • Tech Leads can add project requirement 21
  • 23. Build Infrastructure Overhead • Effective development systems require ongoing investment to scale – Impacts speed and morale • IMVU spending 20% of engineering on maintenance of the tests and process – Even with premium we find it has high ROI • Pain follows a square wave pattern as we scale the organization 22
  • 24. Example: New IM Client • Not previously possible – 1-year design and development – Substantial non-customer-facing infrastructure • Big win for customers and technical debt – Solved key issue confusing customers – Rate of development greatly accelerated • Iterated with customer validation! 23
  • 25. Example: Hack Week • Originally few requirements – Anybody can develop anything – Have to demo it at end of week (live) • New requirements – anything, but ship it or kill it – Each person allowed 1 project at a time – Product adopts it, keep building it or kill it – Limit customer exposure until adoption – Engineers need business data to make decisions! • Results – Much higher rate of projects getting to customers – Many engineers choose to work on existing product plan! 24
  • 26. Key Cultural Values We Kept • Customer metrics validate our decisions • Value everybody’s ability to contribute to product direction – Great ideas can come from anywhere • Culture of accepting failures so long as you learn (and improve) 25
  • 27. But Does it Scale? (Yes) IMVU Revenue by Quarter (in millions) $8 $7 $6 $5 $4 $3 $2 $1 $0 Qtr Q1'06 Q2'06 Q3'06 Q4'06 Q1'07 Q2'07 Q3'07 Q4'07 Q1'08 Q2'08 Q3'08 Q4'08 Q1'09 Q2'09 Q3'09 Q4'09 26
  • 28. Oh Yeah… Interested in getting more experience? We’re hiring! http://www.imvu.com/jobs/ 27