Showing posts with label Lean Startup. Show all posts
Showing posts with label Lean Startup. Show all posts

Monday, January 18, 2010

Startups: Quick and Dirty or Built to Last?

Several years ago, I rented a small house on the San Francisco Bay peninsula. The landlord was a very nice person, but she didn't want to spend a penny more than she had to for anything. In the mid-90's, she built a large house and installed the cheapest double-pane windows she could find. Typically, good windows that are properly installed last at least 25 years, but most of the internal vapor seals on the windows that she installed had broken in less than 10 years. The result was moisture and fogging between the panes that was impossible to remove. She was thinking about selling the house and knew that she could never get a good price with those windows, so she had to replace all of them.

There are times when you should spend money now in order to avoid having to spend more money later; the windows in that house are a good example. By installing good-quality windows when the house was built, the landlord could have avoided the hassle and expense of replacing them a few years later. However, there are also times when it's appropriate to spend the least amount possible building a "disposable" solution.

Software and Internet services startups have to make this same choice all the time: Spend a lot of money up front to get high-quality code that can be used for a long time, or go the cheap and dirty route and get something out that works but will have to be replaced quickly?  The answer depends on what stage your startup is in. If you're just getting started and you're still trying to determine if the opportunity you've targeted is real and your technical solution will work, cheap and dirty is best. You're almost certainly going to throw out your code once, if not multiple times, before you're got the right product/market fit. Once you've got your product/market fit right, you can begin replacing "temporary" code with higher-quality, more maintainable code (I hesitate to say "permanent". because no code should be permanent.)

There are always situations where getting it right the first time is essential, especially in applications used for mission-critical or life-and-death situations. However, for most early-stage startups, cheap and dirty is the way to go, at least at the beginning.

Reblog this post [with Zemanta]

Tuesday, December 08, 2009

What does "Pivoting" really mean?

Lean Startup and Customer Development are techniques/processes being used by a lot of startups, especially software and services companies. A term commonly used in both techniques is "pivoting". It means that the company changed direction--it was developing a floor wax, which no one wanted, so it "pivots" to develop a dessert topping. Gratuitous SNL reference aside, what usually happens is that the company developed a product with one feature set, then learned that what customers really wanted was a different feature set. In forums on the Web, I often read about companies that pivoted, sometimes three or four times.

What pivoting really means is "We got it wrong." Don't take this the wrong way--I've gotten it wrong many times in my career--but often, a company could have avoided pivoting if it had done more homework upfront. So, how do things go wrong?
  • The team understands technology but not the market: They spot what looks like an opportunity, but they don't really understand the domain all that well, so they define a product or service that looks good to them but not to their target customers.
  • They talk to customers but don't listen: Even when a startup sets out to talk to customers, they dismiss negative feedback--perhaps their product is "too advanced" for the customers they're talking to, or the problems that customers are expressing aren't really problems, or frankly, their customers are stupid.
  • They don't ask the right questions, or they don't ask them in the right way: Large and small companies alike distribute huge, complex, poorly organized surveys that scare off respondents, get low response rates and are too small a sample to be representative of their target customer base. Or, they use focus groups, which have their own set of risks and are often used the wrong way (the company wants to get projectable results when they actually get impressions from a small subset of customers).
  • They copy what competitors are doing: The team starts with an existing product or service and then does a variation--cheaper, faster, or more features. That assumes, however, that the competitive benchmark is actually successful or has features worth replicating. It may turn out that the competitive benchmark isn't successful, and the company ends up replicating a failure.
The solution is to understand more, earlier in the process. Whether that means talking to more customers, asking the right questions in the right way, doing more secondary research or bringing a domain specialist into the team, knowing more upfront is likely to result in a better product/market fit, fewer pivots and faster revenue growth and profitability. None of this invalidates creating Minimum Viable Products or an iterative product and customer development process. It just means spending more time to insure that you're pursuing a real opportunity and not a mirage.
Reblog this post [with Zemanta]