I Am Eric Ries, Author of the Lean Startup. AMA
I'm writing a new book & trying to use lean startup ideas myself in writing it. The new book is only available via Kickstarter, and the campaign ends in 56 hours, so I thought I'd stop by and answer questions about the new book, lean startup, or anything else.
Kickstarter URL: bit.ly/theleadersguide
EDIT: 1:05pm. I need to sign off for a bit. Thanks for asking such great questions. I'll try and stop by later in the day to pick up any stragglers that come in.
114 comments
[ 3.1 ms ] story [ 173 ms ] threadThis may sound pedantic, but it kind of depends on what you mean by "launch" and what you mean by "startup." If you take something like CapTable.io, it only took a few weeks to get the initial version up and running although most people probably don't consider it "launched" at all.
But here's a spooky though I'll leave you with. Often times, when startups are looking at their tools they will say: given the tools I have, the fastest I can build an MVP is X. But if you really take the criticality of learning seriously, you might say: given my desire to learn quickly, what tools can I use to go faster?
And that's where a lot of breakthroughs happen, when you choose tools and platforms not based solely on their technical capabilities, but by their speed of iteration. (It's probably why Facebook was built on PHP.)
I would say the two most fatal misapplications are:
1. "up and to the right" disease. here you split-test everything and just do whatever moves the numbers. pretty soon you are selling porn or psychic hotlines.
2. "no vision, no problems" error. It's like trying to do science without a hypothesis. In lean startup we emphasize that people trying to predict the future are often wrong, so it's best to experiment and pivot as you learn. But some people interpret this to mean that the future is unknowable, there's no point in having any kind of vision, and you should just ship something and see what happens. the problem with this plan is you are guaranteed to succeed - at seeing what happens. after-the-fact rationalization will prevent any learning, because if you can't fail you can't learn. having a big expansive vision is really helpful because it provides lots of falsifiable hypotheses for testing.
3. "minimum viable crap" sloppy execution. Some people think MVP means just throw garbage at the wall and see what sticks, especially since the M makes people think lean startup is for doing something small. but the truth is if you're doing something small, you don't need MVP or lean startup. you only need an MVP if you're trying something large. further, part of the MVP process is to learn what customers actually value in terms of quality, so we can build something that they perceive as excellent. shipping crap isn't the goal, and people that go on TechCrunch with garbage and then claim "but it's an MVP!" are doing it wrong. the hard truth is that spending more time "perfecting" a product in the absence of feedback often makes the product worse, not better.
Unfortunately, not all sources of variability are bad. Think about the antibiotic craze as an analogy. It was a major discovery that bacteria cause disease. But it was also a major discovery that certain bacteria are beneficial. Loading up your system with antibiotics 24/7 is actually detrimental to long-term health, even though it's awfully helpful during an appendectomy.
How do you differentiate good variability from bad ones in software development?
Here's a classic example: let's say I have a story card that says "build a feature that lets 10000 customers buy a widget from our store." In most classic agile systems, the engineering team will do their best to understand the customer requirement and see that it's built appropriately.
Now let's say that 0 customers show and buy the widget. Who's fault is this? In traditional agile, it's the Product Owner's fault, not the engineering team.
But exploiting positive variability would say: the effort required to build this feature requires knowing in advance how many customers want to buy the widget. The engineering effort is totally different if the answer is 0, 10, 100, 10000, or 1000000 customers. So rather than build the feature as specified, let's do an experiment to try and assess customer demand first, then build in response to that demand.
That means that sometimes a story will take 10X longer than you originally planned and sometimes it will take 1/10th as long. But in the end, you'll get a better business result. That's positive variability.
If you can tell the truth, try to win the argument now, before it's too late.
But not everyone is so lucky. If for whatever reason, you can't tell the client the truth, you're not totally doomed. What I would look for is an opportunity to make a trade with the various middle managers involved in this situation. Try to ask for fewer, but more dedicated, resources. In most corporate situations, nobody ever asks for less money, smaller teams, less authority. But you'd rather have a dedicated team of 5 than 14 volunteers.
Maybe you can ask a few of the volunteers to join you for an extra-curricular set of meetings, like over a weekend, to try and give them a tiny taste of acting like a real startup.
Now, since you're probably not going to take my advice, I think a new book that you'll find helpful would be Startup Opportunities https://www.amazon.com/Startup-Opportunities-Know-When-Quit/...
I also recently curated a list of classic startup books on Product Hunt: http://www.producthunt.com/ericries/collections/classic-star...
Looking back, I think if YC had existed, I almost certainly would have applied. But nothing like that existed back then and so I wound up making my own mistakes and then writing about them.
I've always thought that it's not entirely good idea to not make your own mistakes. While painful it provides a better gut than simply being told or reading about things and getting quick answers.
You know in traditional businesses there is a reason that even in many cases family members (in family businesses) spend time at the bottom before they are put into higher level positions. It gives you a chance to see exactly why and how things are done and to experience them and fully understand nuance. Things that can't be learned in school or passed by anecdote.
The only way to test a marketplace is to get a small number of highly-interconnected buyers and sellers to transact in low volume by hand. Think eBay and beanie babies or Facebook just on the Harvard campus. Read PG's http://paulgraham.com/ds.html for more.
I am thinking of two conventional "10X engineers" right now that I've worked with in my career. One is extremely loud, brash, judgmental and basically scary. If you are brave enough to come to him with a question, and he thinks it's stupid, you will basically never live it down. The second is extremely humble, quiet, and gentle. If you come to him with a question, he probably won't answer it but will show up two days later with a fully-implemented solution that he created at 2am just to see if it was possible.
In most companies, the first 10X engineer tends to get promoted to a position of seniority, while the second is generally allowed to quietly leave the company when they get bored. And don't even get me started on all the incredibly talented people out there who our biased hiring processes can't ever identify as "10X."
If you ever get the chance to mingle with some of the truly famous founders, ask yourself if they strike you as the smartest people you've ever met. Now, many of us get star-struck when we meet people who are rich and powerful, and we rationalize whatever garbage comes out of their mouths as genius utterances, because deep down we're all still primates. But if you can get past that, you'll notice that a lot of really successful founders (and investors for that matter) aren't especially bright or thoughtful. But they do have other critical character traits that helped them succeed. Here's a PG classic on the subject: http://www.paulgraham.com/bronze.html
He also has a great essay about the importance of grit and determination but I can't quite remember the title.
But regardless of how much money you take, lean is about a disciplined process of decision making. Can you build a culture of high-tempo testing and make it stick not just for the founders but for all employees? That really has nothing to do with how much money you take.
[1] Simply recognizing that someone without name recognition doing something similar on HN is not assured of getting any attention.
However, there are many other ways to build rep in a community like HN without being famous. I bet if any of the highest-karma posters did an AMA they would get a lot of attention. Personally, I'd be fascinated to learn more about who they are.
I actually picked up a considerable amount of side consulting by being a regular commenter on a well known blog. While I make money from that side consulting (near 6 figures), it's actually a drain on how I make money in other ways. It almost doesn't pay (but it's fun). [1] However the time it took me to earn enough of a reputation which led (in an indirect way) to the consulting (and contacts) was really a poor use of my time.
A better idea time wise, to jump start reputation, and build a rep (in a community like HN if that is what you are trying to do) would be to attempt to do things that are remarkable and get attention. Then people might talk about you and you will have the reputation that you seek that will bring other things that you need.
[1] I also get to meet many interesting people and contacts as well.
There are great commenters who are very well-known who don't rank anywhere on the leaderboard. 'pbsd is a well-known cryptographer. 'tzs is the best commenter on HN. 'carbocation is a doctor/medical researcher.
Being engaged and available is important. The leaderboard is a really warped assessment of that. HN should get rid of it, along with the whole karma system.
An easy start: continue scoring comments, but stop revealing per-user karma totals.
I don't think anyone needs an AMA from me or Patrick McKenzie. The Ries AMA is interesting because he isn't a regular, and has interesting things to say.
"I don't think anyone needs an AMA from me"
Actually I would find that fascinating.
(although given your prior comment history, I'm guessing the latter)
Cheers! /Martin
1) the value proposition for the book was right and 2) that the book actually lived up to that value proposition
I am convinced the book would not have been a blockbuster without that work.
Now the tools are so much better. Kickstarter allows me to do this testing and iteration in a much bigger and more public way - and that's just the start. Now that I have a 7000+ community of people who are going on the journey with me, I have a built-in place to test concepts and make sure that what I'm recommending is actually effective.
But the biggest change is not in all that noise, it's in the fact that entrepreneurial know-how is widely available. When I first started blogging in 2008, there weren't that many startup blogs. Almost no VCs blogged. YC was just beginning and PG's essays were about many different topics, with startups appearing only rarely.
Now new founders are swimming in a sea of knowledge that was previously considered esoteric. I think we're only seeing the tip of the iceberg of what will happen to the global economy now that the genie is out of the bottle. (mixing metaphors a wee bit)
Link for those who are unfamiliar. https://www.nsf.gov/news/special_reports/i-corps/
I think the more important thing is to become deeply curious and well educated about how the world works. I don't see how to do that without a grounding in history, philosophy, psychology, literature, etc. but there are many ways to get that grounding besides formal schooling.
The key is to move from "pretend startup" to "real startup" - which is 100% possible inside an established company if the leadership wants it to happen. But it is not easy; it requires significant changes to many of the company's systems, including HR and Finance.
To know if it's likely to work ask yourself: 1. does the startup have the authority to operate autonomously or does it need endless approvals and permissions? 2. does the startup have a clear board that it is accountable to for both funding and pivot decisions? 3. is the statup cross-functional across all the functions required to build the product? 4. are the members of the startup full-time on just that one thing? 5. is the budgeting process metered (ie fixed rounds of funding) or entitlement based (ie annual appropriates with quarterly adjustments)?
If you don't have good answers to all five of these questions, you're probably playing startup more than real startup.
So, as a citizen of the USA: come here, help make us great As a citizen of the world: transform your city into a startup hub
I guess what I'm saying is there is some truth to the saying that "Silicon Valley is a state of mind" and also some truth to the saying "that sounds great but a lot of the money is on Sand Hill Road."
Everyone I've heard talking about transforming cities into startup hubs, always frames it as "make some good startups and everything else will come."
It all depends on what you are trying to learn. What has to be true in order for your new product or project to succeed? How can you find that out cheaply and quickly? And what if you chose tools for speed of testing rather than efficiency of production?
I've been amazed how many hardware and industrial companies have been able to adopt lean startup, even in situations I would have previously thought impossible.
1) How can you quickly validate a business with very little immediately visible value to the user? Direct user interviews won't work here because the service is very data-driven (collecting filesystem events), so it'll require a decent amount of data collection from the user (I'll offer something like a 14-30 day trial to allow this). Since it has to be done over a longer period of time, and it includes collecting information that might be sensitive to some people, it's not very easy to fully validate the business. I've had a few friends using it, and I'll be sharing with a small beta user list soon, but otherwise I was wondering if you had any other ideas.
2) I've put off writing the payment processing code, focusing on the product itself. Especially considering the "trial" period necessary to see value, are there any downsides to releasing the MVP without allowing payments and then adding them in after release? (Other than no cashflow of course...)
Thanks! I'm actually reading through the lean startup now (after reading way too much of it's principles on the internet first). So it's neat to be able to communicate with the author directly like this.
Remember that not only does your product have to create value for customers but they have to realize that it will create value for them, and both assumptions are important to test.
I saw you speak some years ago right around the time your first book came out. I have a media background, and I noticed some parallels with what you described at IMVU and what I have seen in my industry.
Typically, the projects have involved large media companies building high-quality products/brands, such as television shows or websites. They are designed and built in near-stealth mode with limited opportunities for user testing or audience feedback, and sometimes (but not always) fail miserably when they are released to the world. Conversely, there are examples of media programs/products/brands being developed in a highly iterative/audience-focused approach and sometimes (but not always) leading to a hit or at least becoming self-sustaining.
My question is this: Generally speaking, can “lean startup” concepts be applied to media or other industries, or do the unique characteristics of those industries — for instance, high cost structures or dependence on industry-specific business models - make it difficult to really leverage the software-focused product development concepts you outlined?
I hope to develop a framework with which to approach product development in my own industry (“lean media”) and would greatly value any feedback/ideas/suggestions for further reading you may have.
Thanks!