Wednesday, May 27, 2009

Austin: the Lean Startup tour continues

Next week I head to Austin, TX for my first visit ever. I'm going to be speaking on June 3rd at an event sponsored by the Technology Entrepreneurs Exchange (TeXchange), "the premier networking organization in Texas for business executives and entrepreneurs to meet, exchange ideas and share experiences." (Also see below for details of another event the day before)

Normally, these events are for members only, but they are making an exception for the lean startup, and the dinner will be open to the public. You can register here. There is also a special discounted rate available for entrepreneurs and bootstrappers, about which you can learn more here. I really like their event format, which includes dinner, moderated table discussions - and then a Q&A session. I expect that will lead to much deeper (and tougher) questions. Bring it on!

Here's their description of the event:

The current macroeconomic climate presents unparalleled opportunities for those that can thrive with constrained resources. The Lean Startup is a practical approach for creating and managing a new breed of company that excels in low-cost experimentation, rapid iteration, and true customer insight. It uses principles of agile software development, open source and web 2.0, and lean manufacturing to guide the creation of technology businesses that create disruptive innovation.

This presentation will empower entrepreneurs and managers to:

-Identify a profitable business model faster and cheaper than your competitors.

-Continuously discover what customers want to buy before building or making follow-on investments in new features.

-Ship new software at a dizzying pace: multiple times a day while improving quality and lowering costs.

-Build a company-wide culture of decision-making based on real facts, not opinions.

In this presentation, serial entrepreneur Eric Ries will share practical solutions based in his work building IMVU to more than 25 million members worldwide and his experiences consulting to more than a dozen technology startups.

Learn more here.
On the day before the TeXchange event (June 2nd), I'll be at a much smaller invite-only gathering sponsored by Austin Ventures. This will be an in-depth discussion with a handful of entrepreneurs and founders that have been pre-selected. This event is being organized by Manuel Rosso, an EIR at Austin Ventures, and my former collaborator back when he was VP of Marketing at IMVU. I asked him to reserve a seat or two for blog readers; if you're interested in coming to the event, you need to email him directly and explain why you want to be there.

Once again, thanks to everyone who can come out to join the discussion in Austin. As usual, if you're a reader, please come say hello - and bring your questions.

Friday, May 22, 2009

The Lean Startup at SIPA follow-up

I had wonderful time presenting at SIPA last night, and was completely exhausted by the incredible post-speech response. To all those who couldn't get your questions answered in person, please feel free to post them as comments and I will do my best to answer. As usual, here are the slides from the event followed by some post-game commentary.




I'm starting to let all this positive feedback go to my head. Here's a taste:
pkgulati: @ericries Attended your #leanstartup event at SIPA today. Great event and a lot in common with what we do at Dubai. We need to stay in touch

GregOsuri: Amazing talk by @ericries at SIPA, changed my thought process significantly, a must education for aspiring start-ups #leanstartup

coupld: @ericries hey Eric this is Kunal. great talk at SIPA today Re: #leanstartup We'll be hitting you up with questions - would love some advice.

ms5: Talking to friends re @ericries talk #leanstartup - IMO most of his points can ONLY be understood by ppl who did a startup & failed before
This last point became kind of a theme for the evening: the importance of failing and taking risks in order to learn. I certainly think that having a failed startup can be an important motivator to do the soul-searching required to really learn, but I haven't given up on being able to affect the odds of success for future entrepreneurs on their first time out. If we can change just a few of the "best practices" that are considered common sense throughout the industry, I think we can do much better - even the first time. At a minimum, we ought to be able to help future entrepreneurs learn more per failure (on average) than we do today.

Naturally, not everyone agreed with everything
atseitlin: Listened to @ericries talk. Loved it and great speaker, but disagree with portrayal of agile only dealing with known problems #leanstartup
I'm really interested in perspectives on this point. Some of you will remember my intense anxiety presenting this idea on a webcast with Kent Beck himself tuned in, but he seemed to understand what I was getting at, which was a relief. Still, that doesn't prove that this is right. So if you have thoughts, please post them in the comments.

