50 lecciones aprendidas al crear un producto exitoso [artículo traducido]

1. Un equipo pequeño (de 6 personas o menos) puede crear un gran producto, pero debe tener autonomía total sobre la definición de objetivos, la priorización del roadmap, la elección de métricas, la comunicación con usuarios y los despliegues rápidos de código.

2. El éxito de un producto depende de las personas que lo construyen. Subir el nivel de contratación es clave, porque el talento se acumula. Una mala contratación frena la velocidad del equipo más que cualquier otro factor.

3. La confianza es indispensable para crear grandes productos. La falta de confianza es uno de los mayores cuellos de botella de un equipo, y normalmente es el resultado de haber contratado a alguien por debajo del nivel necesario o de no haberle dado feedback adecuado para mejorar.

4. La confianza también se construye con transparencia. Trabaja de forma abierta, debate en espacios abiertos y documenta lo que haces. Así todos comparten el contexto necesario y se eliminan las peleas políticas que aparecen en muchas empresas.

5. Depende de la confianza y del feedback, no de los procesos. Ese es uno de nuestros valores centrales. Crear y hacer crecer cosas que la gente quiere es un problema sutil, así que confiamos en el criterio de las personas. Si algo sale mal, damos feedback directo.

6. La dirección debe compartir los objetivos de la empresa, y el equipo de producto (ingeniería) debe decidir qué construir para alcanzarlos y definir sus propias metas. Ambas partes deben revisar el impacto real mediante métricas y feedback de usuarios.

7. El producto está subordinado al perfil de cliente ideal (ideal customer profile, ICP). El ICP es para quién construyes, y es el factor más importante para decidir qué hacer. Un ICP preciso define no solo al cliente objetivo, sino también todos los aspectos del producto y de la estrategia de entrada al mercado.

8. Para encontrar el ICP, primero haz una hipótesis y pruébala. Haz preguntas al registrarse, compara la retención, identifica a los power users y realiza encuestas NPS. A medida que acumules información y convicción, agrega más detalle.

9. Crea principios de producto. Nosotros usamos principios como “proveer todas las herramientas necesarias para evaluar el éxito, tomar la delantera y actuar como fuente de verdad para los datos del cliente y del producto”. Eso da un lenguaje común para discutir ideas y tomar decisiones.

10. Mapea todo lo que los usuarios podrían querer. Eso hace falta al priorizar el roadmap. Así no pierdes de vista grandes ideas que hoy todavía están más allá del horizonte.

11. Un producto es más que un conjunto de funcionalidades. También es la marca y la experiencia del producto que ofreces a otros. La magnitud de la inversión en cada función, las personas que contratas, las decisiones de construcción, las funciones emblemáticas, la comunicación con clientes y la política de precios: todo eso crea originalidad.

12. El sitio web es la primera impresión del producto. Un sitio aburrido y genérico envía la señal de que el producto y el equipo detrás también son débiles. Crear un sitio propio y distintivo alineado con tu ICP evita eso y ayuda a impulsar la adquisición de usuarios.

13. A veces no es un problema de producto, sino de mercado. Por ejemplo, cuando Tom Blomfield, fundador de Monzo y partner de YC, estaba creando un servicio para dividir cuentas entre amigos de la universidad, recibió el consejo de dejar de construir y enfocarse en conseguir usuarios. Después de 4 semanas de llamadas en frío y conseguir solo a una persona, supo que era momento de pivotear.

14. Si vas a pivotear, hazlo en grande. Stewart Butterfield transformó dos empresas de videojuegos en Flickr y Slack. El cofundador de LinkedIn, Reid Hoffman, dice que para pasar del fracaso al éxito, los fundadores de startups deben hacer slash and burn con el resto del negocio. Si se ve parecido, ve más lejos.

15. Como dice Jason Fried de 37signals: “No puedes validar una idea. Como no existe, tienes que construirla de verdad. El mercado la validará”.

16. Los planes son útiles, pero no para seguirlos de forma rígida. Una buena ejecución no consiste en cumplir un plan específico, sino en repetir el trabajo más importante. Evalúa a las personas no por si “siguen el plan”, sino por lo que entregan, la frecuencia de entrega y el impacto.

