domingo, 22 de enero de 2012

Lean Startup: Aprender (4/4)


The Lean Startup in a Nutshell IV: Learn

In this part of the Lean Startup in a Nutshell series, we finally close the build-measure-learn loop and learn how to—well, learn. Learning is arguably the most crucial step within the feedback loop. If a startup is unable to learn properly, people's time is wasted. Lean means: eliminate waste. Waste is eliminated by learning as much as possible as frequently as possible.
Customer interviews
Learning from accessible and actionable metrics is straightforward. Learning from qualitative one-on-one interviews with customers is harder. When conducting these interviews, the reality distortion field of the founders must be taken into account:
True visionaries spend considerable energy every day trying to maintain the reality distortion field. Try to see it from their point of view – none of the disruptive innovations in history were amenable to simple ROI calculations and standard linear thinking. In order to do something on that scale, you need to get people thinking, believing, and acting outside the box. Their greatest fear is categorically not that their vision is wrong. Their real fear is that the company will give up without ever really trying.
— Eric Ries
Nobody wants to become trapped in local maxima: "Customers don't know what they want." It's true—they don't. So how can we then learn from customers? The rules are simple:
  1. Stay true to the vision—an acute pain that others do not see.
  2. Present the currently specified product to early adopters.
  3. Look for customers for whom your product vision is a perfect fit.
  4. Only if you are unable to find them after extensive trials, pivot.
In a customer interview, you are thus essentially looking for a negative result. It is like a scientific experiment—you are trying to prove your current product vision wrong. It is not that you want to extract feature requests from customer interviews—it is the vision and the founders' intuition which should dictate the next feature additions. You are merely looking for the constant assurance that you are on the right track.
If you are curious to see how a negative result in customer interviews—even withstanding the enormous power of the reality distortion field—looks like, enter Eric Ries:
 "I've never heard of that. My friends have never heard of that. Why do you want me to do that?" It requires a lot of explanation. Instant messaging add-on is not a category that exists in your mind. But since she is in the room with us, we could talk her into doing it. So, she downloads the product. We have her install it on the computer. And then we say, "Okay. It’s time to check it out. Invite one of your friends to chat."
And she says, "No way."
Customer segmentation
One-on-one conversations with customers are a good way to look for patterns in the noise. While you should be ignoring a single feature request made by a single customer, a feature request being articulated consistently across interviews should make you aware of the possibility that you have identified a real need.
Often, using the knowledge from customer interviews is not enough to identify reliable customer segments. Surveys are a good tool to broaden the search. Of course, you always want to know which customer segment is closest to bring you product/market fit.
Segmentation will help you see which customers are the most relevant to realizing the overall vision of your startup.
Customer Advisory Board
The culmination of letting customer feedback penetrate your company as part of an integrated discipline is a Customer Advisory Board:
Here’s what it looks like. In a previous company, we put together a group of passionate early adopters. They had their own private forum, and a company founder (aka me) personally ran the group in its early days. Every two months, the company would have a big end-of-milestone meeting, with our Board of Directors, Business Advisory Board, and all employees present. At this meeting, we’d present a big package of our progress over the course of the cycle. And at each meeting, we’d also include an unedited, uncensored report direct from the Customer Advisory Board.
I wish I could say that these reports were always positive. In fact, we often got a failing grade. And, as you can see in my previous post on “The cardinal sin of community management” the feedback could be all over the map. But we had some super-active customers who would act as editors, collecting feedback from all over the community and synthesizing it into a report of the top issues. It was a labor of love, and it meant we always had a real voice of the customer right there in the meeting with us. It was absolutely worth it.
A Customer Advisory Board is essentially a safety net, safeguarding against the cases where the reality distortion field of the founders clouds their vision.Facebook Beacon comes to mind. A customer advisory board gives the customers the power to break through to the visionaries, essentially begging them for help: Look, we aren't asking for much, but this is absolutely necessary. Please, please, implement this.
Five Whys
Five Whys is one of my personal favorites. It is a technique for solving problems in a sustainable way, not combatting symptoms, but using root cause analysis. Five Whys is easy to formulate. It consists of two distinct steps.
The first step is to ask "Why?" five times whenever there is a problem, going deeper with each question and unconvering the root cause of the problem, not just the surfacing symptoms:
A new release broke a key feature for customers. 
  1. Why? Because a particular server failed.
  2. Why did the server fail? Because an obscure subsystem was used in the wrong way.
  3. Why was it used in the wrong way? The engineer who used it didn't know how to use it properly.
  4. Why didn't he know? Because he was never trained.
  5. Why wasn't he trained? Because his manager doesn't believe in training new engineers, because they are "too busy."
