Scaling Product Development at a

SCALING PRODUCT DEVELOPMENT At a Lean Startup James Birchler (@jamesbirchler)Engineering Director, IMVUGDC Online, Oct. 5-8, 2010 AGILE @IMVU

I’ve got some questions for you: How many of you are part of a product team building great stuff for customers? Now… …does anyone have one product development tactic you use that works consistently to help your team meet its goals and deliver great stuff to customers, every time and for every project? I would like that, because it would be great to know that there is tactic, or even a set of tactics or a process—that can lead my team to success every time. But I can’t think of even one that I would count on to work every time, not amidst all the changing conditions of a dynamic product and business. What I would bet my money on is a winning… …strategy, one you can use to maximize your team’s chances of success over time of delivering great features to your customers. Today I’ll share one of the strategies that we use at IMVU. I’m going to review a lot of material today, so to make a couple things more memorable, I’ll reference two of my favorite things: pizza and maps. Today IMVU is a social entertainment product where our customers use 3D avatars to meet people, chat, create cool stuff—AKA UGC--, and play games with their friends. But we started as an add-on… …to products like AOL Instant Messenger, adding 3D avatars to text-based instant messaging. Unfortunately for us, we failed! It turned out that we built something our customers didn’t want. But we listened to customer feedback, and began changing our product to suit their needs. We were doing the first parts of Customer Development: Customer Discovery and Customer Validation. Customer Discovery: ensuring the product solves a problem for a group of customers Customer Validation: Ensuring that group of customers is big enough to build a business And our product development process involved one big weekly meeting to update each other on project status. Our development cycles were 2 months long. We were trying to find a recipe for a product people would like enough to buy, and then build a business on top of that. The team was small and well coordinated, and it worked! After many trials, we found a decent recipe! It wasn’t the best in the world, but it was certainly edible. And the numbers looked pretty good, too… so we thought we could run with this recipe, and we decided to scale it. We thought we could take lots of this dough, this sauce, and this cheese and just make a lot of it… but we didn’t think about changing the recipe to suit this scaling plan, and But clearly, if our goal was to scale, we didn’t do it very well. Something wasn’t working. As it turns out… What got you here won’t always get you there. When you take the recipe and try to scale it up, you end up with something mediocre. You can’t just multiply the amounts of ingredients. You have to adjust the ratios in your recipe, often the cooking temperature and time, sometimes the cooking method… So what happened in our case? We had one person in charge of the sauce, one person in charge of the cheese, and another person in charge of the dough Each of those people thought they could manage their part of the product recipe separately and come up with a bigger version of the original pizza. But we didn’t have a single person in charge of how the entire pizza recipe would come together into something that people would really like and want to pay for. AND, we were GROWING! And the product development process that worked for a small, focused team …wasn’t working for our larger and fast-growing team. Here’s a way to visualize what was going on from our customers’ perspective: I don’t know how many of you have used IMVU, but most of you probably know iTunes… Imagine trying to buy a music track, and instead of the simple process you’re used to… …a web browser launches, obscures the iTunes UI, and forces you through a web-based purchase process, which even if you complete successfully, doesn’t leave you in a position to listen to the track you just purchased. This is a situation our customers were intimately familiar with … This is the previous version of the IMVU 3D chat client. You can see we’ve got the ability to have multiple 3D chat’s happening, cool… and we’ve got a buddy list…okay, and wait—what’s that? An inventory attached to the buddy list? Well that feels sort of “bolted on”, but alright… So let’s say that you’re chatting and you want to buy a snazzy new shirt: first of all, how do you think you would buy something here? Anyone? If you manage to find the “shop catalog” button—bully for you! Now hopefully your friends won’t be too insulted as you leave them, perhaps permanently, and we pop a web browser right over the top of the IMVU chat client UI Oops. Many of our customers got lost at this point, never to find there way back into our core experience. We were held prisoner by a couple of things. Our technology was standing in the way of us being able to respond to our customers—due to accumulated technical debt from our early “discovery” mode product development. And fixing our UI infrastructure was a project that would require a large, coordinated effort that our existing PROCESS couldn’t support. Sort of a Catch-22. ,[object Object]