Of course, people do use agile in situations of high uncertainty (aka the "unknown problem") - but my claim is just that agile methodologies don't explicitly address the question of how to decide which problem to solve. For example, the agile practice of an in-house customer or product owner that can make authoritative prioritization decisions seems like it doesn't translate very well to startups. Of course, by collapsing the feedback time for the person in that role, agile is certainly helpful (and much more helpful than waterfall) - it's not just not designed for this context. Thoughts?

ms5: @ericries in tonight's talk on #leanstartup "To get to Minimum Viable Prod (MVP), cut features until it is really, really painful" #prodmgmt
Lost of questions last night on the minimum viable product, including one that elicited this response. It occurred to me that this is simultaneously a really hard problem and a really easy problem. Hard, because finding a clear rationale for any specific MVP is challenging. It's mostly a matter of judgment. But once you take the question out of the abstract, it gets much easier. In almost every case, people who ask me about the MVP already have a product in development - and it is plenty good enough to start getting feedback.
marymin: The later you fail, the bigger the audience that sees you fail - and the more you have at risk. #leanstartup
This is another fun one that I don't get to talk about often enough. Our natural impulse is to wait and prevent problems. The more time we take, the fewer problems we should have, because we use that extra time to think things through. That's true as far as it goes, but it's actually faulty reasoning in a lot of startup situations.

If your startup is growing (or aspires to grow), then the costs of a mistake are always going up. If your site goes down when you have 100 customers, that's painful. But with 100 million customers, it could be catastrophic. Since the cost of failure is monotonically increasing, it actually makes sense to fail sooner, not later. In other words, make your mistakes as soon as possible and learn from them - before you get too big to be able to take those kinds of risks. This is the thinking that allowed us to overcome our fear of continuous deployment at IMVU.

Thanks so much to everyone who made the trip to SIPA and participated in the conversation, as well as to SIPA and HP for hosting me. I certainly learned a lot from the experience. Your support means the world to me. Thanks!

Sunday, May 17, 2009

Last chance to register for The Lean Startup at HP on May 21

This coming Thursday, May 21, is the last time I'm currently scheduled to give the full Lean Startup presentation in the Bay Area. The event is being sponsored by SIPA but will be open to the public. Last I heard from the venue, there are still some seats available; the ticket cost is only $25 if you register online.

Here's their write-up of the event:
We have heard that recessions are the best time to start your own startup. For entrepreneurs who have been on the path, it may be straight forward to get started. What about the rest of us? There are so many engineers with bright ideas, but don't know how to start.

The current macroeconomic climate presents unparalleled opportunities for those that can thrive with constrained resources. Many startups are now following the Lean Startup process. The Lean process was created by Toyota in the 50s. The Lean Startup embodies similar principles as applied to the startup process. The Lean Startup is a practical approach for creating and managing a new breed of company that excels in low-cost experimentation, rapid iteration, and true customer insight.

Eric Ries, a co-founder of IMVU, is a strong proponent of this process and very successfully used it at IMVU. He will share the key principles of making sure you get your startup idea off the ground and stay on course.

If you are an engineer with bright ideas, consider Lean Startup to build confidence while building your startup.

1. Identify a profitable business model faster and cheaper than your competitors.

2. Continuously discover what customers want to buy before building or making follow-on investments in new features.

3. Ship new software at a dizzying pace: multiple times a day while improving quality and lowering costs.

4. Build a company-wide culture of decision-making based on real facts, not opinions.

You can register online here.

The event itself will be held on the HP campus in Cupertino, from 6-8:30pm. As always, if you're a reader and happen to be there, please do come say hello. If you have any questions, please post them as comments to this entry. I'll do my best to see that they are addressed.