The second step is to make proportional investments at each layer of the problem. For the above example that means that:
  1. The broken release should be rolled back and fixed.
  2. The subsystem should be made less obscure.
  3. The engineer should be trained to be able to use it properly in the future.
  4. A roadmap for setting up a training program should be formulated.
  5. The manager should be talked to and convinced of the value of training.
Five Whys usually traces back a technical problem to a human problem.
Proportional investments are never complete solutions at each problem layer. Rather, they are a first step to improving the situation at that level of depth. Imagine the Five Whys hierarchy as a building. Each floor should be reinforced a little bit. That makes more sense than reworking the entire first floor and leaving the other floors in their desolate condition.
Proportional investments leverage the 80/20 rule. The minimal solutions will always account for the bulk of the problem. With each subsequent Five Whys analysis, similar investments will lead to more complete solutions for those layers which seem to be among the root causes of many surfacing issues.
If you are interested in the detailed mechanics of conducting a Five Why root cause analysis, I highly recommend this in-depth guide by Eric Ries
Conclusion
Learning in a Lean Startup is the hardest part. It takes a commitment to objective standards and scientific methods to break through the reality distortion field. Learning creates anxiety for the founder's ego. Setting up processes designed for continuous learning are thus indispensable for a thriving startup whose success is not based on mere luck, but on method.
This concludes the Lean Startup in a Nutshell series. I have left out some of the concepts which I personally consider more controversial and less well illustrated in detail—such as the subdivision of a startup into two cross-functional teams—, but I bet that you will not have a difficult time continuing your Lean Startup journey on Eric's blog or by reading his book.

Lean Startup: Medir (3/4)

The Lean Startup in a Nutshell III: Measure

In this part of the Lean Startup in a Nutshell series, let us look at how to take the interactions between customers and our code and turn them into valuable data about these customers. Each technique described here is designed to help us become more data-driven and ease decision making by favoring facts over fiction.
Split testing
Spli testing (or A/B testing) is the core technique required to learn about user behavior.
In a split test, we deliver a reference experience to some of our users and an alternative experience to the rest of our users—while measuring the impact of the change within one group as compared to the other.
Split tests should be micro in their scope but macro in their impact measurement. The former means that a split test should test an isolated aspect of the experience, such as adding a feature, changing the appearance of a button, consistently changing a design element across the site, etc.
The latter means that the impact of the change implemented within a split test should be measured in terms of the overall metrics relevant to the business—such as the global signup rate or the revenue per customer—and not in terms of a local click-through or conversion rate.
Eric Ries offers many examples for counter-intuitive—but extremely powerful—insights derived from split-testing. Let me cite only one: When a mere link indicating a premium experience (such as a V.I.P. club) was added to the navigational interface at Ries's company IMVU, this increased the overall revenue per customer even for those customers who never clicked on the link. The mere presence of the link primed the users to make them willing to spend more on the website.
  1. easy one-line implementation for developers
  2. easy reporting to render all test results understandable
  3. starting simple and getting more complex over time
  4. making concrete predictions and testing against these
Cohort analysis
They were adding new features, improving quality, and generally executing against the product roadmap. Each month, their gross numbers move up and to the right. So, they said, they must be on the right track.
Then I asked them this question: what would happen to the company if the entire product development team took a month off and went on vacation? The sales staff would keep signing up new customers. The website would continue to get new traffic from word of mouth. Could they be sure that they wouldn’t—as a business—be making just as much “progress” as they claim to be making now?
In one scenario, they’ve been working overtime, putting in crazy hours, and in the other, they’d be on vacation. If both scenarios lead to the same result, how can the product development team claim to be making progress? To be doing effective work?
Cohort analysis means looking at the new customers who join every day as a distinct group. This enables an organization to ask how today's customers compare to yesterday's, to ask whether measured improvements are not just a result of the already well-working system, but of the most recent changes. It also enables an organization to detect "fake improvements", features or changes which actually worsen the user experience.
For each cohort, you may ask:
  1. What fraction of users signed up?
  2. What fraction of users bought the product?
  3. What fraction of users upgraded to the premium account?