17. Posponer algo “solo una semana más” casi siempre es una mala idea. Cuando esa actitud se acumula durante meses, reduce drásticamente el momentum. Cuanto antes pongas algo en manos de los usuarios, antes podrás aprender su valor y mejorarlo.

18. Reduce el trabajo en curso. Un PR debería terminarse en un día; empieza el día respondiendo solicitudes de revisión de otros; haz merge en cualquier momento, despliega detrás de feature flags y prueba en producción. Todo eso reduce la carga de contexto del trabajo.

19. Desplegar rápido es el núcleo de nuestra filosofía de desarrollo de producto, pero tiene trade-offs. La adquisición de tecnología, las reuniones de planificación, los rituales ágiles y la revisión de métricas pasan a segundo plano. El trabajo asíncrono hace esto más posible.

20. Introduce nuevas tecnologías en el producto solo cuando haya problemas urgentes como costos excesivos, problemas de escalabilidad o demandas del cliente. Para encontrar la tecnología adecuada, pregunta cómo lo resolvió tu equipo u otros equipos directamente.

21. Los deadlines artificiales no hacen que un equipo vaya más rápido. Más bien crean un ciclo desastroso de deuda técnica acumulada y burnout. Elimina los procesos que ralentizan al equipo y da a los equipos pequeños autonomía para desplegar rápido.

22. Otra forma de desplegar más rápido es eliminar el diseño por defecto. Una vez que el sistema de diseño esté funcionando, deja que los ingenieros construyan. Si hace falta, luego pule lo ya desplegado con revisiones de diseño.

23. Las feature flags permiten a los ingenieros de producto desplegar cambios rápido, probar en producción y obtener feedback real de usuarios. También reducen el riesgo al funcionar como kill switch cuando algo no opera como se esperaba.

24. En PostHog, la mejor comunicación es el pull request. A diferencia de los mensajes o los issues, convierte el feedback en impacto de inmediato. Encaja con una cultura orientada a la acción y crea un loop de feedback más cerrado.

25. Deja clara la ownership. Eso hace mucho más claro y rápido decidir qué construir. Los equipos que evitan la ownership desperdician tiempo en planificación, brainstorming, reuniones y gestión de proyectos en vez de desplegar.

26. Los ingenieros tienen la capacidad de decidir qué construir. Entienden las limitaciones técnicas, detectan patrones en las funcionalidades y saben cómo resolver problemas. Aun así, puede haber cuellos de botella de información sobre lo que los usuarios necesitan.

27. En vez de controlar a los ingenieros, los product managers deben dar contexto al equipo de producto mediante analítica de producto, investigación de usuarios y análisis de competidores.

28. La mayoría no es Steve Jobs. No tiene una visión total para construir “por intuición” desde el principio ni dibuja el gran panorama. En su lugar, despliega, entrégalo a usuarios y repite el ciclo de feedback. Cuanto más rápido sea ese ritmo, mejor será el producto.

29. Contrata y apóyate en ingenieros de producto. Combinan habilidades full-stack y obsesión por el cliente, ambas necesarias para construir producto. También deben hablar con usuarios, hacer entrevistas, reclutar gente para probar nuevas funciones, recopilar feedback, atender soporte y responder a incidentes.

30. Lee The Mom Test. Enseña cómo conversar sobre los problemas de usuarios potenciales. La clave son dos tipos de entrevistas de usuario: exploración del problema y validación de la solución. La primera guía futuras decisiones de producto; la segunda ayuda a mejorar lo que estás construyendo ahora.

31. Para sacar el máximo provecho a las entrevistas de usuario, ten claro de antemano quiénes son los usuarios (ICP), cómo usan el producto y qué planeas construir después. Así la entrevista aclara el foco del siguiente paso en vez de generar confusión.

32. Entre las posibles cosas por construir, las solicitudes de soporte son las más “reales”. Hay un usuario específico con un problema concreto, así que si lo resuelves, el producto mejora de inmediato. Otros cambios no son tan intuitivos.

33. Cuando los ingenieros se encargan del soporte, se fomenta la ownership de todo el ciclo de vida del producto, desde la ideación hasta la implementación y el mantenimiento continuo. Cada etapa se conecta con las demás al acumular contexto sobre los puntos de dolor reales del cliente y el código detrás de cada problema.

