La guía que me hubiese gustado tener cuando empecé a trabajar con productos digitales

Déjenme contarles una (no tan) breve historia personal:

Programación

Desde chiquito lo que siempre me gustó fue resolver problemas. Tuve la suerte, gracias a una increíble escuela, de dar de muy chico mis primeros pasos en la programación (apróximadamente 7 años). A medida que fui creciendo fui conociendo otros programas, hasta que realmente tuve la capacidad de hacer cosas que tuvieran utilidad real. Todavía me acuerdo cuando hice mi primer calculadora, una cosa espantosa que ocupaba toda la pantalla con unos 15 botones del tamaño de un caramelo… pero cumplia su función.

Luego de varios años trabajando en el rubro programación decidí que lo que más me gustaba era estar del lado de la generación de productos que ayuden a la gente a través de la tecnología.

Producto

En el medio de mi vida de programador estaba en boga una metodología ágil que se llama Scrum que me gustó al momento de haberla conocido, y profundice mucho en su conocimiento y aplicación con mis equipos. Pero además, por primera vez veía en esa metodología el rol del “Product Owner” que era la mejor descripción de aquél que traducía lo que la gente / negocio necesitaba en soluciones que podamos construir.

Le puse punto final luego de varios años al apasionante rubro de la programación (que al día de hoy me sigue encantando) y empecé mi incipiente carrera en el área de Producto. Vostu, la joven empresa a la que me sumé, era un emprendimiento que hacía juegos para redes sociales y el primer juego que me tocó fue el de Poker.

Para resumir mi experiencia: primer trabajo como Product Owner, pésimo jugador de Poker, y mis conocimientos de redes sociales… eh… no tenía ni una cuenta de Facebook.

¿Soy pésimo?

Cuándo me dieron el puesto no tenía ni idea que iba a hacer ni sabía nada de la industria de videojuegos, así que lo primero que hice fue tratar de obtener inspiración en los “número 1”, los otros juegos de poker online y “social” que había en el mercado. Nuestro producto estaba recién lanzado y había montones de funcionalidades para agregar. Así que me puse manos a la obra: identificar funcionalidades, encontrar su valor potencial, entender cuánto nos iba a costar y priorizar el backlog.

Y finalmente construimos la primera de esas funcionalidades… y no paso nada… no se incrementó enormemente la cantidad de usuarios, ni tuvimos mucha más retención, ni ganamos mucha más plata. Quizás fue un error de priorización, quizás ese feature no era tan importante… Y entonces construimos la segunda… y no paso nada. Y entre una y otra perdíamos 1 mes, desarrollando, lanzando, esperando resultados… Y nada.

Creo que la frustración que tenía se podía oler en mi piel. Los pensamientos en mi cabeza volaban: había tirado mi carrera de programación, sentía que apestaba haciendo mi trabajo, y me estaba decepcionando a mi, al equipo y a los fundadores de la empresa que habían puesto su confianza en mi.

Saliendo del pozo

De todas formas, no soy de los que tira la toalla fácilmente.

Sumido en ese mar de pensamientos, dupliqué mis esfuerzos. Y de a poco fui entendiendo más de que se trataba el rol, y entiendo a mirar métricas con mucho mejor criterio, y a entender mejor al usuario que estaba atrás del producto, y cómo la comunicación era a veces más importante que el feature en sí.

Así fue que llegué a la conclusión que tenía que cambiar mi enfoque. Siempre me gustaron mucho las metodologías, y si bien Scrum (y las metodologías ágiles en general) eran excelentes para la construcción de software, no alcanzaban a la hora de construir productos innovadores.

Lo que tenía que hacer para cambiar era dejar de buscar inspiración en lo que los número 1 habían hecho, y entender cómo lo habían logrado.

Fueron pasando los años, las experiencias profesionales, y mediante algunos cursos y lecturas fui dando con eso. Libros como “Lean Startup”, “Inspired”, “Don’t make me think” fueron construyendo un conocimiento base de cómo hacer las cosas distinto, sumados a workshops puntuales sobre innovación cómo “Lean Startup Machine Workshop”, “Design Sprint” y “How to create products customers love”.

¿Cómo resultó?

Los resultados fueron increíbles: lo que logramos fue pasar de probar una idea por trimestre a una por semana… eso logra básicamente innovar 12 veces más rápido. Y no lo conseguimos cambiando o ampliando el equipo, o trabajando 18 horas por día, lo conseguimos cambiando las prácticas para poder iterar de forma mucho más barata y veloz.

¿Cómo puedo ayudar?

Cuando empecé a trabajar en el área de producto no tenía idea en lo que me estaba metiendo, y la información que había era o bien escasa o bien dificil de encontrar/acceder.

Me llevó años, esfuerzo, muchas equivocaciones (y bastante veces sentirme un inútil) antes de poder entender mejor el rol y encontrar una metodología que sea adecuada. La diferencia en resultados que tengo hoy versus cuando empecé es abismal: probamos ideas más rápido, entendemos mejor lo que el cliente quiere, y en consecuencia logramos mejores resultados para el negocio.

Mi objetivo es poder facilitarle a quienes estén interesados material que ayude a achicar la curva de aprendizaje, para que otros puedan evitarse ese tiempo y errores que yo pase.

Por eso armé una guía con la metodología de Product Discovery, la que me ayudó a buscar innovar 12 veces más rápido, y que sinceramente me hubiese gustado tener ese día que empecé a trabajar en Vostu en el videojuego de Poker. ¡Te invito a descargarla!

Descargar la guía gratuita

---

Me gustaría pedirte 1 minuto de tu tiempo para conocerte mejor. Al final de todo vas a poder dejarme un comentario. Me encantaría que escribas cuál es tu principal desafío o el tema principal que te gustaría saber/hacer mejor. Y qué resultado desearías lograr si pudieras mover una varita mágica y resolverlo.

Desde ya te aseguro que voy a leerlos todos. Mi objetivo es poder orientar mejor el contenido que estoy produciendo y ayudar de la mejor forma posible 🙂

Te dejo mi ejemplo más reciente:

-Desafío: Me cuesta mucho realizar una entrevista efectiva a usuarios. A veces caigo en preguntas muy abiertas sobre las que me cuesta sacar conclusiones. Y a veces hago preguntas demasiado guiadas que se que condicionan la respuesta.

-Resultado ideal: Me gustaría tener un script muy claro, adaptable a las necesidades del producto que estoy investigando, y una guía que pueda repasar en 5 minutos antes de la entrevista y me dé las pautas para hacer preguntas efectivas.

Desde ya no te preocupes por la longitud o el formato. Para mi lo más importante es conocer tu respuesta 🙂

¡Mil gracias! Realmente significa mucho para mi.