Cohort analysis is also perfect for killing features. Just remove a feature and see what happens. If the relevant overall business metrics don't change, you just improved the product by making it simpler.
Conversion funnels
Sales funnels and customer acquisitions funnels are old and time-tested concepts. Key to building meaningful and trustworthy conversion funnels are person-based analytics (or per-customer metrics) instead of global analytics (or vanity metrics) such as the total number of views or visitors.
There is a great talk by Mike McDerment explaining what he calls the Google Analytics line and how to go beyond it by connecting marketing and customer account databases. Going beyond the line of vanity metrics (such as the total number of page views) is a prerequisite for collecting the data necessary to analyze and build conversion funnels.
I highly recommend the above talk as well as the related article by Eric Ries in order to get started with person-based analytics. Always remember, "metrics are people, too".
Net Promoter Score and product/market fit
NPS is a methodology that comes out of the service industry. It involves using a simple tracking survey to constantly get feedback from active customers. It is described in detail by Fred Reichheld in his book The Ultimate Question: Driving Good Profits and True Growth. The tracking survey asks one simple question:
"How likely are you to recommend Product X to a friend or colleague?"
The answer is then put through a formula to give you a single overall score that tells you how well you are doing at satisfying your customers.
The Net Promoter Score is a powerful concept to get a birds-eye holistic view of your business. It is designed to measure the overall customer satisfaction a product or service yields.
For Sean Ellis, a slightly different question is at the root of determiningwhether a startup has reached product/market fit:
"Would you be very disappointed if you could no longer use the product?" or
"Do you consider the product a must-have"?
Sean Ellis supposes that only when 40% answer "yes" to the above question, the startup has reached product/market fit.
Measuring the NPS and the product-market fit constantly ensures that a startup never forgets the overall picture of improving customer happiness while split-testing and working on conversion optimization. These holistic metrics are probably also the best way to measure product development progress in the long run.
User testing
If Product Development is simply going to start building the product without any customer feedback, why have anyone talk to customers at all? Why don’t you just build the product, ship it, and hope someone wants to buy it? The operative word is start building the product. The job of Customer Development is to get the company’s customer knowledge to catch up to the pace of Product Development—and in the process, to guarantee that there will be paying customers the day the product ships.
User testing is a cheap way to "get out of the building" and talk to customers. User testing means having a bunch of individual users interact with your product or service, giving you qualitative feedback. There are a number of user testing service providers on the web, usually providing a screen-sharing video and a written report for each user doing the test.
Conclusion
Good measurement relies on good and reasonable metrics. It requires an actual understanding of what constitutes progress and how to document it. It puts science ahead of vanity. And it recognizes that metrics are people, too.

Lean Startup: Construir (2/4)


The Lean Startup in a Nutshell II: Build

