Qué hacer cuando todavía no tienes product-market fit: cómo distinguir un problema de ejecución de un problema de idea, y qué significa pivotar en la práctica

Qué vas a aprender hoy

En la lección anterior viste dos formas de medir si tienes product-market fit: la encuesta del 40% de Sean Ellis y el análisis de cohortes. Hoy partimos de que el resultado fue “todavía no” y vas a aprender qué hacer con esa información. Vas a salir con una técnica concreta para averiguar si lo que falla es la ejecución (algo que se arregla sin tocar la idea) o la idea misma (algo que exige cambiar una pieza estructural), y con un mapa de lo que significa “pivotar” en términos concretos, no como palabra de moda que se usa para cualquier cambio de rumbo.

Conceptos base

Pivote (pivot): cambio estratégico que modifica uno o varios elementos de un producto o negocio —pero no todos a la vez— para poner a prueba una hipótesis distinta. Un estudio publicado en Empirical Software Engineering (revista académica revisada por pares) que analizó 49 startups de software, citando la definición original de Eric Ries, describe el pivote como “un tipo especial de cambio diseñado para testear y validar las hipótesis sobre un producto, un modelo de negocio y un motor de crecimiento”. La idea central de esa definición es “uno o varios elementos, pero no todos”: pivotar no es tirarlo todo y empezar de cero, es cambiar una pieza concreta mientras conservas el resto, incluida la visión de fondo que te llevó a empezar.

Problema de ejecución: la idea de fondo es razonable, pero algo en cómo la estás llevando a cabo hace que la demanda real se pierda por el camino. Un flujo de registro confuso, un precio mal comunicado, un canal de captación que trae al tipo de usuario equivocado. Se corrige cambiando cómo haces las cosas, no qué haces.

Problema de idea (o de estrategia): la ejecución puede ser impecable y, aun así, no funcionar, porque la hipótesis de fondo es la que falla. Nadie tiene el problema que creías que tenía, o lo tiene pero no con la urgencia suficiente como para pagar por resolverlo. Se corrige cambiando qué haces, no cómo lo haces.

Los cinco porqués (five whys): técnica que popularizó Eric Ries dentro del método Lean Startup y que expone en un vídeo del Stanford Technology Ventures Program. Consiste en preguntar “¿por qué?” de forma encadenada frente a un síntoma, buscando en cada respuesta “las causas raíz —los ‘problemas humanos’— detrás de cada contratiempo técnico”, en vez de quedarse en la primera explicación superficial. El propio material insiste en acompañar el análisis con una inversión proporcional en las personas o procesos que resulten ser la causa real, no solo en arreglar el síntoma técnico visible.

Motor de crecimiento (engine of growth): el mecanismo concreto por el que un producto consigue usuarios o clientes nuevos de forma sostenida —boca a boca, publicidad de pago, o el propio uso del producto atrayendo a más gente, entre otros—. Es uno de los cuatro elementos que un pivote puede tocar, junto con el producto, el equipo y el modelo de negocio. Lo vas a desarrollar en la próxima lección; hoy solo lo necesitas como una de las piezas posibles del cambio.

Desarrollo

”No tener PMF todavía” es un síntoma, no un diagnóstico

El error más común en este punto es reaccionar a la falta de product-market fit como si fuera una sola cosa con una sola solución: o insistir sin cambiar nada porque “hay que darle tiempo”, o tirar la idea entera y empezar otra desde cero. Ninguna de las dos es la respuesta por defecto correcta, porque “no tengo PMF” puede significar cosas muy distintas según de dónde venga el problema. El mismo estudio sobre pivotes de startups de software mencionado arriba identificó 14 factores distintos que llevan a una startup a pivotar, y los agrupó en dos bloques que conviene separar mentalmente: factores relacionados con el mercado (la reacción del cliente, si el problema es lo bastante urgente, si hay competencia que ya lo resuelve mejor) y factores relacionados con la ejecución interna (un modelo de negocio que no cierra números aunque el producto guste, un proceso que no escala). Según ese análisis, “la reacción negativa de los clientes y un modelo de negocio defectuoso son los factores más comunes” que empujan a las startups estudiadas a pivotar. Fíjate en que son dos causas de naturaleza distinta: la primera apunta a la idea (a la gente no le importa lo suficiente el problema que resuelves), la segunda apunta más a la ejecución o a una pieza concreta del negocio (el producto puede gustar y aun así no ser viable tal como está montado el cobro o la operación).