As a reminder, slides and audio from the Web 2.0 Expo debut of this talk are available online, too. Hope to see you there.
Reblog this post [with Zemanta]

Thursday, May 14, 2009

The Lean Startup Workshop - now an O'Reilly Master Class

My rate of posting has been much lower lately, and this is mostly due to preparations for the upcoming Lean Startup Workshop on May 29. I have a lot of good news to report on this front.

First of all, I'm excited to announce that the workshop is now an O'Reilly Master Class, and we have added a second date on June 18. Most importantly, thanks to O'Reilly, we now have more capacity, including a few additional seats to the previously-sold-out May 29 date. You can register for both dates on the new official signup page.

What will be covered in the full-day program? Take a look:

This full-day Master Class focuses on how to build a startup from the ground up to focus on customers, markets, and speed of iteration. Using examples drawn from his own experiences in the startup hub of Silicon Valley, Eric Ries unravels the myths and misconceptions that guide most startups, and paints a picture of a new way forward for the industry. Unlike other incubator-led programs, this workshop is open to anyone who wants to learn, and it does not require companies take investment or give out equity.

Through case studies, exercises, and discussions, Eric Ries will guide entrepreneurs of all stripes through the key areas that determine success for startups: product, engineering, QA, marketing, and business strategy. This workshop presents a new methodology that will allow you to bring new products -- and companies -- to life.

At the end of the workshop, you will have new insight into how to evaluate the strengths and shortcomings of your company, as well as a clear plan of action to bring lean-startup thinking back home. Rather than abstract principles, you'll learn to directly problem-solve.

You can click here to learn more.

The response so far has been nothing short of overwhelming, and I want to especially thank those of you who participated in the survey and customer validation exercise that helped shape this event. I'm working on a future post where I'll share the details of how I used customer development to shape both the content and packaging of this event, so look for that soon.

For now, I'd like to ask a favor. Given that this is my first effort in a joint partnership, I'd like to ask you to help spread the word about the Master Class. Would you be willing to link to the Master Class info page from your blog? Twitter about it or post it to a social media site? Most importantly, if you know a high-quality entrepreneur who you think would add to the conversation, would you be willing to try and convince them to attend? I'd also welcome nominations over email, if you have someone you think is a good fit for the event. Please feel free to send along your comments or questions about the workshop itself.

Lastly, some people have asked about discounted rates for those that can't afford the tuition fee. Others have asked about sponsorship opportunities at the workshop. We're not going to have any form of advertising, but I am considering trying to offer a scholarship program to worthy entrepreneurs, just as we did for the Web 2.0 Expo. If you'd be interested in sponsoring a scholarship, or applying for one, would you get in touch or leave a comment on this post? If there's enough interest, I'll do my best to screen the applicants and recognize the donors.

Thank you all for your continued support, and hope to see you at an event soon.

Thursday, May 7, 2009

Fear is the mind-killer

Fear is an emotion that slows teams down. It makes us more cautious. It makes us over-invest in prevention. It makes us less willing to trust, to communicate openly, and - most painfully - to take risks. It is the dominant reason I see teams fall back on "best practices" which may not be effective, but are at least reassuring. Unfortunately, these actions generally work to increase the batch size of our work, which magnifies the consequences of failure and therefore leads to more fear. Reducing fear is a heuristic we can use to judge process improvements. Anything that reduces fear is likely to speed up the fundamental feedback loop.

The interesting thing about fear is that to reduce it requires two contradictory impulses. First, we can reduce fear by mitigating the consequences of failure. If we construct areas where experimentation is less costly, we can feel safer and therefore try new things. On the other hand, the second main way to reduce fear is to engage in the feared activity more often. By pushing the envelope, we can challenge our assumptions about consequences and get better at what we fear at the same time. Thus, it is sometimes a good idea to reduce fear by slowing down, and sometimes a good idea to reduce fear by speeding up.