In this part of the Lean Startup in a Nutshell series, we discuss how to accelerate the first stage of the build-measure-learn feedback loop where we build code from ideas. Each technique is designed to help us build faster and eliminate waste.
Minimum viable product
In product development, the Minimum Viable Product or MVP is a strategy used for fast and quantitative market testing of a product or product feature, popularized by Eric Ries for web applications. — Wikipedia
Or, as defined by Eric Ries himself,
The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. — Eric Ries, StartupLessonsLearned.com
The MVP caters to early-adopter customers:
The minimum viable product is that product which has just those features and no more, that allows you to ship a product that early adopters see and—at least some of whom—resonate with, give you money for, and start to give you feedback on. —Eric Ries, Venture Hacks interview
The MVP falls in between the maximum-feature approach—building a complete product implementing the entire vision of the startup founders—and the "release early, release often" mantra—shipping code immediately, listening to customers, implementing what customers want, repeating the process.
The MVP presupposes a clear long-term vision of a product or service which solves a core problem. It represents the smallest effort of building a product that delivers the promise of that vision to early adopters—the people who have the same visioning power as the entrepreneurs, who will be the most forgiving, and who will fill in—in their minds—the features which aren't yet there.
An MVP can be a crappy first web application, a clickable screen design, a paper prototype, or just a text, video, or graphic describing the problem and the solution embodied in the vision for the product.
Agile development
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
— The Agile Manifesto 
Talking in depth about agile development would require a blog post of its own—or probably even an entire book. Let me thus assume that you are familiar with the basic aspects of the agile methodology (XPScrumTDD) and talk instead about how agile development relates to customer development.
All agile development methodologies, be it XP or Scrum or Kanban, at some point need to answer the question, "What is the most important work we should do right now?". Usually, the answer to this question takes the form of a backlog, a collection of stories to be worked on in the next iteration.
In a Lean Startup, the backlog is fed as part of the company-wide feedback loop, by the new hypotheses derived from actual customer feedback.
Continuous deployment
Remember, a Lean Startup optimizes the total time through the company-wide feedback loop. Imperative to that aim is not to "get stuck" in the build phase for longer periods of time than necessary. Whenever you're working on a current release, make it as minimal as possible. Your aim is to learn as quickly as possible whether the work you are doing makes sense.
Continuous deployment is the natural extension (and completion) ofcontinuous integration:
For those of you with some background in lean manufacturing, you may notice that integration risk sounds a lot like work-in-progress inventory. I think they are the same thing. Whenever you have code that is un-deployed or un-integrated, it's helpful to think of it as a huge stack of not-yet-installed parts in a widget factory. The more code, the bigger the pile. Continuous integration is a technique for reducing those piles of code.
— Eric Ries
What continuous deployment adds to that is to actually deliver the code to the customer to get the company-wide feedback loop running again. It means to overcome the anxiety of occasionally releasing a broken or malfunctioning product and to embrace the power of being fast and flexible enough to fix problems as they occur.
Of course, some development environments—such as the iTunes App Store—restrict the developer's ability to do continuous deployment. In that particular case, try to gain back the freedom of continuous deployment by having an alternate version of the product—a web-based client—running at a faster pace of iteration, or by relocating part of the product's magic from the client side to the server side.
Open-source components
There are two kinds of philosophies: the closed-source world of Microsoft Windows and proprietary systems, and the open-source world of harnessing the world's knowledge and giving back accordingly. I tend to resonate much more with the second philosophy, and it is at the very heart of the Lean Startup.
Leverage open-source technology to its full extent not only to keep costs down, but to increase the speed and versatility of product development early on. Open source operates using the model of commons-based peer production which is proven to be incredibly effective at creating and nourishing extensive collaborative communities and cooperative ecosystems.
If I were to include one specific tool here, it would be GitHub.
The cloud
Cloud technologies—such as cloud computing, cloud storage, SaaS offeringsand IaaS offerings—enable young tech companies to start with zero overhead and practically zero cost while being able to scale considerably onceproduct/market fit is achieved.
Today, there is almost no point in setting up your own data centers upfront, before having validated that you are actually building something people want. My newest startup uses open-source technology (e.g. Ruby on Rails) and cloud IaaS (e.g. Heroku) exclusively in order to achieve a high speed of iteration at low cost.
I believe that the advent of powerful scalable cloud infrastructures with pay-as-you-go models basically supersedes—and renders less important—Eric Ries's concept of just-in-time scalability. If you are interested in the story of just-in-time scalability, enter Eric Ries.
Cluster immune system
The concepts of agile development and continuous deployment may seem quite radical to project managers of older schools, having practiced thewaterfall-style approach to product development. When you think of a product juggernaught such as the Microsoft Windows operating system, for instance, how could you possibly even dare to think about deploying this piece of software continuously?
What if someone breaks an important feature during a deploy? What if someone interrupts the e-commerce flow of an online store system? What if someone hides the "Payout" button in an online payment system, turning the entire business into a hobby (borrowing from Eric Ries)?
These concerns are all valid—unless there are proper defenses in place to guard against such potential dangers. Test-driven development and strict continuous integration rules are among the first lines of defense. The cluster immune system is later-stage, more sophisticated, line of defense.
A cluster immune system is designed to track bad deployments—changes having unintended consequences—to the production environment in real time. It continuously measures the business's core metrics and automatically rejects and reverts changes affecting these metrics in a negative way.
A good cluster immune system would understand that a recent code change made the average order volume drop to about 50% of the original value. It would then revert the change, returning the system to the previous working state. It would also interrupt the deployment pipeline so that further changes would become impossible. It would send an e-mail to the author of the change as well as the whole development team to inform them about the problem. It would only allow deployment to resume once a human got to the root cause of the problem and understood and fixed it.
Building a cluster immune system isn't easy. It doesn't happen in a single day. Cluster immune systems should be built iteratively as well, starting simple and becoming more complex over time. Their development should be driven by the needs of the development team and the particular technology stack used by the team.
Conclusion
Building products in a Lean Startup requires technology and methodologies which enable the development team to iterate as rapidly as possible while remaining as flexible as possible at the same time. The speed of iteration is to be counter-balanced by defensive methods designed to remove anxiety from the team. Making mistakes is vital in a Lean Startup. Design the development environment so that mistakes can never have disastrous consequences.