Lack of strong, consistent product ownership

Too much focus on individual business metrics

Inability to make big feature changes—no one product owner or team had enough resources to make a big change.

No coherent full-product vision

We’d outgrown our product development processIt all might have been comic…if it hadn’t been so tragic for our customers and our business. So we decided to try something new and CRAZY! LEARN FROM OUR MISTAKES! We consciously took stock of our situation, and decided to make some big changes based on our experience. Two important changes were 1) we hired a one person to be responsible for the entire customer experience, with responsibility and a mandate to make big changes, and 2) We updated our product development process. We decided to use the same Lean Startup philosophy that grew the company in the early days to improve and scale our development process. This is the Build Measure Learn loop. We figured, if it works for building cars and our first 3d Chat client, there’s no reason it shouldn’t work for building an efficient software product development team as well. So the plan was to build, measure, and learn as quickly as possible, and incorporate new innovations into our process each sprint. We ravamped the UI infrastructure that was so rife with technical debt, so we could build new UI quickly and efficiently using HTML and JavaScript. And the same teams that were mired before become what our product owners now call the most productive teams they’ve ever worked with. And we did it! We found a great recipe… And our customers loved it. And the numbers look pretty good, too. So how did we do it? We made a lot of changes in the company; here are some of the changes to our product development process. Our product development process is built on a 3-week sprint cycle Remember the build-measure-learn loop? We’ve found that 3 week sprints are ideal for our teams. Scrum facilitates face to face communication, and the daily standup is an opportunity to re-emphasize our commitments to each other and to the team. We say what we accomplished yesterday, what we are committing to get done today, and whether we are blocked in any way. We also take time for follow-up discussions on any topic people want to bring up. Everyone leaves the meeting knowing the exact status of the projects we’re working on. We do this in 15 minutes or less per day. Artifacts – a shared task board Artifacts – a burndown chart for tracking progress Let’s talk about some of the tactics we use successfully at IMVU Standardize. Shipping containers are all the same size. This is because they stack better, and are easier to manage efficiently. But our teams were all doing something different… We found that when our teams were doing things their own way, they didn’t work together that well. Team workflows were too different; it was hard to swap team members and manage different process flows, and it was just harder for everyone to understand what we were working on, and why. So we started with a standardized Scrum process, and now we mange the ongoing evolution of that process. Then it was… ,[object Object]

Easier to share best practicesChanging and evolving your process, is, by the way, in conflict with most dogmatic or zealous approaches to project management. So we avoid dogma. For example, we decided that locking down the sprint backlog at the start of the sprint wasn’t working for us. Sometimes we need to react quickly to marketing needs or prioritize critical work. Unexpected things happen, and Scrum—or any other methodology--practiced dogmatically, doesn’t accommodate that very well. Given that we’re committed to continuous improvement of our process, we avoid dogma at all costs. So we call attention to changes in the sprint backlog daily in scrum and decide as team whether to accept the new work into the sprint. Focused Meeting of Key Stakeholders Solution for a successful planning meeting ,[object Object]

Incorporate different viewpoints and approaches

Then revise to align documentsGround Rules for Planning Meetings We want our teams to have a shared understanding of the sprint projects ,[object Object]

Discussion, disagreement, new ideas, learning

Detailed: we dive into the code and project designsFoster engagement during planning No laptops or cell phones No side conversations. Share the keyboard: take turns driving the meeting Take breaks, bring in food and refreshments Something that deserves special mention is stakeholder agreement We found that time spent to complete tasks was often different than planned, making sprint success difficult to predict Solution: two engineers + technical lead must agree on task duration ,[object Object]

Accomplishes the same engagement as using story points and playing planning poker.