34. Que los ingenieros atiendan soporte acorta el loop entre el problema del usuario y el fix desplegado. No se interponen personal de soporte, product managers ni procesos de planificación. Como extra, a los usuarios les encanta.

35. Usar tu propio producto (dogfooding) ayuda a acelerar la velocidad de despliegue, detectar problemas antes de que lleguen a los usuarios, entender el producto en profundidad y desarrollar empatía con los usuarios. Pero no reemplaza hablar con usuarios, obtener feedback real ni seguir métricas de uso.

36. Así como nuestro equipo de producto resolvió una necesidad propia con un popup de entrevistas, resolver necesidades internas es una buena forma de validar casos de uso. Si deberías usar tu propio producto y no lo haces, es señal de que algo anda mal y hay que corregirlo.

37. Los grandes creadores de producto siempre están prototipando y experimentando. Deben sentirse cómodos construyendo MVPs y pruebas de concepto, desplegando trabajo incompleto, reuniendo feedback y pivoteando si fracasan. También necesitan habilidades para construir desde cero, desde infraestructura hasta diseño.

38. Un A/B test exitoso requiere una buena hipótesis que explique qué se está probando y por qué. Incluye el contexto del test, los cambios, las métricas y el resultado esperado.

39. Al experimentar con producto, asume que puede fallar y que quizá habrá que eliminarlo. Configúralo para que sea fácil quitarlo con feature flags y despliega una versión “suficientemente buena” en vez de una perfecta en mantenimiento y escalabilidad. Ya la mejorarás si funciona.

40. Los experimentos de producto pueden hacerse de forma mucho más “tonta” de lo que crees. En vez de construir toda una funcionalidad, prueba un fake door test: agrega una opción o botón que no lleva a ninguna parte y mira si la gente hace clic.

41. El fracaso de un experimento de producto no es el fin del mundo. En Google, entre 80% y 90% de los experimentos “fracasan”. Puede parecer tiempo perdido, pero a gran escala ese 10% de éxito compensa todo lo demás, como en el A/B test de mostrar titulares en Bing, que elevó los ingresos 12% (más de $100 millones).

42. Si te enfocas en crecimiento, piensa y prioriza como un growth engineer. Identifica el área objetivo, elige una métrica representativa, formula una hipótesis de mejora y crea el experimento más pequeño posible para probarla.

43. Implementar analítica casi nunca es demasiado pronto. Puede no aplicar a un producto antes del lanzamiento, pero lanzar “porque todavía es muy pronto” y sin analítica es una falsa economía. Después del lanzamiento, la prioridad cambia de desplegar a máxima velocidad a desplegar lo correcto a máxima velocidad.

44. Cuando empieces con analítica, arranca en pequeño. Elige un producto o función concreta, sigue el uso con autocapture, visualízalo con gráficos de tendencias y retención, e intenta desplegar funciones que mejoren eso. El “complejo industrial del modern data stack” hace que parezca más complicado de lo que realmente es.

45. Si no sabes con qué métrica empezar, recomiendo activation. Está por encima de otras métricas, los ingenieros pueden influirla directamente y resulta útil para toda la organización.

46. Además de activation, la retención es otra métrica clave para entender el impacto de lo que construyes. Seguir sus cambios semana a semana permite ver si tus modificaciones ayudan a retener usuarios.

47. Al medir product-market fit, revisa si el engagement de usuarios crece exponencialmente más rápido que el crecimiento de usuarios y si la retención se aplana (por encima de 0%). Después, verifica si la retención de usuarios ICP es excelente y si los clientes de pago pertenecen a ese ICP.

48. Las revisiones de crecimiento sirven para comprobar si lo que construye el equipo impacta métricas importantes, como ingresos, analítica de producto y feedback de usuarios. En PostHog, es una responsabilidad clave de los product managers.

49. Si construyes varios productos, trata a cada uno como una mini startup. Que tenga sus propias decisiones de producto, precios, ingresos, costos y coordinación con equipos de cara al cliente.

50. Aférrate a productos que te parezcan interesantes. Como escribió James, cofundador de PostHog, en una guía sobre product-market fit: “Si no te interesa, pivotea. Eso es todo. Logras más cuando te aferras a algo que sientes como propio.”