Lean Startup: Fundamentos (1/4)


The Lean Startup in a Nutshell I: Foundations

I remembered a specific moment from my very first startup. It was the moment I realized my company was going to fail. My cofounder and I were at our wits’ end. The dot-com bubble had crashed, and we had spent all of our money. We were trying desperately to raise more, and we could not. The scene was perfect: it was raining, we were arguing in the street. We literally couldn’t agree on where to walk next, and so we parted, in anger, heading in opposite directions. (...)
It remains a painful memory. We had begun as friends, and ended as enemies. The company limped along for months after, but our situation was hopeless. Looking back, I know our failure was inevitable, because we had no clue. It seemed we were doing everything right: we had a great product, a brilliant team, amazing technology, and the right idea at the right time. (...) But despite a promising idea, we were nonetheless doomed from day one, because we did not know the process we would need to use to turn our product insights into a great company.
When I first read about the concept of the Lean Startup in Eric's blog, it was a fragmented set of ideas, case studies and practices – most of them useful, many of them thought-provoking. Little did I know that it would take this collection of thoughts only a few years to turn into a global movement and a coherent theory of entrepreneurship.
And while the orignal story of the Lean Startup yet remains to be written, let me try to give a practioner's overview of both the theoretical foundations of the Lean Startup as well as the specific tools and techniques it employs to achieve maximum efficiency. The Lean Startup in a Nutshell series will walk you through each of the different building blocks of the Lean Startup, and hopefully turn you into a Lean Startup expert in no time.
None of the ideas presented in this series are original ones. They have all been extracted from the works of Eric RiesSteve Blank, and other evangelists of the Lean Startup movement.
The startup as an experiment

A startup is not a small version of a larger company. It is en entirely different kind of organization, driven by different goals and different needs. In other words: The dollhouse theory of startups is wrong. Neither does a startup need the same departments – engineering, marketing, QA, finance, support, etc. –, nor should it follow the same product development methodology as its hypothetical larger counterpart.
While an established business focuses on executing and scaling a proven model, a startup is essentially an experiment. It is a human institution designed to create something new under conditions of extreme uncertainty – meaning that both the solution to the supposed problem as well as the problem itself are unknown. The purpose of the startup is to find a way of transforming the vision of its founders into a working and sustainable business model before it runs out of money.
The product development methodologies
Every organization strives to solve a problem. In an established business, the problem is well defined. For such a business, both the waterfall and the agile product development methodology may be appropriate, depending on whether the solution to the problem is known in advance or not.
In a startup, all that is certain is the vision of the founders. A startup is thus an organization in search of the right problem to solve. It must develop partial solutions to hypothetical problems while constantly gathering feedback until it is able to figure out what customers really want. The right methodology for a startup is the build-measure-learn feedback loop.
Let us review the three different product development methodologies.
  • The waterfall methodology (known problem, known solution)specifies a linear plan of product or service milestones. It goes from requirements to design to implementation to testing. In the waterfall model, progress is achieved by advancing the plan. Using this definition of progress, whether product development results in success or failure entirely depends on whether the solution to the problem is accurately known in advance and whether the problem is actually a problem customers care about.
  • The agile development methodology (known problem, unknown solution) is an iterative and incremental approach to software development. It emphasises frequent interactions over extensive documentation and the ability to respond to changes in specification over the linearity of advancing a pre-negotiated plan. It is perfectly suitable for situations where it is known what customers ultimately want, but where the team is unable to predict the best way to get there due to a lack of past experience solving that problem. Progress in the agile methodology is measured by lines of working code.
  • The build-measure-learn feedback loop (unknown problem) is the underlying development methodology of the Lean Startup. In essence, it combines agile product development and customer development in a company-wide feedback loop of learning and discovery. In a Lean Startup, progress is measured by validated learning – by the number of full-turns through the entire feedback loop. It is important to understand that unless the whole feedback loop is completed quickly, work carried out in a single stage of the feedback loop (building, measuring, or learning) does not count as actual progress and is very probably a waste of time.