Esto es lo que hace peligroso decidir a ojo. Si el problema real es de ejecución y tú lo tratas como si fuera de idea, acabas abandonando algo que sí tenía demanda real solo porque la envolviste mal. Si el problema real es de idea y tú lo tratas como si fuera de ejecución, te pasas meses puliendo un flujo de registro, un onboarding o un precio para un problema que, dicho sin rodeos, a nadie le importa lo bastante. Antes de decidir qué hacer, hace falta un método para averiguar cuál de los dos tienes.

El método: los cinco porqués aplicados a tu métrica de PMF, no a un bug

La técnica de los cinco porqués se suele enseñar con ejemplos de fallos técnicos (una web caída, un despliegue roto), pero el mismo mecanismo sirve para diagnosticar por qué no llegas al umbral de PMF que viste en la lección anterior. La diferencia respecto a un análisis de causa raíz técnico es que aquí cada “por qué” te obliga a decidir, en cada paso, si la respuesta describe algo que tú controlas de forma directa (ejecución) o algo que depende de una preferencia o urgencia del usuario que tú no puedes fabricar (idea). Un ejemplo aplicado a un desarrollador que ha lanzado una herramienta SaaS pequeña, con datos inventados para ilustrar el mecanismo, no como cifra real de ningún caso:

1. Síntoma: solo el 15% de los usuarios que prueban la herramienta responden “muy decepcionado” en la encuesta de Sean Ellis, muy por debajo del 40% de referencia. ¿Por qué?
2. Porque la mayoría prueba la herramienta una vez y no vuelve a entrar en los siete días siguientes. ¿Por qué?
3. Porque el resultado que obtienen en esa primera visita no se parece a lo que esperaban por el mensaje con el que llegaron (un anuncio, una publicación). ¿Por qué?
4. Aquí es donde la cadena se bifurca, y la bifurcación es el punto que importa: si la respuesta es “porque el onboarding no explica bien cómo sacarle partido en los primeros dos minutos”, sigues en terreno de ejecución, algo tú controlas y puedes rediseñar. Si la respuesta es “porque lo que promete el anuncio no es, en realidad, lo que la herramienta resuelve mejor que las alternativas que ya usan”, has cruzado a terreno de idea: el problema no es cómo lo presentas, es que no resuelve nada que no resolvieran ya de otra forma suficientemente buena.

El valor del método no está en llegar siempre a cinco preguntas exactas —Ries mismo lo plantea como una guía, no como una fórmula rígida—, sino en no detenerte en la primera explicación cómoda. “Nuestro onboarding es confuso” es casi siempre la primera respuesta que se te ocurre, porque es la más fácil de arreglar y la que menos cuestiona tu idea original. Merece la pena seguir preguntando un par de niveles más antes de asumir que ese es el problema real.

Qué significa pivotar, en términos concretos y no como buzzword

Si tras el diagnóstico concluyes que el problema es de idea, el paso siguiente no es “reinventarse” en abstracto. El mismo estudio académico catalogó diez tipos distintos de pivote observados en startups reales de software, agrupados en pivotes relacionados con el producto y pivotes relacionados con el mercado. No hace falta memorizar los diez, pero conviene conocer los que más aplican a alguien que construye un producto o servicio digital en solitario o en equipo pequeño:

• Pivote de necesidad del cliente (customer need pivot): mantienes el mismo tipo de usuario, pero cambias qué problema concreto le resuelves, porque en el camino descubriste una necesidad distinta y más urgente en ese mismo público. Según el propio estudio, este fue el tipo de pivote de mercado más frecuente entre las startups analizadas.
• Pivote de segmento de cliente (customer segment pivot): mantienes el producto casi igual, pero cambias a quién se lo vendes, porque descubres que un tipo de usuario distinto al que imaginabas al principio lo valora más o paga mejor por él.
• Zoom-in: una sola función de lo que construiste se convierte en el producto entero, porque resulta que esa función concreta es la que de verdad genera valor, y el resto era ruido alrededor.
• Zoom-out: al revés, lo que era el producto completo pasa a ser solo una pieza dentro de algo más amplio, porque por sí sola no bastaba para justificar el precio o el compromiso que pedías.
• Pivote de canal (channel pivot): el producto y el cliente se mantienen, pero cambia la vía por la que llega a ese cliente —de venta directa a marketplace, de autoservicio a venta asistida, por ejemplo—.