To illustrate this point, I want to excerpt a large part of a recent blog post by Owen Rogers, who organized my recent trip to Vancouver. I spent some time with his company before the conference and discussed ways to get started with continuous deployment, including my experience introducing it at IMVU. He summarized that conversation well, so rather than re-tread that material, I'll quote it here:

One thing that I was surprised to learn was that IMVU started out with continuous deployment. They were deploying to production with every commit before they had an automated build server or extensive automated test coverage in place. Intuitively this seemed completely backwards to me - surely it would be better to start with CI, build up the test coverage until it reached an acceptable level and then work on deploying continuously. In retrospect and with a better understanding of their context, their approach makes perfect sense. Moreover, approaching the problem from the direction that I had intuitively is a recipe for never reaching a point where continuous deployment is feasible.

Initially, IMVU sought to quickly build a product that would prove out the soundness of their ideas and test the validity of their business model. Their initial users were super early adopters who were willing to trade quality for access to new features. Getting features and fixes into hands of users was the greatest priority - a test environment would just get in the way and slow down the validation coming from having code running in production. As the product matured, they were able to ratchet up the quality to prevent regression on features that had been truly embraced by their customers.

Second, leveraging a dynamic scripting language (like PHP) for building web applications made it easy to quickly set up a simple, non-disruptive deployment process. There’s no compilation or packaging steps which would generally be performed by an automated build server - just copy and change the symlink.

Third, they evolved ways to selectively expose functionality to sets of users. As Eric said, “at IMVU, ‘release’ is a marketing term”. New functionality could be living in production for days or weeks before being released to the majority of users. They could test, get feedback and refine a new feature with a subset of users until it was ready for wider consumption. Users were not just an extension of the testing team - they were an extension of the product design team.

Understanding these three factors makes it clear as to why continuous deployment was a starting point for IMVU. In contrast, at most organizations - especially those with mature products - high quality is the starting point. It is assumed that users will not tolerate any decrease in quality. Users should only see new functionality once it is ready, fully implemented and thoroughly tested, lest they get a bad impression of the product that could adversely affect the company’s brand. They would rather build the wrong product well than risk this kind of exposure. In this context, the automated test coverage would need to be so good as to render continuous deployment infeasible for most systems. Starting instead from a position where feedback cycle time is the priority and allowing quality to ratchet up as the product matures provides a more natural lead in to continuous deployment.

The rest of the post, which you can read here, discusses the application of these principles to other contexts. I recommend you take a look.

Returning to the topic at hand, I think this example illustrates the tension required to reduce fear. In order to do continuous deployment at IMVU, we had to handle fear two ways:

  1. Reduce consequences - by emphasizing the small number of customers we had, we were able to convince ourselves that exposing them to a half-baked product was not very risky. Although it was painful, we focused our attention on the even bigger risks we were mitigating: the risk that nobody would use our product, the risk that customers wouldn't pay for virtual goods, and the risk that we'd spend years of our lives building something that didn't matter - again.

  2. Fear early, fear often - by actually doing continuous deployment before we were really "ready" for it, we got used to the real benefits and consequences of acting at that pace. On the negative side, we got a visceral feel for the kinds of changes that could really harm customers, like commits that take the whole site down. But on the plus side, we got to see just how powerful it is to be able to ship changes to the product at any hour of the day, to get rapid feedback on new ideas, and to not have to wait for the next "release train" to put your ideas in action. On the whole, it made it easier for us to decide to invest in preventive maintenance (ie the Cluster Immune System) rather than just slow down and accept a larger batch size.
Making this fear-reduction strategy work required more than just the core team getting used to continuous deployment. We eventually discovered (via five whys) that we also had to get each new employee acculturated to a fearless way of thinking. For people we hired from larger companies especially, this was challenging. To get them over that hurdle, we once again turned to the "reduce consequences" and "face your fears" duality.

