Precios: Me gusta en Facebook puede tener costos

Riesgos para el bolsillo de poner "me gusta" en Facebook

Por Ariel Baños 

Las opiniones favorable de los clientes
de hoteles en las redes sociales, paradójicamente,
podrían impactar negativamente en su bolsillo en
futuras estadías. Foto: Archivo / Facebook

¿Es mejor quejarse o hablar bien de una empresa para conseguir precios más bajos?

Esta es una pregunta frecuente que se realizan los clientes, en la permanente búsqueda de adquirir aquellos productos y servicios preferidos, a un precio más conveniente.

El inconveniente es que algunas empresas dan señales muy negativas a sus clientes, en relación a la pregunta anterior. Los incentivos se han distorsionado de tal manera, que cada vez más mercados se parecen a la canción "El mundo del revés" de María Elena Walsh. Los premiados son los clientes más conflictivos, y se castiga a aquellos más fieles, que muchas veces suelen hacer correr la voz de su satisfacción.

HABLANDO MAL DE LA EMPRESA

"Llamo para dar de baja el servicio", se apresura a comentar un irritado usuario. Luego de describir brevemente su problema al encargado de Atención al Cliente, llega la rápida respuesta del empleado de la empresa. "No se preocupe señor, para compensarlo por esta situación, a partir del próximo mes lo incluiremos en una promoción especial".

Muchas empresas tienen formalizado en sus procedimientos de retención de clientes, la posibilidad de ofrecer un descuento adicional o una promoción especial. Usualmente se otorga este beneficio de precios sólo a aquellos que presentan una queja por el servicio o bien amenazan con cambiarse a un competidor.

Realizar un descuento o una promoción inmediata al cliente, aparecen como soluciones rápidas ante una emergencia. Después de todo el precio es la variable más fácil e inmediata de modificar.

Sin embargo, aún cuando el resultado pudiera ser exitoso, en términos de retención inmediata de clientes, este tipo de respuestas tiene tres grandes inconvenientes .

En primer lugar no ataca el problema principal del reclamo, generalmente vinculado a la prestación del servicio o características del producto. Sin embargo para la empresa resulta más fácil ajustar el precio (a pesar de su impacto económico), que realizar los cambios necesarios en el servicio o producto para satisfacer al cliente. Al no resolverse el problema de base, la queja del cliente queda latente, con grandes posibilidades de repetirse. En este sentido, un viejo refrán sostiene que "la dulzura de un precio bajo desaparece más rápidamente que la amargura de la mala calidad".

En segundo lugar , aún cuando la reducción de precios ataque el problema de base, que en este caso podría ser una diferencia de precios con un competidor, no es una respuesta consistente. El hecho de realizar descuentos selectivos, si bien minimiza el impacto en los resultados económicos de la empresa, puede generar conflictos, cuando otros clientes adviertan las ventajas de precios que tienen ciertos usuarios. La empresa da señales de inconsistencia y falta de transparencia en las decisiones de precios hacia sus clientes.

En tercer lugar , y la más riesgosa de las consecuencias, es que estas conductas estimulan a los clientes a "comportarse mal". Es decir que ante la evidencia de que aquellos que se quejan frecuentemente y amenazan con comprar a un competidor son los que obtienen los mejores precios, aún los clientes más fieles se ven estimulados a imitar estas conductas. La empresa envía señales muy negativas al premiar los comportamientos más conflictivos, y esto suele agravar la situación, además de afectar la imagen pública de la compañía debido a estas inconsistencias.

HABLANDO BIEN DE LA EMPRESA

Imaginemos que se alojó en un hotel, y tuvo una extraordinaria experiencia por la calidad de atención y las instalaciones. ¿Por qué no recomendarlo a través de las redes sociales? Bueno, paradójicamente, ésto podría impactar negativamente en su bolsillo en futuras estadías.

La suma de opiniones positivas, podría convencer a los directivos del hotel, acerca de la oportunidad de elevar precios o bien reducir las promociones otorgadas. En un foro realizado recientemente por la escuela de negocios española Instituto de Empresa (IE), algunas cadenas hoteleras han revelado que las opiniones de clientes en sitios como Tripadvisor o Trivago , tienen un peso importante al momento de definir sus estrategias de precios.

Si bien esta estrategia es mucho más sutil y difícil de rastrear que la anterior, podría tener efectos muy nocivos en el uso de las redes sociales para expresar preferencias de consumo.

¿Se está llegando demasiado lejos? Indudablemente este enfoque tiene grandes riesgos. Si esta práctica se generalizara, y tomara estado público, los clientes evitarían comentar sus preferencias en las redes sociales o intencionalmente postearían comentarios negativos, con la finalidad de forzar una reducción de precios de las empresas.

CONCLUSIONES

Las empresas deberían ser muy cuidadosas en la utilización de los canales de comunicación con sus clientes. La recepción de reclamos, opiniones o comentarios, no debería utilizarse como un medio para ajustar precios, cualquiera fuera la dirección del ajuste. La utilización indebida de estos canales podría finalmente distorsionar sus verdaderos objetivos, alentando comportamientos nocivos tanto para empresas, como para clientes.

La Nación

Read more »

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.

— Eric Ries, A real Customer Advisory Board

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."

— Eric Ries, The Five Whys for Start-Ups

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.

Devianbits

Read more »

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.

A good split testing environment ensures:

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?

— Eric Ries, Are You Building The Right Product?

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.

— Eric Ries, Net Promoter Score

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.

— Steve Blank, Four Steps to the Epiphany

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.

Devianbits

Read more »

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 (XP, Scrum, TDD) 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.

Devianbits

Read more »

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.

– Eric Ries, Startup Lessons Learned

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 Ries, Steve 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.

– Eric Ries, RailsConf 2011

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

Devianbits

Read more »

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

Read more »