And the doors are locked and all the cold Coke Zero is held outside, until they agree. ;) We’ve found recently that a good target for team size is about 4 engineers per team. Communication overhead increases quickly as you add people, and since scrum is all about lightweight, face-to-face communication, adding team members can quickly cause unforeseen problems. We’ve found that about 4 engineers is the sweet spot for optimizing our ability to get things done efficiently and with high quality. However, we learned that the hard way, but in 2 easy steps: We created a great process… 2) We followed our process, and got into a comfortable routine. We gradually increased our team size, and incorporated new practices to accommodate for subtle changes that were happening Team made an optimization to reduce interruptions, based on a Best Practice from another team, allowing two team members to only fix broken tests (we use TDD). Other team members were writing feature code more efficiently; fewer interruptions. Oops. ,[object Object]

One group created problems that another group had to solve

We failed to understand the impact of an underlying infrastructure problem

Team too big—happened graduallyLearn from your mistakes (and your successes) Pay attention to what works and what doesn’t ,[object Object]

Objective, high-level measure of velocity

Early signal of success/failure, even if team “seems” fine

Faster response time Over time you might develop some ALWAYS’S What is an always’s you ask? These are things we do for every project, always. Remind yourselves about these—write them on the whiteboard during your planning meeting! (Planning Assumptions on the whiteboard) We also write our planning assumptions on the whiteboard. We make our assumptions public This Reduce surprises, ensures engagement, helps catch errors. Making these assumptions explicit means it’s harder to forget planned vacations, conferences, and other events that might affect planning. It also sets expectations for how much time each engineer will be contributing to achieving the team goals that sprint. This is all part of our Planning Technology This is one of our early scrum task boards. A later version of our scrum task board: Bigger Painter’s tape 5 columns (Added QA + “New”) “New” column: We realized we were in charge of our destiny, and that we wanted to accommodate new work coming into the sprint In planning, we needed to refer to the old board AND make a new board. Voila: the temporary task board We spared no expense and found removable artists tape and black foam core… And this board has some *sweet* features: ,[object Object]

Physical size limits number of stories

Easy to meet, collaborate, plan work

Hard to work with if you are remote!An online board is helpful with people working remotely from home or other locations These tactics totally work for us Except whenthey totally don’t Context Matters: Some of our process works because of the particular context we have at a given time. Context changes! Some of our greatest failures result from following our process. You have to know when to deviate from your process. You have to always remember that you are in control, you are driving. A map can be a useful guide, but it is not a substitute for paying attention to what is going on. If you follow this map without thinking about it, you might run into problems. Process is like a map. Your process is not a replacement for being engaged and paying attention! Plan your route! Ensure that you are headed to the right destination. What your process or plan tells you is the right offramp, may not be. Process is not a substitute for engagement. Engage! Be conscious! Expect the unexpected. Change your process in subtle ways that get people to engage… Start using story points, for example… Any change you make will create a problem for the team to solve, and require people to re-engage So What Did We Learn? Apply Build Measure Learn to your process ,[object Object]

Thank you!James BirchlerEmail: jbirchler@imvu.comTwitter: @jamesbirchlerTweet this talk! #imvugdc Title slide photo credit: Jewel Fish by www.flickr.com/psyberartist SLIDE COPY BELOW THIS POINT------------------------------------ Name one guaranteed winning tactic

Thanks to Eric Ries, http://startuplessonslearned.com

Process Strategy & Revenue Timeline ($ millions) Optimize & Scale Explore & Build Photo by The Pizza Review http://flic.kr/p/4zYkdj

Photo by CarbonNYC http://flic.kr/p/KTPYW

Prod Dev Strategy & Revenue Timeline ($ millions)

Process Strategy & Revenue Timeline ($ millions) Optimize & Scale Explore & Build Photo by http://www.canpages.ca/blog/?p=508

Floppy Drive Photo by Accretion Disk http://flic.kr/p/MaphG

Scaling Product Development at a

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (18)

Similaire à Scaling Product Development at a

Similaire à Scaling Product Development at a (20)

Dernier

Dernier (20)

Scaling Product Development at a

Notes de l'éditeur