El Modelo Operativo de Producto, con Chris Jones de SVPG

En Product Sessions conversamos con Chris Jones, partner de Silicon Valley Product Group (SVPG) y coautor de Transformed junto a Marty Cagan. Chris lleva unos 30 años en producto, 20 de ellos liderando equipos de producto, UX y datos, y los últimos 10 ayudando a empresas de todo tipo a trabajar como las mejores compañías de tecnología. La charla completa está en el video de arriba; acá van las ideas centrales.

¿Qué hace un product manager, según SVPG?

Para Chris, el product manager es un miembro del equipo de producto, que es multidisciplinario, y responde sobre todo por dos cosas: el valor y la viabilidad de lo que el equipo crea. Valor quiere decir que los usuarios o clientes lo van a comprar o usar cuando tengan opción. Viabilidad, que funciona para el negocio. “No alcanza con satisfacer al cliente: hay que hacerlo de una forma que funcione para el negocio.”

¿Conviene un perfil de negocios o uno técnico? Chris contrató product managers muy buenos de los dos lados y prefiere armar un equipo con ambos. Lo que no negocia es que cada uno pueda moverse en el terreno del otro: alguien de negocios que no se intimide en una charla con un arquitecto de software, y alguien de ingeniería que pueda hablar de métricas financieras con el VP de Finanzas.

¿En qué se diferencia de un product owner o un scrum master?

El product owner y el scrum master son roles de un proceso ágil, y ese proceso se ocupa sobre todo del delivery: cómo cortar el trabajo, cómo priorizar el backlog, cómo ser más eficientes. Lo que esos modelos no cuentan es cómo se llega a un buen backlog. El product manager hace lo que haría un product owner, pero además se hace cargo del discovery: asegurarse de que lo que se construye sea valioso y viable.

Chris aclara que la confusión no es solo de Latinoamérica: en Estados Unidos también hay muchas empresas con un rol de producto que en la práctica es de gestión de proyectos. “Por eso SVPG tiene un negocio.”

¿Qué es el modelo operativo de producto?

Un modelo operativo es cómo se hace el trabajo en una empresa: qué roles hay, cómo se combinan y qué técnicas se usan. El modelo operativo de producto se entiende mejor por contraste con el modelo de proyectos, el de siempre: alguien arma un caso de negocio, se aprueba, se junta un equipo, se ejecuta y se lanza. Ese modelo se mide por lo que se entrega y en qué fecha, y según Chris falla muy seguido, por razones de estructura.

El modelo de producto mide el resultado. En lugar de “lanzá este onboarding”, el pedido es “hacé que el onboarding tarde la mitad y tenga menos errores”, y el equipo responde por cuánto resolvió el problema, no por haber entregado a tiempo. El nombre es nuevo, aclara Chris, pero la idea es la que SVPG recomienda desde hace mucho.

¿Qué cambia pasar de feature teams a equipos empoderados?

Es la diferencia entre recibir “construí esta solución” y recibir “resolvé este problema, con la solución que creas mejor”. El segundo pedido cambia el comportamiento de todo el equipo: los ingenieros no se ponen a construir de entrada, desconfían de la primera idea y buscan evidencia antes de invertir en ella.

Chris lo lleva a una queja clásica: “Nunca escuché a un product manager decir que habla demasiado con clientes.” Si lo único que te piden es entregar, hablar con clientes te frena. Si te miden por resolver el problema, hablar con ellos es la única forma de no equivocarte.

¿Cómo trabajan varios equipos empoderados sobre un mismo problema?

Los equipos no hacen lo que quieren. Los líderes les dan un contexto compartido, con una visión y una estrategia de producto, y reparten las áreas de cada equipo de forma que tenga sentido. Varios equipos, a veces 20, pueden compartir un mismo objetivo, y a escala eso es más común que un objetivo por equipo. Cómo se dividen las responsabilidades entre equipos, lo que se conoce como team topology, puede hacer que las dependencias sean mejores o peores.

¿Cómo se gana la confianza de los stakeholders?

Para un stakeholder de negocio, dejar de pedir funcionalidades y empezar a plantear problemas se siente como perder el control. Chris pone la responsabilidad del lado de producto: si el product manager no conoce a los clientes, los datos y el negocio mejor que el stakeholder, no tiene sentido que el stakeholder confíe en él. “Sería una tontería.” El trabajo es volverse digno de esa confianza.

¿Cuándo conviene empezar? Desde el principio, porque así es como sucede la innovación. Pero no funciona si los equipos no tienen el conocimiento para que se les confíen las decisiones.

¿De dónde sale el tiempo para hablar con clientes?

Chris da dos respuestas. La primera: ese es un lugar donde tu manager tiene que ayudarte, reacomodando trabajo o facilitando el acceso a clientes. La segunda: el discovery tiene que restarte trabajo. Si solo construís lo que tiene evidencia de que va a funcionar, construís menos, y dejás de dedicar tanto tiempo a acompañar entregas, que es importante pero no es el trabajo central de producto.

¿Cuáles son las tres dimensiones del modelo operativo de producto?

Chris define el modelo como un conjunto de principios, y aclara que no es un proceso ni un framework. Tiene tres dimensiones:

1. Cómo se construye. Dejar los lanzamientos grandes cada mes o cada trimestre y publicar al menos cada dos semanas, idealmente más seguido. Suele exigir cambios de arquitectura, automatización de pruebas y un pipeline de desarrollo nuevo. También medir todo lo que se publica y poder retirar, comparar o lanzar de a poco distintas versiones. Es sobre todo terreno de ingeniería, y muchas empresas se quedan acá creyendo que ya se transformaron.
2. Cómo se resuelven problemas. El paso de feature teams a equipos empoderados. Involucra a producto, diseño, datos e ingeniería.
3. Cómo se decide qué problemas resolver. Acá entran la visión y la estrategia de producto, y alcanza a toda la empresa: es la relación entre los stakeholders de negocio y la organización de producto.

Para esa tercera dimensión no hay receta. La estrategia sale de líderes que entienden a fondo el mercado, el producto y lo que se aprende en discovery. Chris cita a Steve Jobs: enfocarse no es decir que sí a lo importante, es decir que no a cientos de otras buenas ideas. Y agrega que a veces importa menos en qué te enfocás que el hecho de enfocarte.

¿Cómo cambia la IA el trabajo de producto?

Chris no cree que la IA cambie los principios del modelo, y tampoco que vaya a reemplazar a los equipos en la próxima década. Sí cree que va a darles mucha palanca a quienes hacen producto: para entender datos o incluso para proponer un primer borrador de estrategia. También observa que casi todas las startups de San Francisco trabajan con IA generativa, y que el modelo operativo se aplica igual a esos productos.

¿Qué puede hacer un product manager si su empresa no trabaja así?

El modelo no se instala solo desde abajo: necesita que se sumen muchas otras personas. Lo que sí está en manos de cada product manager es volverse lo más experto posible en los clientes, los datos y cómo funciona el negocio, y construir relación con los stakeholders: poder consultarles cosas y pedirles que te enseñen. Eso mejora tus decisiones y te da lugar en la mesa cuando llegue el cambio, que según Chris ya viene.