- Muchas empresas ralentizan su desarrollo por quedar atrapadas en procesos complejos o requisitos interminables, pero lo que de verdad importa es crear rápido el “producto correcto”.
- Si se eliminan los elementos innecesarios del proceso de desarrollo, la velocidad de desarrollo del producto aumenta muchísimo. Crear el producto correcto es, en esencia, un proceso rápido.
- Lo que frena la velocidad de los equipos de producto son elementos innecesarios como los procesos, la distancia entre quienes toman decisiones y quienes ejecutan, y las especificaciones excesivas.
[Principios para la Product Velocity]
1. Hace falta ‘hacer menos’
- En general, existe un trade-off entre velocidad y calidad.
- La mayoría de las empresas definen requisitos y plazos, y tratan la calidad como un resultado, pero nosotros hacemos lo contrario: definimos un estándar de calidad y pensamos qué podemos lanzar en 60 días.
- Lo importante no es intentar cumplir todos los requisitos, sino terminar rápido lo que realmente importa.
- Si eliminas requisitos y haces solo lo necesario, puedes aumentar tanto la velocidad como la calidad.
- Elon Musk también propone un enfoque similar y dice: “Primero, haz que los requisitos sean menos estúpidos”.
2. El ‘modo tonto’ suele ser efectivo
- Si tomamos como ejemplo el ‘midwit meme’, tanto la gente muy inteligente como la gente tonta coinciden en soluciones simples, mientras que la persona promedio complica innecesariamente los problemas.
- A menudo abordamos los problemas en ‘modo tonto’, tratando de encontrar una solución simple en vez de pensarlo todo de manera compleja.
- Cuando cometemos errores, por lo general fue porque pensamos demasiado; los métodos simples funcionan más seguido.
- Preguntarnos “¿qué haría si fuera tonto?” muchas veces nos lleva a una solución ejecutable.
3. No todos los problemas son importantes
- Solo unos pocos problemas son realmente muy importantes. Los problemas críticos, como la seguridad, sí hay que resolverlos, pero no hace falta resolverlos todos.
- Por ejemplo, la UI móvil no es buena, pero como los clientes casi no usan móvil, no la estamos mejorando.
- De esta forma, los problemas que a los clientes no les importan demasiado pueden ignorarse.
4. Simplemente constrúyelo
- No tenemos un proceso para el desarrollo de producto. No hacemos mockups en Figma, PRD, sistemas de diseño, agile, OKR, una hoja de ruta de producto definida, A/B testing ni growth hacking.
- Como nuestros clientes son ingenieros, esperamos que nuestros ingenieros puedan encargarse también del producto, el diseño y demás.
- Preferimos construir el producto rápido y observar la reacción de los clientes.
5. Reescribir, cuando haga falta
- Muchas empresas creen que pueden moverse más rápido si posponen la deuda técnica el mayor tiempo posible, pero a nosotros no nos incomoda hacer reescrituras grandes cuando hace falta.
- A veces, el camino más rápido para construir lo correcto es construir primero lo incorrecto, darte cuenta de que está mal y reemplazarlo por lo correcto.
- Si parece útil eliminar deuda técnica, lo haremos.
6. Subcontratar cuando sea posible
- Siempre que se pueda, compramos soluciones de proveedores externos en vez de construirlas internamente. Por ejemplo, generamos SDK mediante un proveedor llamado Fern.
- Claro, usar proveedores implica un costo inicial considerable y limita el grado de libertad, pero por lo general es la decisión correcta.
- Nuestros recursos de ingeniería son muy limitados y caros; una semana del tiempo de un ingeniero cuesta alrededor de 5 mil dólares. Si se considera el costo de oportunidad, su valor es mucho mayor.
- En realidad, hay relativamente pocas cosas que verdaderamente valga la pena construir.
7. No contratar
- No esperamos que aumentar el personal incremente la producción del equipo. Contratar es lento y difícil, y el onboarding y la gestión de personas consumen tiempo.
- En especial, es difícil incorporar gente capaz de contribuir sin necesitar mucho apoyo.
- Por eso, incluso teniendo recursos para construir un gran equipo de ingeniería, hacemos todo lo posible por seguir siendo pequeños. Eso hace la vida mucho más fácil.
Reflexión final
- Nos dimos cuenta, en una medida que antes no habíamos comprendido, de que el desarrollo de producto no debería tomar tanto tiempo.
- Si sabes lo que necesitan los clientes, tienes un equipo sólido y eliminas los elementos innecesarios que distraen, puedes desarrollar productos a alta velocidad.
10 comentarios
Yo también vine a verlo otra vez. Nos vemos de nuevo la próxima.
Se ve bien una y otra vez.
?? Es bastante idealista.
Los costos de gestión del outsourcing y los recursos que habría que invertir ahí no deben ser poca cosa... Aun así, en términos generales, es un consejo excelente.
Siempre dicen que hay que usar outsourcing. Pero casi nunca veo cómo se supone que debe hacerse cuando lo usas.
Si entregas solo un boceto simple sin una visión clara del servicio, terminas recibiendo cosas peores de lo que esperabas, sin siquiera darte cuenta de ello....
???: Por favor, háganlo rápido, pero sin que sea ágil.
Creo que es posible cuando el producto está claro
Cuando lo que hay que hacer es evidente, se siente que cualquier diseño adicional más allá de eso es innecesario.
"Primero, haz que los requisitos sean menos tontos"
Si un día la empresa subcontratada desaparece... si no contestan el teléfono T_T
Aunque sea desarrollo interno, si un día todos renuncian de golpe, ¿no sería una situación parecida..?