Fíjate en un patrón común a los cinco: en cada uno, tres de las cuatro piezas (producto, equipo, modelo de negocio, motor de crecimiento) se mantienen razonablemente estables, y una cambia de forma deliberada. Eso es lo que distingue un pivote de un relanzamiento completo, y también de un simple ajuste de producto. Ajustar un botón, cambiar un color o rehacer un onboarding no es pivotar: es iterar dentro de la misma hipótesis. Cerrar el proyecto y montar algo sin relación tampoco es pivotar: es empezar de cero. Pivotar es la categoría intermedia, y es intermedia porque conserva el aprendizaje acumulado en vez de tirarlo.

Antes de pivotar, agota primero la hipótesis de ejecución

Un error frecuente en sentido contrario también merece mención: pivotar demasiado rápido, sin haber probado primero si el problema era de ejecución. Cambiar de idea es costoso —pierdes el aprendizaje específico que ya tenías sobre tu primer público— así que antes de dar ese paso conviene haber descartado con datos, no con intuición, que el problema no se resuelve con cambios más baratos: un onboarding mejor explicado, un precio distinto, un canal de captación distinto que traiga a gente más alineada con lo que construiste. Si después de esos cambios la métrica de PMF sigue sin moverse de forma consistente durante varias cohortes, ahí sí tienes evidencia de que el problema está un nivel más abajo, en la idea, y no en cómo la estás ejecutando.

Aplicación práctica

Coge el resultado de la encuesta de Sean Ellis o del análisis de cohortes que hiciste en la lección anterior (o, si todavía no lo has hecho, el síntoma más claro de que algo no engancha: usuarios que prueban y no vuelven, o que prueban y no pagan). Escribe el síntoma como una frase concreta y aplícale los cinco porqués por escrito, en un documento, no mentalmente: anota cada respuesta antes de pasar a la siguiente pregunta. En cada nivel, marca explícitamente si la respuesta describe algo que depende de ti (ejecución) o algo que depende de una preferencia del usuario que no puedes fabricar (idea). Cuando llegues al punto donde la cadena se bifurca hacia “idea”, repasa la lista de tipos de pivote de este documento y anota cuál de ellos, si alguno, encajaría con lo que acabas de descubrir. No tienes que decidir hoy si pivotar: el ejercicio de hoy es solo llegar a un diagnóstico por escrito, con la cadena de porqués visible, en vez de una sensación vaga de “esto no funciona”.

Errores comunes

Detenerse en la primera respuesta del “por qué” porque es la más cómoda de arreglar, en vez de seguir preguntando hasta encontrar si hay una causa más profunda debajo. Confundir “pivotar” con “cambiarlo todo”: si acabas descartando el equipo, el producto, el modelo de negocio y el motor de crecimiento a la vez, no estás pivotando, estás empezando un proyecto distinto, y conviene ser honesto contigo mismo sobre esa diferencia. Y decidir el pivote basándose en una sola señal aislada o en una conversación puntual con un usuario frustrado, en vez de en el patrón repetido que viste con las herramientas de la lección anterior (la encuesta y las cohortes).

Fuentes

1. Bajwa, S. S., Wang, X., Nguyen Duc, A. y Abrahamsson, P. (2017). “‘Failures’ to be celebrated: an analysis of major pivots of software startups.” Empirical Software Engineering, 22. https://link.springer.com/article/10.1007/s10664-016-9458-0
2. Stanford Technology Ventures Program (STVP). “The Five Whys” (vídeo con Eric Ries). https://stvp.stanford.edu/clips/the-five-whys

Para la próxima lección

Si el diagnóstico de hoy te confirma que sí tienes product-market fit, el siguiente paso es elegir tu motor de crecimiento: qué mecanismo concreto vas a usar para conseguir los próximos usuarios antes de invertir en escalarlo.