The remaining parts of the Lean Startup in a Nutshell series will discuss the specific techniques to accelerate each stage of the feedback loop in detail.
Pivots and innovation accounting
A startup consists of a vision and a strategy (a business model, i.e. a collection of hypotheses) designed to turn that vision into a real-world business that is creating sustainable value. What I particularly like about the Lean Startup framework is that within it, the vision is the only thing that remains untouched. It is thus in perfect alignment with Simon Sinek's model of the power of purpose and the built-to-last concept.
While the startup's vision functions as the guiding light, its strategy is temporary and fluid until it has been validated by subsequent iteration of the build-measure-learn feedback loop. In the Lean Startup model, a change in strategy is called a pivot, and it represents the most fundamental concept of the Lean Startup:
If you look at the real story, you'll discover this weird zig-zaggy path between the initial idea and the successful idea. (...) It's just that successful entrepreneurs, when they run into difficulty, they don't just give up and go home, but neither do they persevere the plane straight into the ground. They do this thing called the pivot. They change some elements of the business while keeping others constant. They keep a new strategy for achieving the same vision. So you pivot the strategy, you stay true to the vision.
And the premise of the Lean Startup is this: If we can reduce the time between pivots, we can increase our odds of success before we run out of money.
In order to decide whether to pivot or not after an iteration of the feedback loop, we use innovation accounting. Innovation accounting consists of formulating and testing a set of key metrics – quantitative assumptions – by working backwards through the feedback loop:
  1. What are we trying to learn next?
  2. What do we need to measure in order to learn that?
  3. What do we have to build to be able to measure that?
It is time to pivot whenever further iterations of the feedback loop lead to diminishing returns, whenever it becomes unlikely that the quantitative assumptions needed to validate the current strategy can be met at all.
Innovation accounting brings accountability to entrepreneurship: It enables us to know whether we are actually making progress and whether we are getting closer to realizing our vision or not. It empowers us to set goals and decide when to pivot in advance, and act accordingly once we collect the necessary validated learning.
The remaining parts of the Lean Startup in a Nutshell series will discuss each of the three stages of the feedback loop: Build, Measure, Learn.
The Lean Startup in a Nutshell series

Lean Startup: 8 maneras de pivotear sobre la visión


A Smart Business Knows 8 Ways to Pivot Their Vision



Martin Zwilling 


