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

Post on 13-May-2015

8.090 views 3 download

Tags:

description

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

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

An online community where members use 3D avatars

to meet new people, chat, create

and have fun with their friends

1

Video of this presentation from the

April 23, 2010 Startup Lessons Learned

conference is available at

http://bit.ly/bBpUcm

2

But Does it Scale?The Evolution of Lean at IMVU

Brett G. Durrett, James Birchler, Timothy Fitz

IMVU, Inc.

3

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

4

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

5

Success!

$0.0

$0.5

$1.0

$1.5

$2.0

$2.5

$3.0

Q1'06 Q2'06 Q3'06 Q4'06 Q1'07 Q2'07

IMVU Revenue by Quarter (in millions)

6

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

7

Not So Much

$0.0

$0.5

$1.0

$1.5

$2.0

$2.5

$3.0

Q1'06 Q2'06 Q3'06 Q4'06 Q1'07 Q2'07 Q3'07

IMVU Revenue by Quarter (in millions)

8

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

9

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

10

Again, Not So Much

$0.0

$0.5

$1.0

$1.5

$2.0

$2.5

$3.0

Q1'06 Q2'06 Q3'06 Q4'06 Q1'07 Q2'07 Q3'07 Q4'07 Q1'08 Q2'08

IMVU Revenue by Quarter (in millions)

11

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

12

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

13

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!

14

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

15

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

16

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

17

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

18

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

19

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

20

How Do You Know?

“We are hiring smart people that can’t make

changes to our code”

21

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

22

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

23

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!

24

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!

25

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)

26

But Does it Scale? (Yes)

$0

$1

$2

$3

$4

$5

$6

$7

$8

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

IMVU Revenue by Quarter (in millions)

27

Oh Yeah…

Interested in getting more experience?

We’re hiring!

http://www.imvu.com/jobs/