El otro día pregunté a varios ingenieros senior de un equipo si estaban involucrados en las fases iniciales de producto. Me respondieron que sí, estaban involucrados en Discovery. Me resultó raro, ¿estáis seguros?
Efectivamente, ellos llamaban Discovery a otra cosa. Os cuento.
En su caso, el equipo de PMs les contaba la solución que habían pensado implementar para que el equipo de ingeniería "descubriera" que hay que hacer y estimara el coste. Los PMs usarían eso en el planning del quarter.
Por supuesto, esto no es Discovery.
Este equipo tiene que mejorar en varios aspectos:
-
El equipo de ingeniería no entiende el problema. Les viene dada la solución. Pueden participar del diseño, pero si no entienden el problema ni el valor a ofrecer a los usuarios, ¿cómo van a tomar las mejores decisiones?
-
Una solución puede que resuelva, o no, un problema. Sin embargo, un problema tiene múltiples soluciones. Si ingeniería no participa de la elección del approach, del shaping, posiblemente no estemos eligiendo la solución que aporte el mayor valor a menor coste.
-
Como a los ingenieros les viene dada la solución, no van a entender del todo bien qué habrá que hacer y no estarán intrínsecamente motivados por ella. Por tanto, – como me dijeron – suelen dar estimaciones mucho más altas para cubrirse las espaldas.
-
Al no participar de entender los problemas, ingeniería no piensa pro-activamente en que tecnologías podrían ayudarnos a dar un salto en resolver los problemas que tenemos.
Muchas veces, una tecnología habilita soluciones que nos parecían ciencia ficción. Debemos experimentar. Mi recomendación es que como equipo de producto (todos los perfiles) dediquéis tiempo a entender y comunicar los problemas que tiene la empresa y vuestros clientes.
Hablad con clientes, entended los problemas – no las soluciones dadas – de vuestros stakeholders internos e invertir algo de tiempo para explorar prototipos con clientes. Compartidles un concepto con voz, o un diseño en figma muy alto nivel. Validad ideas locas, y no tan locas. Haced PoCs con tecnologías nuevas. Explorad continuamente el futuro. Descubrid el futuro. Eso es Discovery.
También puede interesarte

40 clics para pagar dos horas de aparcamiento
Un parquímetro me ha recordado por qué contar los clics y los segundos que le cuesta a tu usuario completar una tarea es clave al diseñar un producto.

5 comportamientos que definen a un Product Engineer
La IA hace que programar sea rápido. El reto que queda es entender el problema, plantear una buena arquitectura y fasear con criterio.
