Los equipos de productos están cada vez más en evidencia. Es muy común encontrar a estos equipos. No importa el tamaño ni el segmento de actuación de las empresas en los que estén inseridos.

Este artículo es el primero de la serie en la que abordaremos conceptos relacionados con nuestro equipo de productos. Dividiremos los temas en los siguientes tópicos:

Parte I: Por qué creamos un equipo de productos.

Parte II: Cómo aplicamos el concepto de MVP.

Parte III: Cuál es la influencia real de los datos en nuestras decisiones estratégicas.

Introducción

Antes de comenzar a desarrollar el tema sobre nuestro equipo de productos, cabe una pequeña introducción sobre la empresa en que estamos inseridos.

MZ es una empresa líder en el mercado brasileño en el sector de relaciones con inversionistas y tiene 19 años de existencia y consolidación en el mercado. Nuestro principal objetivo es cumplir íntegramente nuestro propósito de facilitar y agregar cada vez más valor a nuestros clientes. En este contexto, vimos la necesidad de cambiar el rumbo de la compañía.

Decidimos entonces preparar la empresa para un mundo cada vez más rápido y digital. Con este foco, iniciamos los procesos de transformación digital y cultural. En este proceso, diseñamos toda la operación de la empresa alrededor de los nuevos productos que estamos construyendo. Para eso, invertimos en tecnología de punta y cambiamos la forma como trabajábamos hasta entonces.

Una de las primeras acciones efectivas que ejecutamos fue la creación de nuestro equipo de productos, que pasó a ser responsable del nuevo posicionamiento.

Para entender lo que representa este cambio, es esencial que miremos nuestro pasado. Durante mucho tiempo, nuestros equipos estuvieron divididos de la siguiente forma:

Equipos de negocios: responsables de identificar las necesidades de nuestros clientes y asegurar que se satisficieran todas sus necesidades.

Equipos de tecnología: responsables del mantenimiento de los productos existentes y del desarrollo de nuevas funcionalidades especificadas por el equipo de negocios.

Este modelo, a pesar de ser utilizado por diversas empresas, tiene algunas fallas, entre las que podemos destacar:

• El equipo de negocios no tiene el conocimiento necesario en tecnología. Con eso, acaban surgiendo diversos productos “fantasmas” que no pueden ser reaprovechados y demandan mantenimientos futuros, además de costos para la empresa.
• El equipo de tecnología no tiene un entendimiento claro del posible crecimiento de los productos; de esta forma, las decisiones estratégicas raramente son efectivas.
• Documentación extensa y dificultad de control: En un mundo ágil y de cambios, la entrega debe ser rápida. Transformar mantenimientos en megaproyectos causa un trastorno para todos los involucrados (cliente y equipos internos).
• Dificultad de actualización: El proceso de creación de nuevas herramientas y de actualización de las tecnologías existentes se hace extremadamente difícil. Son muchas reglas de negocios distribuidas por todas las aplicaciones creadas.

Al mirar el escenario, percibimos la extrema necesidad de tener un control más rígido de nuestros productos y asegurar que se desarrollen solamente funcionalidades efectivamente relevantes.

Al analizar el mercado y las empresas actuales, nos deparamos con diversos ejemplos de funcionamiento. Dos ejemplos nos llamaron la atención y resolvimos estudiarlos a fondo para aplicar sus conceptos a nuestra empresa: Spotify (Squads) y Google (OKRs).

Estructura del equipo (Squads)

El requisito básico para alcanzar la excelencia es tener profesionales con diferentes calificaciones trabajando juntos en pro de un propósito. Entonces, creamos un equipo de productos compuesto por:

Los principales desafíos de este equipo son asegurar que el equipo de desarrollo producirá solamente lo que generará valor para nuestros clientes y que podrá ser escalable y replicable, así como analizar todos los datos generados por la plataforma y tomar decisiones sobre las funcionalidades existentes (cambiarlas si es necesario o inclusive descontinuarlas).

El hecho de tener un equipo multidisciplinario es fundamental para cumplir nuestros objetivos. Conseguimos analizar el producto de punta a punta entendiendo si es posible crearlo con la tecnología existente (especialistas técnicos), si generará beneficios para el mercado que buscamos (especialistas RI), si está bien diseñado/estructurado, si será aceptado por el público (especialista UX) y si el momento para su lanzamiento es oportuno (líder).

Prototipado y validación

Hay mucha literatura sobre cómo debe ser la rutina de un equipo de productos. Optamos por seguir las enseñanzas de Google Ventures (GV), que pueden encontrarse aquí: http://www.gv.com/sprint/

Nuestros sprints, así como el de GV, se dividen en cinco días. Cada día tiene sus actividades específicas y el fin de la semana (viernes), conseguimos aprobar o no nuestra idea. Si es aprobada, esta funcionalidad sigue para el equipo de desarrollo para ser implementada.

De forma bien resumida, para nuevas funcionalidades, trabajamos con el principio de que no hay necesidad de implementación sin validación previa. De esta forma, concentramos nuestros esfuerzos en discutir qué reglas de negocios deben satisfacerse y cuál es la mejor forma de satisfacerlas.

Después de definir lo que deberá entregarse, creamos prototipos funcionales y los validamos con clientes y con otros especialistas. Si tuvimos el aval de más del 75% de nuestro público destinatario, seguimos adelante.

La única regla que no seguimos al pie de la letra es el tiempo desprendido. De acuerdo con GV, sería necesario trabajar enfocados por lo menos seis horas diarias. Debido al hecho de tener una operación esbelta y otras obligaciones, dedicamos sólo un período diario. A pesar de ello, no nos sentimos perjudicados y nuestra tasa de retrabajo en desarrollo disminuyó drásticamente.

Medición y mantenimiento

Para las funcionalidades ya desarrolladas y en uso, no existe nada más asertivo que datos. Conseguimos recoger información diversa sobre utilización, tiempo utilizado en cada acción y facilidad de uso, entre otros.

Con eso, sugerimos cambios diversos (layout, flujo de información o inclusive reglas de negocios) y validamos dichas alteraciones con nuestros clientes/público interno antes de implementarlas.

Lo más increíble de trabajar con datos es que en más del 95% de los casos los cambios sugeridos son muy bien aceptados y elogiados. De esta forma, ahorramos tiempo utilizado en correcciones de bugs y podemos invertir correctamente en la creación de nuevas funcionalidades.

Sin embargo, los datos no eximen la necesidad de interacción con el cliente. Siempre es muy importante escuchar al cliente y validar sus solicitudes. Para eso, utilizamos una herramienta de feedback, un Google Forms con cuatro preguntas. Dichas preguntas permiten que la solicitud/sugerencia se haga de forma estructurada. Evitamos así el tradicional: “Sería muy bueno si…” y cambiamos la sugerencia incierta por algo que realmente generará valor para quien la solicita.

Conclusión

El mundo está cambiando. Surgen nuevas tecnologías cada hora y debemos estar preparados para alcanzar la excelencia y utilizar lo más moderno que existe. Es imposible innovar, mejorar y evolucionar si quedamos enyesados en procesos antiguos y anticuados. La creación de un equipo de productos como el nuestro puede agilizar y asegurar la rapidez necesaria para las evoluciones y adecuaciones necesarias.

Otro punto importante es siempre recolectar datos en cualquier implementación realizada. Hablaremos más sobre esto en el tercer artículo de esta serie.

En el próximo artículo, hablaremos sobre cómo trabajamos el concepto de MVP y cómo éste nos ayuda a ahorrar horas y más horas en el desarrollo de nuestros productos.

Escrito por: Felipe Furlan