One of the hottest buzzword for startups these days is “pivot.” The term, introduced by entrepreneur and venture advisor Eric Ries in an article on Lessons Learned  a couple of years ago, is properly used to describe smart startups that change direction quickly, but stay grounded in what they’ve learned. They keep one foot in the past and place one foot in a new possible future.
Over time, this pivoting may lead them a bit away from their original vision, but not away from the common principles that link each step. The pivot has to leverage previous learning about customers, technology, and the environment. The alternative is more risky, simply jumping compulsively from one vision to another, and is likely to lead to a death spiral.
The pivot can be applied to any element of the business model, without changing the underlying vision. Here are some of the most common pivot elements that Eric and others have noted:
  1. Customer problem pivot. In this scenario, you use essentially the same product to solve a different problem for the same customer segment. Eric says that Starbucks famously did this pivot when they went from selling coffee beans and espresso makers to brewing drinks in-house.
  2. Market segment pivot. This means you take your existing product and use it to solve a similar problem for a different set of customers. This may be necessary when you find that consumers aren’t buying your product, but enterprises have a similar problem, with money to spend. Sometimes this is more a marketing change than a product change.
  3. Technology pivot. Engineers always fight to take advantage of what they have built so far. So the most obvious pivot for them is to repurpose the technology platform, to make it solve a more pressing, more marketable, or just a more solvable problem as you learn from customers.
  4. Product feature pivot. Here especially, you need to pay close attention to what real customers are doing, rather than your projections of what they should do. It can mean to zoom-in and remove features for focus, or zoom-out to add features for a more holistic solution.
  5. Revenue model pivot. One pivot is to change your focus from a premium price, customized solution, to a low price commoditized solution. Another common variation worth considering is the move from a one-time product sale to monthly subscription or license fees. Another is the famous razor versus blade strategy.
  6. Sales channel pivot. Startups with complex new products always seem to start with direct sales, and building their own brand. When they find how expensive and time consuming this is, they need to use what they have learned from customers to consider a distribution channel, ecommerce, white-labeling the product, and strategic partners.
  7. Product versus services pivot. Sometimes products are too different or too complex to be sold effectively to the customer with the problem. Now is the time for bundling support services with the product, education offerings, or simply making your offering a service that happens to deliver a product at the core.
  8. Major competitor pivot. What do you do when a major new player or competitor jumps into your space? You can charge ahead blindly, or focus on one of the above pivots to build your differentiation and stay alive.
In all cases, the change is not linearly adding one more new feature, in the vain hope that this one will cause traction to magically materialize. The key to pivoting is spotting trends from real data and real market experience, and optimizing the basic product/market fit, without leaving a hole or divot in your market or your credibility.
Look for multiple data points before you pivot. You have to learn that no product will satisfy every customer, so don’t make random jumps based on a single customer, friend, or negative blog article. A good internal data point or early-warning is a chronically frustrated solution team.
Get your investors and advisors to do the pivot exercise right along with you, so there are no surprises. Adaptation and dealing with chaos is the key to survival for a startup, and your best competitive edge over large companies. The down side is that it may be bad for your golf swing.


Forbes

lunes, 16 de enero de 2012

Fijación de precios: 3 tácticas para las fiestas


3 Shopping Cart Promotional Tactics for the Holiday Season


In 2006, a Wharton professor first noticed that online buyers were more likely to respond to a free shipping offer that resulted in a savings of $6.99 over an outright savings offer of $10. The explanation was that it made the online price more comparable with the offline equivalent.
This fascinating insight into buyer motivations has contributed to on a major new piece of research into online buyer behaviour, which I’ve been working on over the last few months. It will be published on December 13th as an ebook titled ‘The Science of Shopping Cart Abandonment.’
To mark Black Friday, I’ve drawn from some of this research to look at the effects of holiday promotions, and how different price points impact buyer behavior. In particular, I’ll look at the relationship between the cart value and the shopping cart abandonment rate.
What are key price points that trigger abandonment? And can different pricing tactics lead to more conversions without eroding margin? I began my research analyzing a random sample of 264,631 abandoned shopping carts in August 2011, from a cross section of B2C e-commerce sites.
What we already know is that the value of the shopping cart has a disproportionate impact on whether an e-commerce purchaser will buy or abandon. What we have discovered is that it’s not a linear relationship and too simplistic to assume this as a general rule. This leads us to conclude that there are three promotional tactics that merchants should test this holiday season to improve conversions:
  1. Offer discounted shipping for low cost shopping carts.
  2. Set a $99 minimum order for free shipping.
  3. Consider specific promotions for individual products with varying abandonment rates.
1. Offer discounted shipping for low cost shopping carts. As might be expected, higher value shopping carts are abandoned more frequently, and as a broad rule, this holds true. Surprisingly though, as you can see in the chart, lower value shopping carts are abandoned often, as well.


What appears to be happening is that customers abandon when the ratio of shipping cost to the value of the cart approaches 100 percent. Many people face an “emotional block” as the shipping costs approaches the cost of the item(s) in the cart. Would you buy a $19.99 item if it costs an additional $14.95 to ship? In this case, the shipping cost is 75 percent of the item value.

Online retailers should review the ratio of shipping-cost-to-cart-value for some of its lower value abandoned carts and then consider adjusting shipping policies to achieve a ratio below the acceptable threshold of 50 percent.

