Mentalidad de Producto: ¿Por qué es tan difícil desarrollarla?

Por: Andrea Santacruz y Diana Barreno

Al iniciar la construcción de un producto, se suele poner énfasis en los hitos que se quieren alcanzar, las características que debe tener, y las formas de trabajar en el agilismo que se van a emplear. Aunque se habla mucho de la entrega de valor, como equipo no se llega a interiorizar el significado del mismo en el contexto del cliente, y por ende tener una mentalidad de producto parecería una condición compleja de alcanzar.

Como consultores, desarrollar esta capacidad es tan importante como cualquiera de las habilidades claves requeridas por rol o nivel técnico. Es por ello que en este artículo, hemos desarrollado cuatro puntos de conversación para que puedan ser discutidos dentro de los equipos y así poder implementar este tipo de mentalidad dentro de tu proyecto.

Proyecto vs. producto

Es muy frecuente toparse con estos dos conceptos que en ocasiones se pueden llegar a confundir como uno solo; sin embargo, son muy distintos. Un proyecto es una serie de tareas que necesitan ser completadas en una fecha acordada para alcanzar un resultado específico. Por otro lado, un producto representa valor para el consumidor o cliente quien está dispuesto a pagar por un beneficio percibido (Haines, 2019) o como lo menciona Melissa Perri, un “producto es un sistema de intercambio de valor” tanto para el usuario como para el mismo negocio.

Empresas como John Deere, mencionadas en el libro ‘Escaping the Build Trap’, son un claro ejemplo de un enfoque de producto vs proyecto, considerando al usuario como centro para entender las necesidades o problemáticas, y a partir de ello poder desarrollar un producto que brinde valor. En el caso del equipo de desarrollo de esta empresa, al vivir en zonas urbanas fueron motivados a ir a los campos de cultivo a ver en acción a sus clientes (granjeros) para poder ganar más contexto.

Este enfoque permite continuar con la evolución de los productos y crear ciclos de entrega de valor constantes en lugar de una entrega final acumulada del producto. Diferenciando de esta forma la gestión de un producto a la de un proyecto.

Espacio del problema vs. Espacio de solución

El gran objetivo de iniciar la construcción de un producto de software es ayudar al usuario a eliminar o disminuir sus puntos de fricción. Y en ese afán de ayudar, se puede caer en el error de pensar directamente en la solución en lugar de tratar de entender a fondo cuáles son los problemas de nuestros clientes, ya que el cerebro humano tiende a pensar en términos de solución, que suele terminar en una fijación de la misma.

Para definir el problema que se quiere resolver, se puede optar por realizar entrevistas o sesiones de exploración con los usuarios/clientes en los cuales se llegue a entender la causalidad de sus problemas y alinearlos con los objetivos del negocio.

Una vez que entendemos el problema, podemos pasar a plantear hipótesis y proponer experimentos que nos ayuden a aprender si la solución planteada es adecuada. Experimentar es construir algo para aprender, para validar o invalidar una hipótesis, por lo cual el experimento planteado para dicha hipótesis no debe durar mucho tiempo. Dentro de la experimentación existen algunas técnicas que nos pueden ayudar con esta fase: Prototipos, Concierge experiments, Wizard of Oz, Concept Testing. En este punto se debe resaltar que invertir en la construcción de un experimento genera un aprendizaje con el cual podemos ser más eficientes en el planteamiento de una solución y por ende obtener mayores ganancias por el mismo.

Mentalidad del departamento vs. Mentalidad de la organización

En las organizaciones tradicionales, las directrices estratégicas generalmente son tomadas por un consejo directivo, las cuales son asignadas y ejecutadas por cada área de la organización para conseguir el objetivo planteado. Pero hoy en día se ha evidenciado que las empresas más innovadoras tienden a obtener retroalimentación más rápida del usuario final, que permite validar si la estrategia planteada es la que se debe seguir o quizá sea necesario reformularla.

Generalmente se suele poner énfasis en que las áreas de tecnología tengan esta capacidad de ser adaptables y puedan reaccionar de manera rápida a los cambios del mercado; no obstante, esta rapidez de reacción puede ser ralentizada por los procesos burocráticos de otras estructuras de la organización de las que tenga dependencia. Es por esto que resulta necesario que los cambios estratégicos que se den sobre la marcha, sean capaces de ser sintonizados por toda la organización y esta pueda adaptarse rápidamente en otra dirección así como poder trabajar en equipos autónomos que permitan tomar decisiones oportunas para la consecución de objetivos.

Métricas de valor vs métricas tradicionales de éxito

La cultura empresarial tiende a tomar decisiones en base a métricas tradicionales que monitorean el avance de un proceso (outputs) en lugar de enfocarse en medir la obtención de resultados tangibles (outcomes). Por ello en el ciclo del producto, en empresas tradicionales con negocios digitales modernos, se viene trabajando constantemente con métricas alineadas a los outputs, tales como número de funcionalidades construidas, velocidad esperada de desarrollo o número de puntos por iteración, y no en idear métricas que definen qué hace que nuestro producto sea valioso para el cliente o usuario final como NPS, porcentaje de retención,porcentaje de adopción, aumento del LTV, entre otros.

En conclusión, desarrollar una mentalidad de producto conlleva un esfuerzo constante que implica cambiar nuestra forma tradicional de pensamiento y de trabajo dentro de una organización. Desde reaprender lo que conocemos por años sobre la gestión de proyectos de software, a verlo ahora como un producto único para cada cliente. Esto implica, entre otras cosas, reformular nuestras métricas de éxito (outcomes), dejar de percibir a la experimentación como un gasto sino una inversión a futuro, añadir a nuestra cultura los ciclos rápidos de retroalimentación como una forma cotidiana de trabajo, y entender el problema antes de pasar a la solución. Con estos cambios dentro de la mentalidad del equipo, podrás evidenciar resultados, tanto en el corto como en el largo plazo.

Disclaimer: las declaraciones y opiniones expresadas en este artículo son las de l@s autor@s y no reflejan necesariamente las posturas de Thoughtworks.

¿Quieres formar parte de Thoughtworks Ecuador? Aplica a nuestras vacantes en nuestra página web https://thght.works/3F3T4JA