Todo equipo de producto enfrenta el mismo dilema incómodo: enviar las mejoras incrementales obvias que los clientes piden y los stakeholders esperan, o invertir en las apuestas ambiciosas que podrían desbloquear la siguiente curva de crecimiento. Elige todo incremental y el producto sigue vivo pero deja de importar. Elige todo moonshot y el equipo se quema antes de que aterrice ninguno.

La respuesta honesta no es ninguno de los dos extremos. Es una asignación deliberada que protege ambos. Este artículo destila un framework funcional del análisis de Adrian Bryant en ProductPlan y añade los guardarraíles que lo hacen sobrevivir la presión trimestral.

Por qué la mayoría de equipos van por defecto a las ganancias rápidas

Tres fuerzas empujan los roadmaps hacia lo incremental:

  • Las peticiones de cliente son ruidosas y específicas. Las apuestas grandes son especulativas; los bug fixes y features pequeños llegan con peticionarios concretos y scope claro.
  • Las revisiones trimestrales favorecen el output visible. Cinco features pequeños entregados a tiempo se ven mejor en una board deck que una apuesta grande aún en discovery.
  • Presión del pipeline de ventas. Cada "perdimos este deal porque no tenemos el feature X" es una forcing function. Pocos comerciales pierden deals por la ausencia de un moonshot.

El resultado son roadmaps que ganan cada trimestre durante dos años y de repente se ven obsoletos porque nadie estaba construyendo lo siguiente mientras los wins incrementales se acumulaban.

La asignación 70/20/10

Toma prestado el modelo del viejo framework de innovación de Google, adaptado para roadmaps de producto:

  • 70% de capacidad en trabajo core: mantenimiento del producto, arreglar issues reales, enviar mejoras pedidas que componen la satisfacción del usuario.
  • 20% en apuestas adyacentes: extensiones del producto core hacia casos de uso o audiencias cercanas. Más riesgo que el core, menos que los moonshots.
  • 10% en apuestas grandes: iniciativas ambiciosas con resultados inciertos y gran upside potencial.

Los porcentajes exactos pueden cambiar por etapa (las startups tempranas se inclinan más 50/30/20, los productos maduros suelen deslizarse a 80/15/5). Lo que importa es el principio: asignación protegida. El 10% no es lo que queda después de que el 70% termine. Es capacidad reservada que se defiende.

Sin protección, las apuestas grandes siempre se las comen las ganancias rápidas. La presión trimestral es asimétrica: el coste de saltarse un moonshot este trimestre es invisible. El coste de saltarse una petición de feature es ruidoso.

Tres guardarraíles que mantienen la asignación honesta

Guardarraíl 1: un bucket de capacidad separado

Haz la asignación explícita en la herramienta de roadmap. Un equipo que trabaja en una apuesta grande del 10% no debería estar también tomando tickets incrementales esa semana. Mezclar capacidades significa que lo incremental siempre gana porque tiene deadlines más claras.

Guardarraíl 2: cadencias de revisión distintas

Revisa el trabajo incremental semanalmente (qué se envió, qué viene). Revisa las apuestas grandes mensualmente (qué se aprendió, cuál es el próximo experimento). La apuesta grande no se mueve en el mismo reloj; revisarla semanalmente crea presión artificial para mostrar un progreso que todavía no existe.

Guardarraíl 3: una vista de portfolio, no por feature

Deja de preguntar "¿este feature va a tener éxito?". Empieza a preguntar "¿el portfolio está balanceado?". Las apuestas grandes deben tener tasas de fracaso altas. Una asignación del 10% donde el 70% de los intentos falla está bien si el 30% que funciona produce outcomes 10x. Una asignación del 100% con 0% de fracasos significa que el equipo en realidad no está apostando.

Cómo identificar una apuesta real vs un feature disfrazado

Muchas cosas se llaman big bets que son solo features grandes disfrazados. Una apuesta real tiene tres propiedades:

  • Resultado incierto: genuinamente no sabes si va a funcionar. Si el equipo puede predecir el ROI por adelantado, no es una apuesta, es un proyecto.
  • Horizonte multi-trimestral: el tiempo desde el inicio hasta el outcome validado supera un trimestre. Las apuestas que se resuelven en 4 semanas pertenecen al bucket adyacente del 20%.
  • Opcionalidad estratégica: si funciona, abre caminos nuevos. Si una apuesta ganadora solo optimiza el camino existente, es trabajo incremental con un precio mayor.

Comunicar el split a los stakeholders

La parte más difícil no es decidir la asignación. Es defenderla frente a ejecutivos, ventas y customer success cuando todos están empujando contra el 70%. Dos movimientos de comunicación ayudan:

  • Hacer la apuesta visible. Muestra el 10% explícitamente en el roadmap público o interno, con la hipótesis. Los stakeholders no pueden quejarse de trabajo invisible.
  • Reportar aprendizajes, no entregables. Para apuestas grandes, tu update trimestral es "probamos X, aprendimos Y, ahora intentamos Z". No "todavía no enviamos nada". Lo primero es un update de portfolio; lo segundo suena a fracaso.

Qué cambia después de un año de asignación disciplinada

Los equipos que defienden el split 70/20/10 durante cuatro trimestres reportan algunos cambios comunes:

  • Una o dos apuestas grandes aterrizan y reconfiguran el producto
  • El pipeline de "próxima apuesta a probar" está lleno porque el equipo lleva un año generando hipótesis
  • Los stakeholders ajustan expectativas y dejan de preguntar por qué los moonshots no se envían cada dos semanas
  • El equipo tiene una historia que contar más allá de "enviamos 47 features este año"

Para llevar

La gravedad por defecto de cualquier organización de producto es hacia todo incremental. Sin asignación explícita, las apuestas grandes se squeezan por la presión trimestral. El split 70/20/10 con capacidad protegida, cadencias de revisión distintas y pensamiento de portfolio mantiene ambos lados financiados. Es incómodo los primeros dos trimestres y obviamente correcto al cuarto.