2. Set a $99 minimum order for free shipping. Retailers know that customers are sensitive to perceived price points. For example, a $19.99 item seems to be cheaper than a $20 one, at least by more than 1 cent. We perceive the $20 item to be significantly more expensive, even though we know it is not. As you can see in the chart, online shoppers have the same emotional response. When we analyze the shopping cart abandonment rate curve by smaller price breaks for carts up to $200, we find there’s an emotional hurdle close to $100.



What this means for e-commerce sites is that the abandonment rate spikes at key price points. At $100, the spike is the most significant and has the highest volume, but at $250, $400, and $500, you will most likely see similar spikes. These are great break points for offering minimum order free shipping, which will help with the low value cart/high shipping cost problem by encouraging customers to add more items to their carts to reach the free shipping minimum.

We’ve asked retailers that offer $99 minimum order free shipping how they arrived at that particular threshold. Their answer is that, through trial and error, $99 is the best balance between changing customer behavior and maintaining margin. This data suggests that, from a customer perspective, free shipping just below the critical $100 threshold is well worth testing.

3. Consider special promotions for individual products with varying abandonment rates. Different products get abandoned at different rates, and it’s amazing to see the huge difference. For example: two items at the same online retailer both cost $199. You might not be surprised to learn that an item costing $199 is abandoned frequently, at 95 percent of the time. That means that when this item is added to the cart, the item is purchased only one in 20 times.
But figure this. On the same site at a different item, also costing $199, the item is abandoned only 32 percent of the time, and gets bought two out of every three times. While it is worth evaluating the difference between the product specifics between these two items, online retailers should consider special promotions for the item abandoned more frequently.
If both of these products at $199 are frequently abandoned, we highly recommend further examination. Start by building a spreadsheet of frequently carted items and calculate an abandonment ratio for each product. This will help you identify frequently abandoned items and opportunities for specific product promotions, as well as zero in on other opportunities to optimize the copy on the product detail page to secure the conversion.
These three techniques will help to drive conversions this holiday season. If you are able to offer site wide free shipping as part of your peak promotion package, then this will be universally popular. If you cannot, then minimum order free shipping, together with specific incentives for high abandon or lower value carts should prove a successful formula.



miércoles, 11 de enero de 2012

¿Por qué las consolas son tan baratas?


Unos 300 trabajadores chinos amenazaron con suicidarse

Ensamblaban consolas de videojuegos, pero ante el reclamo de suba de salarios, la empresa Foxconn los echó y no los indeminzó; en 2010 murieron allí 14 empleados



Unos 300 trabajadores de una fábrica de tecnología china, donde se ensamblan dispositivos de marcas como Microsoft, Apple y Sony, se manifestaron en el techo de la empresa donde trabajan y amenazaron con realizar un suicidio en masa si no se resuelve una disputa sobre el pago de sus salarios, según informó The Huffington Post .
Los trabajadores forman parte de las plantas ubicadas en el parque tecnológico de Foxconn Technology en Wuhan en la provincia de Hubei, en China, que actualmente ensambla la consola Xbox 360. La compañía ya ha protagonizado anteriormente incidentes similares, llegando a registrar suicidios de empleados por sus condiciones de trabajo.
De acuerdo con lo publicado, los empleados habían pedido a la compañía un aumento en sus salarios y ésta les había indicado que si no estaban satisfechos con su remuneración que abandonaran la empresa a cambio de una indemnización o continuaran trabajando en las mismas condiciones.
La mayoría de los trabajadores decidieron entonces renunciar a su empleo, pero la empresa no les entregó las indemnizaciones prometidas. Entonces iniciaron su acción de protesta, de la que fueron disuadidos por el alcalde de la localidad.
Las fábricas de Foxconn en China han sido escenario de varios suicidios de trabajadores en el pasado, incluyendo 14 empleados en 2010 en su planta de Shenzhen, por los bajos salarios y las malas condiciones de trabajo. El propio Steve Jobs tuvo que hacer referencia a estas muertes, considerando "preocupante" la cadena de suicidios, pero aseguró que en la fábrica donde se ensamblan iPhones e iPads no había "explotación".

Twitter Delicious Facebook Digg Stumbleupon Favorites More

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Best Hostgator Coupon Code