When a new engineer started at IMVU, I had a simple rule: they had to ship code to production on their first day. It wasn't an absolute rule; if it had to be the second day, that was OK. But if it slipped to the third day, I started to worry. Generally, we'd let them pick their own bug to fix, or, if necessary, assign them something small. As we got better at this, we realized the smaller the better. Either way, it had to be a real bug and it had to be fixed live, in production. For some, this was an absolutely terrifying experience. "What if I take the site down?!" was a common refrain. I tried to make sure we always gave the same answer: "if you manage to take the site down, that's our fault for making it too easy. Either way, we'll learn something interesting."

Because this was such a big cultural change for most new employees, we didn't leave them to sink or swim on their own. We always assigned them a "code mentor" from the ranks of the more established engineers. The idea was that these two people would operate as a unit, with the mentor's job performance during this period evaluated by the performance of the new person. As we continued to find bugs in production caused by new engineers who weren't properly trained, we'd do root cause analysis, and keep making proportional investments in improving the process. As a result, we had a pretty decent curriculum for each mentor to follow to ensure the new employee got up to speed on the most important topics quickly.

These two practices worked together well. For one, it required us to keep our developer sandbox setup procedure simple and automated. Anyone who had served as a code mentor would instinctively be bothered if someone else made a change to the sandbox environment that required special manual setup. Such changes inevitably waste a lot of time, since we generally build a lot more developer sandboxes than we realize. Most importantly, we immediately thrust our new employees into a mindset of reduced fear. We had them imagine the most risky thing they could possibly do - pushing code to production too soon - and then do it.

Here's the key point. I won't pretend that this worked smoothly every time. Some engineers, especially in the early days, did indeed take the site down on their first day. And that was not a lot of fun. But it still turned out OK. We didn't have that many customers, after all. And continuous deployment meant we could react fast and fix the problem quickly. Most importantly, new employees realized that they weren't going to be fired for making a mistake. We'd immediately involve them in the postmortem analysis, and in a lot of cases it was the newcomer themselves (with the help of their mentor) who would would build the prophylactic systems required to prevent the next new person from tripping over that same issue.

Fear slows teams of all sizes down. Even if you have a large team, could you create a sandboxed environment where anyone can make changes that affect a small number of customers? Even as we grew the team at IMVU, we always maintained a rule that anyone could run a split-test without excess approvals as long as the total number of customers affected was below a critical threshold. Could you create a separate release process for small or low-risk commits, so that work that happens in small batches is released faster? My prediction in such a situation is that, over time, an increasing proportion of your commits will become eligible for the fast-track procedure.

Whatever fear-reducing tactics you try, share your results in the comments. Or, if fear's got you paralyzed, share that too. We'll do our best to help.

(with apologies to Frank Herbert)

Reblog this post [with Zemanta]

Tuesday, May 5, 2009

More video "what to do if customers don't like your (initial) product" plus full webcast

First up is an interview with Mixergy, about lean startups and what to do if customers don't like your (initial) product. You can watch the whole hour-long discussion here. Here's a little taste from a story I've mentioned on this blog a few times, but haven't discussed in detail, about the decision at IMVU to abandon our IM add-on concept; you can also watch an excerpt on YouTube.

I mean, it requires a lot of explanation. instant messaging add-on - it’s not a category that exists in her mind. But, since she’s in the room with us we can talk her into doing it. So she downloads the product, we have her install it on the computer, and we’re like “okay, it’s time to check it out, you know, invite one of your friends to chat.”

She says, “no way.”

We say, “Why not?”

She says, “I don’t know if this thing is cool yet. You want me to risk inviting my friends to a thing that I don’t think is cool? What are they going to think of me? If it sucks, they’re going to think I suck, right?”

And we say “No, no, it’s going to be so fun. It’s a social product…”

And the look of dubiousness, I mean, you can just see, this is a dealbreaker. And of course the first time you have that experience you say, “All right, it’s just that person, let em out, you know, send them away. Get me a new one.”

