Tres restricciones que imponer antes de construir
(jordanlord.co.uk)- Las ideas de producto deben imponer primero restricciones para reducir el espacio de exploración y evitar que terminen siendo demasiado complejas o sin identidad
- Toda idea debe quedar resumida en un one pager de una sola página; si no cabe ahí, hay que asumir que todavía necesita más investigación, planeación y prototipos
- Junto con el producto, hay que construir una core tech que pueda sobrevivir por separado, para que siga siendo un activo acumulativo incluso si cambia la dirección
- En el centro del producto debe haber una defining constraint que el usuario vea constantemente, y esa restricción define de forma natural el feel y la identidad del producto
- Si no pasa хотя sea uno de los tres criterios, la postura correcta es no construirlo, porque eso es importante para el control del alcance y para asegurar apalancamiento a largo plazo
Tres restricciones que imponer antes de construir
- Si se establecen restricciones antes de crear un producto, se reduce el espacio de exploración y se evita terminar con algo complejo o sin identidad
- Tras 10 años construyendo distintos productos, se vio que los productos demasiado complejos o sin identidad terminaban fracasando, y después de muchos intentos y errores eso se condensó en tres criterios
-
Si pasa de una página, no se construye
- Toda idea debe organizarse en un one pager, y ese documento funciona como north star
- El one pager debe ser innegociable, preciso, ambicioso y al mismo tiempo sin relleno
- El mismo documento puede usarse para comunicarse con inversionistas, colaboradores, miembros del equipo, amistades y familia
- Si durante la colaboración aparece un conflicto, lo que no esté en el one pager no vale la pena discutirlo; si de verdad importa, hay que corregir el documento para reflejarlo
- Si ni siquiera se logra llenar una página, no se trata de inflarla a la fuerza, sino de asumir que todavía no está lista para construirse
- En ese caso, primero hay que pasar por investigación, planeación y prototipos y luego volver a escribir el one pager
- Si se extiende más de una página, entonces es demasiado complejo, así que no se construye
-
La tecnología central debe estar separada del producto
- Aparte del producto en sí, hay que crear una core tech que lo sostenga
- La core tech puede ser una metodología, una tecnología, una herramienta o incluso otro producto, y debe poder sobrevivir aunque el producto actual desaparezca
- Esta separación evita quedar encerrado en un solo producto y permite que la acumulación continúe aunque haya un cambio de rumbo
- Los productos cambian de dirección con frecuencia, pero la core tech queda como un activo persistente y acumulativo
- A largo plazo, este tipo de esfuerzo acumulado puede generar beneficios no lineales
- Se mencionan como ejemplos git de Linus Torvalds, HCL de HashiCorp y Kubernetes de Google
- No hace falta contar con recursos del nivel de una gran empresa; también puede ser una librería separada del codebase o una metodología que se va refinando continuamente
- La core tech debe ser independiente de la dirección del producto, pero sí debe estar alineada con la visión de largo plazo de la persona o la empresa
- Si una idea no permite desarrollar core tech, entonces no ofrece suficiente apalancamiento
-
Una sola restricción decisiva debe definir el producto
- En el centro del producto debe existir una defining constraint que el usuario vea siempre
- Esa restricción debe ser un elemento con el que el usuario se encuentre e interactúe constantemente, y es lo que forma la identidad del producto
- Una buena restricción crea el feel del producto y se filtra en toda la experiencia de uso
- En Minecraft todo está hecho de bloques, e IKEA se define por muebles flat-pack de autoensamblaje; así, la identidad se revela directamente desde la restricción
- Este tipo de restricción reduce el espacio de decisiones, limita el alcance y ayuda a enfocarse en los problemas realmente importantes
- Si no se elige una restricción, o se elige mal, el producto termina desviándose hacia algo inflado que quiere hacerlo todo
- Cuando hay una restricción bien diseñada, el diseño del producto surge de manera natural a partir de ella
- Esta restricción también debe ocupar un lugar central en el one pager
Criterio final
- Si no pasa хотя sea una de las tres restricciones, no se construye
1 comentarios
Opiniones de Hacker News
A esto yo le he llamado primitivas de producto
Cosas como los blocks de Notion, los messages/conversations de Telegram, los frames/layers de Figma, los tweets de Twitter, las cells/sheets de Excel, los tools/layers de Photoshop y los commands de la CLI.
Creo que un buen diseño de producto surge cuando la cantidad de estas primitivas es muy pequeña.
Un mal producto no sabe cuáles son sus primitivas, o tiene demasiadas, así que cada elemento dentro del producto se siente como algo separado que va por su lado.
Entonces el usuario tiene que aprender un montón de conceptos de alto nivel distintos, se confunde, se intimida y además se vuelve difícil de enseñar.
Idealmente, con una, dos o tres primitivas clave debería bastar.
La complejidad y la potencia de una app vienen de elegir primitivas profundas y combinables.
Como el block de Notion, la cell de Excel, el command de la CLI o el block de Minecraft: unidades pequeñas con las que se puede hacer muchísimo.
Esto se parece al Alexandrian Pattern Language, pero en realidad parece más cercano a los Centers de los que Alexander habló después que a los patterns.
Según lo entiendo, la industria del software adoptó ampliamente sus patterns, pero en sus últimos años Alexander veía la unidad fundamental definitiva de un sistema como el Center.
Cosas como un patio luminoso, un asiento junto a la ventana o una chimenea: puntos de utilidad local y cohesión.
Un center fuerte se combina de manera natural, resuelve tensiones locales, está compuesto de centers más pequeños y sirve como bloque de construcción que crea centers más grandes.
Cuando un producto se vuelve confuso y se hincha, por lo general no es por mala intención.
Las necesidades del usuario pueden encontrarse de forma relativamente empírica, pero la estructura central real que las absorbería con elegancia es muy sutil y difícil de descubrir.
Por eso, para cada necesidad inmediata, siempre termina siendo más fácil pegarle una interfaz rígida y específica.
Encontrar la primitiva central que absorba esas necesidades de forma natural requiere un trabajo profundo de arquitectura.
Tal vez por eso al final terminamos construyendo una y otra vez faster horses.
Antes yo lo llamaba conteo de conceptos.
Normalmente conviene minimizar la cantidad de conceptos clave que componen un producto, y a veces también se les llama sus nouns and verbs.
Esta filosofía parece estar excesivamente simplificada.
Tana prácticamente solo tiene dos primitivas, bullets y supertags, y aun así es tan complejo de usar que para tareas muy simples hay que ver tutoriales de horas.
En cambio, Google Maps tiene bastantes primitivas, pero para el 90% de los casos de uso la UX está bastante bien resuelta.
Yo usaba un criterio parecido también para evaluar lenguajes de programación.
Aunque el lenguaje fuera grande, si era conceptualmente pequeño, una vez aprendido el resto llegaba con la experiencia acumulada; en cambio, un lenguaje conceptualmente grande tenía una barrera de entrada alta.
Un caso donde lo sentí con fuerza fue perl.
Debe ser pequeño, pero no demasiado pequeño.
El ejemplo clásico es shell script (POSIX shell, bash), que intentó modelar incluso el scripting como command para no introducir conceptos nuevos, y el resultado, como todos sabemos, fue una mezcla caliente, lenta y desordenada.
Me gustan las tres restricciones, pero creo que el documento de una página debería variar según la complejidad del proyecto.
Para un proyecto pequeño o mediano, una página bastaría, pero si se trata de software de control de vuelo a Marte, antes de empezar la implementación podría hacer falta un one-pager con enlaces a muchísimas subespecificaciones.
Separar la tecnología y el producto es realmente una decisión inteligente.
Por ejemplo, en Skype estaban la tecnología backend de comunicación P2P y la aplicación frontend de llamadas, y los fundadores inteligentes pusieron ambas en empresas separadas.
Así, incluso después de que Skype, la app frontend, se vendiera a Microsoft, la empresa con la IP principal y la tecnología backend P2P podía seguir conservándose por separado.
Poner una sola restricción en el centro también tiene sentido, pero a veces me parece mejor tener varias restricciones o una lista de prioridades.
Si el principio más alto es difícil de monetizar, tratarlo como un dogma inmutable puede empujar al negocio hacia la quiebra.
Si dentro del equipo hay una idea para hacer un pivot fuerte hacia una dirección mucho más fácil de vender, aunque sea bastante distinta de la original, podría abrir una salida.
Twitter también fue un caso en el que iban a hacer otra cosa y las public status update surgieron como un proyecto secundario.
Este texto resumió muy bien cómo antes construía negocios junto con mi mentor de investigación.
Nosotros primero fijábamos las dos últimas cosas, es decir, la tecnología central y las restricciones.
La tecnología central era un sampler que permitía un hierarchical Bayesian graph model arbitrario para sparse data, y la restricción era que debía poder calcularse con CPU-bound.
Lo que más tiempo nos tomó fue darnos cuenta de que el producto final debía estar separado de la tecnología subyacente.
Ya antes de empezar varias personas me habían dado consejos parecidos, pero hay lecciones que solo se te quedan en el cuerpo cuando las vives tú mismo.
La idea del one-pager es realmente buena.
Si no puedes dedicar tiempo ni siquiera a escribir con claridad las restricciones en una sola página, al final vas a descubrirlas tarde y a las carreras mientras avanzas.
Y eso no termina siendo un bug, sino un defecto del nivel de estábamos construyendo lo equivocado.
No puedo probarlo con datos, pero por mi experiencia, los proyectos donde todos están conceptualmente en la misma página tienen muchas más probabilidades de salir bien.
Incluso un documento de alto nivel de una sola hoja sirve mucho si deja claro qué estamos haciendo y qué no estamos haciendo.
En cambio, los proyectos impulsados de forma improvisada terminan decepcionando incluso a las personas que nunca expresaron claramente lo que pensaban.
Me habría gustado que el autor mostrara un ejemplo completo donde las restricciones realmente funcionen.
Sobre todo, no me queda muy claro cómo se vería en la práctica el tercer punto.
Al final parece que igual uno tiene que inventarse algo por su cuenta.
Me parece buena una idea como everything's a file en Linux.
Con un concepto fuerte así se puede llegar bastante lejos.
Las restricciones están subestimadas.
Las soluciones más elegantes normalmente no salen de una libertad infinita, sino de construir con restricciones claras.
Y eso también conecta con el punto 1.
El propio proceso de escribir el one-pager ayuda a definir esas restricciones.
Que Google tenga Kubernetes parece responder, antes que nada, a un objetivo de neutralizar a la competencia.
Si fuera un solo SaaS, la restricción que yo añadiría sería: ¿puedo conseguir un usuario beta esta semana?
Aunque tiempo, alcance y tecnología se vean bien en el one-pager, si no entra nadie, el proyecto muere ahí mismo.
Por eso, poner desde el principio una restricción de distribución me hizo validar la demanda antes de profundizar demasiado en las funciones.
La idea de que la tecnología central debe poder separarse del producto me hace pensar que podría empujar a abstraer demasiado pronto y abusar de los patrones de diseño.
Claro, tiene sentido separar responsabilidades y mantener limpia la división entre la capa de dominio del negocio y cosas como persistence/network/UI.
Aun así, la capa de dominio al final no puede evitar estar muy fuertemente atada al producto.
No creo que haya forma de evitar eso.
Tal vez se refiere a que hay una capa externa que atrae a los compradores, mientras que lo que realmente mueve el interior no es algo que les importe a los compradores.
Puede haber algunos conceptos que sirvan de interfaz entre las dos capas, pero parece decir que la forma en que evoluciona el interior debe estar separada de la capa externa del producto.
Ahora mismo estoy diseñando la remodelación de una cocina, y se me ocurre que estas tres restricciones podrían servir bastante también para tareas de diseño más generales, no solo para software.
Yo también voy a probarlo de inmediato.
Puede que suene demasiado simple, pero si se mira en términos de espacio y flujo se vuelve más interesante.
Puedes pensar en el flujo de personas, el flujo de luz, el flujo de alimentos y las transiciones, así que resulta bastante entretenido.