Durante años, el dogma ha sido claro: concentra esfuerzo, elige un producto, itera hasta que funcione. Un solo foco, una sola apuesta. El consejo tiene lógica cuando los recursos son limitados y el mercado, estable. Pero hay algo que ese mantra ignora sistemáticamente: qué pasa cuando el producto grande crece sin que nadie haya preguntado si ese crecimiento resuelve algo concreto.
Porque crecer un producto es fácil. Lo difícil es saber por qué lo estás haciendo.
- Un producto grande no es sinónimo de producto valioso: puede ser simplemente un producto con más superficie para el error.
- Varios productos pequeños y bien enfocados no es dispersión: puede ser precisión quirúrgica aplicada a jobs distintos.
Estrategia: El tamaño no es el argumento
Cuando un equipo debate entre "construir una plataforma completa" o "lanzar herramientas específicas", suele estar haciendo la pregunta equivocada. La pregunta correcta no es sobre el tamaño: es sobre los jobs que está intentando resolver.
Un producto grande que intenta servir a diez perfiles distintos con necesidades distintas no es una plataforma potente: es diez productos mediocres cosidos con un mismo login. La ilusión de completitud esconde lo que en realidad es falta de foco. Como ya exploramos al aplicar JTBD para evaluar si una funcionalidad tiene sentido, la pregunta de partida no puede ser "¿qué más añadimos?" sino "¿qué tarea concreta estamos ayudando a completar?".
Un conjunto de herramientas pequeñas, cada una diseñada para un job específico, puede tener más tracción, más retención y más margen —precisamente porque no intenta ser todo para todos.
Decisión: Cuándo la dispersión es, en realidad, precisión
No estamos defendiendo construir treinta productos porque sí. Estamos defendiendo que la decisión de concentración o distribución debe partir de un análisis real, no de una convicción cultural.
El riesgo de apostar por un producto grande no es técnico: es estratégico. Si el mercado se mueve o el job desaparece, has puesto todos los huevos en una cesta que quizás nunca fue la correcta.
La arquitectura de producto —grande, pequeño, modular, monolítica— debería derivarse del mapa de jobs de tus usuarios, no de la narrativa del sector ni de lo que el inversor de turno entiende mejor. Un producto mediano que no ha mapeado sus jobs con rigor tiene el mismo problema que una empresa que lanza IA sin saber qué tarea va a mejorar: confunde movimiento con dirección. Y esto aplica igual cuando hablamos de decidir qué experiencias construir antes de cómo construirlas.
En Room 714 ayudamos a equipos a hacer esa matemática antes de comprometer recursos. Si estás en ese dilema —escalar el producto actual o fragmentarlo en piezas con más foco—, tiene sentido hablarlo antes de que la hoja de ruta ya esté firmada.