So then the second customer comes in. Same thing. Third customer comes in, same thing. You start to see these patterns and you’re like, okay. No matter how stubborn you are there’s got to be something wrong here.

Watch the rest here...

Here's an excerpt from YouTube:






Second, the complete audio (with slides) from my webcast last week is up on YouTube now too:



I hope you'll indulge me as I share some of the testimonials we heard from the participants who opted to answer the post-event survey. I'm trying to get better about taking advantage of the many testimonials you all have written for me. Thank you all so much.

His thinking about the relationship between business and technology is refreshing. His understanding of development problems impressive. I can't think of anyone who would not benefit from the presentation. No wonder Kent B. was there!
-Blaine Wishart

I was pleasantly surprised at how concise, useful and poignant the content was...well worth the time!
-Brian Moelk
Great presentation, as always!
-Sachin Rekhi
Eric is one of the smartest guys in the business.
-Ryan Kuder

Probably the best thing was knowing that Eric has done this and seen it work. It's not just a hypothesis but he has real working knowledge
- Trevor Gerzen
I absolutely loved the closing. "Stop typing, take your hands off the keyboard. Think of one concrete thing you can do in the next 24 hours to move you closer to this." Long pause. "Thanks for listening."
-Kyle Maxwell

Inspiring presentation, makes the daunting process of putting together a startup seem just a bit less daunting.
-Lawrence Green

Thanks for reading, listening, and watching. Your feedback, positive or negative, is always welcome.

Sunday, May 3, 2009

Videos galore

Two new videos are online from recent speeches. The first is my talk on engagement loops and the levers of engagement from the Kontagent/Facebook Developer Garage. Slides from this talk are available here. For more on the subject of engagement loops, you can read my original essay here.

5. Eric Ries - Engagement Loops 3. Justin Smith - Social Gaming Trends - @ Kontagent / Facebook Dev Garage from albert lai on Vimeo.



(This also gives me a chance to clarify that I am no relation to the author of the classic book on positioning, Al Ries)


Next up, here's the video from my talk with Steve Blank at startup2startup. I've embedded the slides below the video feed.






Thanks for watching!
Reblog this post [with Zemanta]

Friday, May 1, 2009

Lean Startup webcast post-game

Wow, what an incredible turnout for webcast this morning, right on the heels of a phenomenal crowd at startup2startup last night. It's been a great twelve hours for the lean startup!

We'll have a full audio recording posted soon, but I did want to share the slides with everyone. Much of the content is shared with the Web 2.0 Expo talk, but there are a few new slides and in the discussion/Q&A we were able to go into much more implementation detail. One big idea that I haven't had a chance to write about on the blog yet is answering the question "What is a startup?" Here's the working definition I've started using:

A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty.

In a future post, I'll attempt to unpack this definition in detail. For now, I just want to call attention to the idea that it has nothing to do with size of company, sector of the economy, or industry.



And now for some instant twitter reactions:
KentBeck: @ericries thank you for the insights. "unknown problem" was an eye opener for me. i'm running junit max according to lean startup principles
OK, so I'm showing off. One of my personal heroes, Kent Beck, the creator of Extreme Programming and a truly wonderful writer was logged in and twittering, too. What a thrill.
OReillyUG: For more info on The Lean Startup by Eric Ries, register for our upcoming courses in SF May 29 and June 18 http://training.oreilly.com/theleanstartup/ #leanstartup
Very excited to announce that I've teamed up with O'Reilly to produce the upcoming Lean Startup Workshop as part of their Master Class series. As a result, we should be able to accommodate more people and more venues, maybe even more cities, if there is interest.

Now for some real feedback:
@rotkapchen #leanstartup Love this: Need both problem team & solution team working simultan, exchanging hypotheses, findings & solutions.
I'm continuing to push this idea, that departments can incentivize sub-optimal behavior. What makes a department (or individual) "more efficient" doesn't necessarily advance the company's goals.
farazq: Awesome session @ericries. LIKED: Y startups fail, cont deployment vs waterfall vs agile, small batches & learn fr biz metrics #leanstartup
As concise a summary as I've ever seen.
hwijaya: #leanstartup It's not the release fast dat matter. It's getting the evident dat u're on the right track (wat u learn frm making the release)

