Construir software y construir un producto parecen lo mismo, y no lo son. La primera es la habilidad que ya tenés: tomar un problema técnico definido y resolverlo con código. La segunda es decidir qué problema vale la pena resolver, para quién, cómo saber si lo resolviste y cómo lograr que la gente lo use. Lo primero te lo enseñaron. Lo segundo, casi seguro que no.
La buena noticia es que construir productos también se aprende. No es un talento misterioso que tienen algunos. Es un conjunto de habilidades que se pueden desarrollar en un orden lógico. La mala noticia es que no se enseñan juntas en ningún lado, y la mayoría de los devs las van aprendiendo a los golpes, proyecto fallido tras proyecto fallido.
Vamos a poner ese aprendizaje en orden, así te ahorrás los golpes.
Habilidad uno: entender problemas, no pedir features
El primer músculo a entrenar es dejar de pensar en soluciones y empezar a pensar en problemas. Como dev estás entrenado para recibir un requerimiento y resolverlo. Para construir producto tenés que dar un paso atrás y preguntar: qué problema real tiene una persona, qué tan grande es ese problema, cómo lo resuelve hoy.
Esto se aprende haciéndolo. Empezá entrevistando gente sobre algún problema que te interese. No les preguntes si usarían tu idea. Preguntales cómo resuelven hoy ese problema, qué les molesta, cuánto tiempo o plata les cuesta. Las respuestas te van a sorprender, y casi siempre van a cambiar lo que pensabas construir.
Habilidad dos: decidir qué no construir
La segunda habilidad es la priorización, y para un dev es contraintuitiva. Tu instinto va a ser construir todo lo que se te ocurra, porque podés. Pero un producto que hace muchas cosas a medias pierde contra uno que hace una cosa muy bien.
Aprender a priorizar significa elegir el problema más doloroso de tu usuario y resolver solo ese, al principio. Todo lo demás se descarta o se posterga. Practicá esto preguntándote, frente a cada feature que querés agregar: si solo pudiera construir una cosa este mes, sería esta. Si la respuesta es no, no la construyas todavía.
Habilidad tres: medir comportamiento
La tercera habilidad es aprender a leer si tu producto funciona. Acá tu cabeza de sistemas juega fuerte a favor, pero el objeto de estudio cambia. Ya no mirás logs de errores, mirás comportamiento de personas.
Quién entra, qué hace, dónde se traba, en qué momento abandona, quién vuelve. Aprender a instrumentar esto y a leerlo es lo que te separa de construir a ciegas. Empezá midiendo una sola cosa que importe de verdad en tu producto, y obsesionate con entender por qué ese número sube o baja.
Habilidad cuatro: que la gente se entere
La cuarta habilidad es la que más resistencia genera en los devs, y es distribución. Podés construir el mejor producto del mundo, pero si nadie sabe que existe, da igual. Llegar a los primeros usuarios es un trabajo en sí mismo, y conviene pensarlo desde el principio, no después de lanzar.
Esto no significa volverte experto en marketing. Significa tener una hipótesis clara de dónde está tu usuario y cómo va a llegar a tu producto. A veces es un posteo bien escrito en el lugar correcto. A veces es hablar de a uno. Lo importante es que tengas un plan, por chico que sea.
El orden importa
Estas cuatro habilidades no se entrenan todas a la vez. Se entrenan en secuencia, y cada proyecto que hagas es una oportunidad de practicar una mientras usás las que ya tenés.
La forma más rápida de aprender a construir producto es construir productos chicos y reales, uno detrás de otro, y sacar una lección clara de cada uno. El primero te va a salir mal y está perfecto. Lo que no podés hacer es quedarte solo en la parte que ya sabés, que es programar, y evitar las otras tres porque te incomodan. Ahí es donde se quedan trabados la mayoría de los devs que quieren construir lo suyo.
El primer paso es saber dónde estás
Es difícil entrenar una habilidad que no sabés que te falta. Antes de meterte en tu próximo proyecto, conviene tener una lectura honesta de cómo estás parado en cada uno de estos músculos.
En ProductPrepa armamos una autoevaluación gratuita que mide tu nivel en los dominios del trabajo de producto. En cinco minutos te muestra dónde tu cabeza de dev ya juega a favor y qué te conviene desarrollar para construir productos que la gente use.
Hacé la autoevaluación y descubrí tu punto de partida.