Running Lean by Ash Maurya

• Practice trumps theory.
• Today's companies can build anything they can imagine. So the question we are called on to answer is no longer primarily, "can it be built?", but rather, "should it be built?"
• Successful new products require constant, disciplined, experimentation--in the scientific sense--in order to discover new sources of profitable growth. This is true for the tiniest startup as well as for the most established company.
• Most startups still fail. But the more interesting fact is that, of those startups that succeed, two-thirds report having drastically changed their plans along the way.
• So, what separates successful startups from unsuccessful ones is not necessarily the fact that successful startups began with a better initial plan, but rather that they find a plan that works before running out of resources.
• Running lean is a systematic process for iterating from Plan A to a plan that works, before running out of resources.
• The key takeaway from Customer Development can best be summed up as: Get out of the building.
• The key takeaway from Lean Startup can best be summed up around the concept of using smaller, faster iterations for testing a vision.
• Startups that succeed are those that manage to iterate en ought times before running out of resources.
• Startups are inherently chaotic, but at any given poi tn in time, there are only a few key actions that matter. You need to just focus on those and ignore the rest.
• You get a gold star not for following a process, but for achieving results.
• No methodology can guarantee success. But a good methodology can provide a feedback loop for continuous improvement and learning.
• Principles guide what you do. Tc tics show you how.
• The essence of running lean can be distilled into three steps:
• 1. Document your Plan A.
• 2. Identify the riskiest parts of your plan.
• 3. Systematically test your plan.
• Reasonably smart people can rationalize anything, but entrepreneurs are especially gifted at this.
• The first step is writing down your initial vision and then sharing it with at least one other person.
• A single-page business modal is much easier to share with others, which means it will be read by more people and probably will be more frequently updated.
• A key point I would like you to take away for now, though, is that your product is NOT "the product" of your startup.
• Customers don't care bout your solution. They care about their problems.
• Your Jon isn't just building the best solution, but owning the entire business model and making all the pieces fit.
• Building a successful product is fundamentally about risk mitigation.
• Startups are a risky business, and our real job as entrepreneurs is to systematically de-risk our startups over time.
• The bigger risk for most startups is building something nobody wants.
• A startup goes through three distant States:
• 1. problem/solution fit
• 2. product/market fit
• 3. scale
• The first stage is about determining whether you have a problem worth solving before investing months or years of effort into building a solution.
• While ideas are cheap, acting on them is quite expensive.
• A problem with solving boils down to three questions:
• 1. Is it something customers want?
• 2. Will they pay for it? If not, who will?
• 3. Can it be solved?
• Once you have a problem worth solving and your MVP has been built, you then test how well your solution solves the problem. In other words, you messier Whether you have built something people want.
• After product/market fit, some level of success is almost always guaranteed. Your focus at this stage shifts toward growth, or scaling your business model.
• Before product/market fit, the focus of the startup centers on learning and pivots. After product/market fit, the focus shifts towards growth and optimizations.
• Pivot is a term used by Eric Rise to describe a change in direction of a startup while staying grounded in learning.
• The best way to differentiate pivots from optimizations is that pivots are about finding a plan that works, while optimizations are about accelerating that plan.
• You stand to learn the most when the probability of the expected outcome is 50%; that is, when you don't know what to expect.
• In order to maximize learning, you have to pick bold outcomes instead of chain incremental improvements.
• Your first goal should be to establish just ugh of a runaway to allow you to start testing and validating your business model with customers.
• bootstrapping + lean startup = low-burn startup
• The lean startup methodology is strongly rooted in the scientific method, and running experiments is a key activity.
• A cycle around the validate learning loop is called an experiment.
• A book, like large software, is never finished--only released.
• Capture your business model in a portable, one-page diagram.
• Hill climbing is good for finding a local optimum, but it is not guarantee ed to find the best possible solution out of all possible solutions.
• A customer is someone who pays for your product, identify your customers.
• You can't effectively built, design, and position a product for everyone.
• Business plans try too hard to predict the future, which is impossible. Instead, write your canvas with a "getting things done" attitude.
• Doing nothing could also be a viable alternative for a customer if the pain is not acute enough.
• Unique Value Proposition: Why you are different and worth getting attention.
• Be different, but make sure your difference matters.
• The key to unlocking what's different about your product is deriving your UVP directly from the number-one problem you are solving. If that problem is indeed worth solving, you're more than halfway there already.
• Pick your words carefully and own them.
• Words are key to any great marketing and branding campaign.
• Picking a few "key" words that you consistently use also drives your search engine optimization (SE) ranking.
• Bind a solution to your problem as late as possible.
• Failing to build a significant path to customers is among the top reasons why startups fail.
• The initial goal of a startup is to learn, not to scale. So, at first it's OK to rely on any channels that get you in front of potential customers.
• When you don't yet have a tested value proposition, it's hard to justify spending marketing dollars or effort on outbound messaging.
• First sell manually, then automate.
• You have to first sell your product yourself, before letting others do it.
• While referral programs can be very effective in spreading the word about your product, you need to have a product worth spreading first.
• Your MVP should address not only the top problems customers have unidentified as being important to them, but also the problems that are worth solving. By that definition, you should plan to deliver enough value to justify charging.
• I believe that if you intent to charge for your product, you should charge from day one.
• Price is part of the product.
• Every business has a few key numbers that can be used to measure how well it is performing. These numbers are key for both measuring progress and identifying hot spots in your customer life cycle.
• Retention measures "repeated use" and/or engagement with your product.
• An interesting perspective to keep in mind is that anything worth copying will be copied, especially once you start to demonstrate a viable business model.
• Incorrect prioritization of risk is one of the top contributors of waste.
• Uncertainty: The lack of complete certainty, that is, the existence of more than one possibility.
• Risk: A state of uncertainty where some of the possibilities involve a loss, catastrophe, or other undesirable outcome.
• The way you quantify risk in your business model is by quantifying the probabilities of a specific outcome along with quantifying the associated loss if you're wrong.
• Your objective is to find a model with a big enough market you can reach with customers who need your product that you can build a business around.
• The ideal problem/solution team size is two or three people.
• There are many arguments for building your release 1.0 with a small team:
• 1. Communication is easier.
• 2. You build less.
• 3. You keep costs low.
• While it is possible to build a product by yourself, I highly recommend working with at least on other person who can, at a minimum, help to enforce periodic reality checks.
• More important than the number of members is ensuring that you have the right talents withing the team to iterate quickly.
• If you are building a product, you need strong product development skills on your team. Having prior experience building stuff is key, along with expertise in the specific technology you are using.
• The one thing you should never outsource is learning about customers.
• Challenge yourself to find the simplest thing you can do to test a hypothesis. This is an underappreciated skill. Once you truly understand what's riskiest about your product, it's often possible to build something other than the product to test it.
• A falsifiable hypothesis is a statement that can be clearly proven wrong.
• Falsifiable Hypothesis = [Specific Repeatable Action] will [Expected Measure able Outcome]
• Company-wide dashboards are great for on-the-ground tactical analysis, but it is equally important to rep rt on your learning milestones at a strategic level.
• Maximize learning (about what's riskiest) per unit time.
• Product risk: Getting the product right
• 1. First make sure you have a problem worth solving.
• 2. Then define the smallest possible solution (MVP).
• 3. Build and validate your MVP at small scale (demonstrate UVP).
• 4. Then verify it at large scale.
• Customer risk: Building a path to customers
• 1. First identify who has the pain.
• 2. Then narrow this down to early adopters who really want your product now.
• 3. It's OK to start with outbound channels.
• 4. But gradually build/develop salable inbound channels--the earlier the better.
• Market risk: Building a viable business
• 1. Identify competition through existing alternatives and pick a price for your solution.
• 2. Test pricing first by measuring what customers SSA (verbal commitments).
• 3. Then test pricing by what customers do.
• 4. Optimize your cost structure to make the business model work.
• The fastest way to learn is to talk to customers. Not releasing code, or collecting analytic, but talking to people.
• Surveys assume you know the right questions to ask.
• Customer interviews are about exploring what you don't know you don't know.
• The best initial learning comes from "open-ended" questions.
• The problem with focus groups is that they quickly developer to "group think", which is wrong for most products.
• While surveys are bad at supporting initial learning, they can be quite effective at verifying what you learn from customer interviews.
• The customer development battle cry, "Get out of the building", codified by Steve Blank, is simultaneously one of the most basic and difficult practices to implement.
• Don't ask customers what they want. Measure what they do.
• Life is too short to keep building something nobody (or not enough people) want.
• Scratching your own itch is a great way to get started, but you still need to validate that you have a problem worth solving by talking to other people.
• When you are able to nail the customer's problem and help him visualize a viable solution, he will buy from you, provided that you remove other objections--for example, by providing a trial period, making it easy to cancel, and so on.
• Understand your customer's worldview before formulating a solution.
• Understanding your early adopters' existing alternatives is key to formulating the right product. Early adopters will use their existing alternatives as anchors against which they Will judge your solution, pricing, and positioning.
• The best way to uncover the "key" words to use in your MVP is to listen closely to how customers describe their workflow.
• Most customers are great at articulating problems but not at visual ling solutions.
• The more real your demo looks, the more accurately you'll be able to test your solution.
• You can't (and shouldn't) convince a customer that she has a must-have problem, but you Ogden can (and should) convince a customer to pay a "fair" price for your product that is usually higher than what both you and the customer think it is.
• The most effective way to get noticed is to nail a customer problem.
• Usually the right price is one the customer accepts, but with a little resistance.
• Don't ask the customer for ballpark pricing. Instead, tell him your pricing model and gauge his response immediately afterward.
• Reducing the scope of your MVP not only shortens your development cycle, but also removes unnecessary distractions that dilute your product's messaging.
• Your MVP should be like a great reduction sauce--concentrated, intense, and flavorful.
• Don't automatically assume that any features have to be included in your MVP. Start with a clean slate and justify the addition of each one.
• Start with your number-one problem.
• The job of your unique value proposition (UVP) is to make a compelling promise.
• The job of the MVP is to deliver on that promise.
• All your energy needs to be channeled ed toward accelerating learning. Speed is key.
• Chances are quite high that you will not have a scaling problem when you launch.
• Continuous deployment is a practice of releasing software continuously throughout the day--in minutes versus days, weeks, or months.
• Continuous flow has been shown to boost productivity by rearranging manufacturing processes so that products are built end-to-end, one at a time, versus the more prevalent batch-and-queue approach.
• The biggest waste in manufacturing is created from having to transport products from one place to another. The biggest waste in software is created from wain ting for software as it moves from one state to another: waiting to code, waiting to test, waiting to deploy. Reducing or eliminating these wait times leads to faster iterations, which is the key to success.
• Your activation flow describes the path customers take from signing up for your service to having a gratifying first experience.
• Reduce sign up friction, but not at the expense of learning.
• It is generally a good practice to keep your sign up forms short and only collect what you absolutely need, but don't shy away from asking for critical contact information up front.
• The purpose of your marketing website is smile: to sell your product.
• Your marketing website is critical in driving the acquisition trigger in your customer life cycle.
• Acquisition describes the path a customer takes from first landing on your website as an unaware visitor to becoming an interested prospect.
• The landing page is by far the hardest of the three. Its job is to make a case for your product to an unaware visitor in fewer than eight seconds.
• Every page needs to have a single, clear call to action. It should stand out and set a clear expectation as to what happens next.
• An actionable metric is one that ties specific and repeatable actions to observed results.
• The opposite of actionable metrics are vanity metrics, which only serve to document the current state of the product but offer no insight (by themselves) into how you got there or what to do next.
• Metrics can help you identify where things are going wrong, but they can't tell you why. You need to talk to people for that.
• Before selling your minimum viable product (MVP) to strangers through your distribution channel, sell it face to face to friendly early adopters. Learn from them. Then refine your design, positioning, and pricing for launch.
• If you can't convert a warm prospect in a 20-minute face-to-face interview, it will be much harder to convert a visitor in less than eight seconds on your landing page.
• The fastest way to learn from customers is to talk to them.
• Contrary to popular belief, you won't be bombarded with phone calls.
• Email is a very effective (and often underutilized) medium for engaging your customers. Everyone has an email address. Email can be automated, tracked, and measured.
• You stand to learn as much (if not more) from your lost sales as you do from your sales.
• Your goal is to establish "just enough" traffic to support learning.
• Simple products are simple to understand.
• Building great software is hard.
• First troubleshoot and resolve issues with ousting features before chasing new features.
• Put down the compiler until you learn why they're not buying.
• Features always have hidden costs.
• More features mean more tests, more screenshots, more videos, more coordination, more complexity, and more distractions.
• A good rule of thumb for prioritizing focus is to implement an 80/20 rule.
• Most of your time immediately after launch should be spent measuring and improving existing features versus chasing after shiny new features.
• A key principle of Kan ban that works to constrain the work queue involves setting limits on the number of features that can be in progress at any given time. This allows you to maximize throughput while minimizing waste.
• In a lean startup, a feature is only "done" when it provides validated learning from customers.
• Because you have a finite work-in-progress limit, you need to carefully prioritize your backlog queue against your product's immediate goals.
• Once you have identified a feature, the first step is to test to see if the problem is worth solving. If you can't justify building the feature, kill it immediately.
• Surveys are more effective at verification than learning.
• Achieving product/market fit or traction can fundamentally be reduced to building something people want or, in other words, delivering on your UVP.
• You have early traction when you are retaining 40% of your activated users, month after month.
• While revenue is the first form of validation, retention is the ultimate form of validation.
• Focusing on scaling your business before you can demonstrate early traction is a form of waste.
• Once you can demonstrate early traction, your focus should shift toward achieving sustainable growth.
• Churn rate is the fraction of customers who leave or fail to reaming engaged with a product after a given time period.
• Viral coefficient measures the number of converted referrals per customer.
• What's stopping your business from growing 10x?
• Every product has to start by demonstrating and delivering a basic value proposition to customers.
• Study your baseline customer life cycle to identify any particular usage patterns.
• Once you've selected your key meaning of growth, put a stake in the ground: Declare the key metric and improvement you want to achieve. Then, align your next set of experiments toward that goal.
• Once your value metrics are validate at a micro scale, you need to race toward your critical network tipping point using the viral engine of growth. Once there, you can look to validate your attention currency through means such as advertising, premium memberships, or something else.
• Matching buyers and sellers s a hard problem.
• Getting to product/market fit is the first significant milestone of a startup. At this stage, some level of success is almost guaranteed and your focus can now shift from learning to scaling.
• Every process works well until you add people.
• The key is to build a continuous learning culture of experimenters versus specialist is, where it's everyone's job to be accountable toward creating and capturing customer value.
• At every stage of the startup, there are a set of actions that are "right" for the startup, in that they maximize return on time, money, and effort. A lean/bootstrapped entrepreneur ignores all else.
• Seed stage investors are just as bad at guessing what products will sauced AA's you are. Without any product validation to rely on, they hedge their bets against your team's track record and storytelling ability.
• Time is more valuable than money.
• Constraints drive innovation, but more important, they force action.
• With less money, you are forced to build less, get it out faster, and learn faster.
• Until you find a problem worth solving, it really don't make sense to quit your day job.
• The biggest burn in a software business is people. Hardware is cheap. Rent, don't buy. Don't scale until you have a scaling problem. Don't hire until it hurts.
• Make a goal of first covering your hardware/hosting costs, and then your people costs.
• It is very tempting to take on unrelated consulting to survive, but it becomes very hard (if not outright impossible) to build a great product in parallel. Instead, look for other related stuff that you can sell along the way.
• IN a lean startup, eliminating waste is a fundamental principle.
• Waste is any human activity which absorbs resources but creates no value.
• Of all resources, there is no resource more valuable than time. Time is more valuable than money. While money can fluctuate up or down, time only moves in one direction.
• Managers typically organize their day into one-hour blocks, and spend each hour dealing with a different task. Maker, like programmers and writers, need to organize their day into longer blocks of uninterrupted time. The cost of context switching is low (and expect) in a manager's schedule. It is high (and a productivity killer) in a maker's schedule.
• Establish uninterruptible time blocks for maker work.
• Achieve maker goals as early in the day as possible.
• Scheduled manage activities as late in the day as possible.
• Always be ready for unplanned activities like customer support.
• Iterate around only three to five actionable metrics.
• A few actionable metrics are all you need to identify and prioritize the most critical issues to tackle.
• Building software to specifications is hard enough that, when faced with a startup environment where both problems and solutions are largely unknown, it is optimal to iterate around less code and more learning.
• Avoid overproduction by making customer pull for features.
• Eighty percent of your effort should be spent toward optimizing existing features versus building new ones.
• Time-based trials help time-box your pricing experiments so that you can force a conversion decision, which allows you to learn and iterate faster.
• Many services make the mistake of giving away too ouch under their free plans, which leads to very low or no conversions. One reason for this is that creatives are especially know to undervalue their own work and are really bad at setting pricing.
• Pricing should be set with the buyer in mind, not the seller.
• Your free user are not your customers (yet).
• Free users aren't "free".
• Even though the operational costs of carrying a free user may seem low, they aren't zero.
• Since your eventual goal is to charge for your product anyway, why not start there? Pick features and a plan based on what customers will pay for today and sign them on as your first customers. Not only is this simpler to build, but it's also simpler to measure.
• The number-one way to get a prospect to agree to an interview is to "nail his problem".
• The purpose of each sentence should be to get the next one read.
• Code in smaller batches.
• The basic idea here is to deploy less code but more frequently. The definition of a small batch is relative, but strive to make it as small as possible.
• Another practice for reducing work-in-progress inventory is to not use any branching in your source control tree.
• The longer you stay of the trunk, the more integration debt you collect, which again inevitably leads to more integration risk, coordination, and planning headaches.
• Testing is everyone's responsibility.
• Outsource as much of your server infrastructure as possible.
• Spending effort setting up and configuring your own servers at this stage is a form of waste. You should instead pick a cloud or platform provider and focus all your efforts on building your application, not your infrastructure.
• Deploy manually first, then automate.
• A feature flipper system uses flags in your code that allow you to enable/disable features on a per-user basis.
• The Pareto Principle: Roughly 80% of the efforts come from 20% of the causes.
• The continuous deployment cycle has a built-in feedback loop that helps you build this monitoring incrementally.
• The Five Whys is a questions-asking method used to deplore the cause/effect relationships underlying a particular problem. Ultimately, the goal of applying the Five Whys method is to determine a root cause of a defect or problem.
• A key design principle is to decouple data collection from data visualization.
• Log everything.
• A good practice to complement tracking raw events is to log every "potentially inter sting" property along with each event.
• Every product has a core set of user actions that track ongoing representative usage.