katrynharris: @ericries: "go as fast as we can work reliably to make progress & no faster" - absolutely & thanks for a super webcast! #leanstartup

Really trying to emphasize the importance of speed - but speed with regard to actual progress. That's what gives startups their disruptive innovation edge. Going "too fast" is not actually helpful. Learning to tell the difference is the hard part, and creating processes that act as speed regulators is the payoff.
clynetic: #leanstartup - All are ready to do this: Whether starting new company, have startup but need to iterate faster, or established company.

kylemaxwell: Behind every technical problem lies a human problem. #leanstartup
Always glad to see people pick up on these themes. It's never too late, you can always get started, and since all problems are human problems, there's no hiding behind a technical excuse.

Of course, not everybody had a great time.
wogsland: Still not understanding the "lean" aspect. Techniques sound fairly expensive to do correctly. #leanstartup
This is an objection I hear regularly, so I'm grateful to have the chance to address it. Lean is not about cheap, it's about speed. All lean transformation techniques, including the ones I advocate, involve making some part of the organization "less efficient" in order to speed up the whole. So they require investments to pay off. However, the level of waste in most organizations is so high that the investments pay off immediately, and therefore create new resources that can be reinvested in further improvements.

For example, it takes a few days of effort to build a simple split-testing system along the lines I advocate. Some companies tell me they "cannot afford" to do it. But if that split-testing system allows you avoid building just one major feature that would have been a waste of time, it's paid for itself many times over. If you don't have the confidence or ability to make trade-offs like that, you can't get lean.
kylemaxwell: you have known knowns, and known unknowns, and unknown unknowns. #leanstartup #rumsfeld
There's no way to avoid this Rumsfeld quote. Then again, "just because you're paranoid doesn't mean they're not out to get you." What can I say? He had a point.
jimmurphy: @ericries bug is your waterfall slide: Problem: Know Solution: *Known* #leanstartup
Thanks! This is fixed in the posted slides.
wogsland: uck, buzzword vomit #leanstartup
Well, I don't know what to say to this. I welcome suggestions for ways to get the same content across with fewer buzzwords. I don't think I can be very helpful without a discussion of the theory behind the lean startup, but I also don't know how else to teach that content. Please feel free to post your thoughts.


And then there's some questions that came up during the webcast that we didn't have time to discuss. I covered a few of them on twitter already:

  • Q: "Do you reccomend removing features that you've launched but don't movethe needle on engagement or revenue?" A: yes, absolutely.

  • Q: Does the Lean Startup framework work efficiently within a company of 2-3 people (think small)?" A: yes, yes, yes

  • Q: Does the Lean Startup framework work efficiently within a company of 2-3 people (think small)?" A: yes, yes, yes

  • Q: "Seems like the biggest issue is changing people's mentality. How did you deal with that on a new recruit (specificaly seasoned ones)?"

    A: have them deploy code to production on their first day as an employee. made a big impression.

  • Q "In CD you spend a lot of time on phone with users. How does this map to the web? Surveys? Trial and Error + Analytics? What else?"

    A: honestly, all of the above. Phone/in-person is still critical, but have to remember that is for idea generation, not idea validation

  • Good Q on webcast: "when measuring the results of your test, how do you avoid the post hocergo propter hoc fallacy?" A: you must split-test
If you had another questions you wanted to see answered (or do after you see the slides or audio), please post them here! I'll do my best to answer.

Lastly, I was really excited to announce on the webcast that we've opened up two dates for the Lean Startup Workshop - now that it's in O'Reilly's Master Class series, I have a lot more capacity to do these events. If you're interested, you can find out more here.


Reblog this post [with Zemanta]