La gestión de productos no se trata de construir más. Se trata de resolver lo que importa.

Por qué el producto comienza con escuchar

Conversación con Jonathan Coll

Gerente Principal de Producto 

Una conversación con Jonathan cambió mi forma de pensar sobre el producto. Jonathan es Gerente de Producto en Avalo, ayudando a dar forma a la plataforma Ionfi by Avalo. Desde afuera, el producto puede parecer decidir qué construir y entregarle a ingeniería una lista de requisitos. Desde adentro, es algo más silencioso y más difícil: asegurarse de que lo que construimos realmente esté resolviendo el problema correcto, por la razón correcta. 

Cuando le pedí que describiera el trabajo en términos sencillos, su respuesta me sorprendió. 

"Yo diría que es 75% escuchar y 25% construir", me dijo. "Mi rol es darle a diseño e ingeniería suficiente contexto para que resuelvan el problema por sí mismos." 

Ese contexto viene de todas partes: clientes, soporte al cliente, operaciones, cumplimiento y tecnología. Cada uno ve una parte diferente del panorama. El trabajo de producto no es decidir qué solicitud gana. Es encontrar los patrones, entender el impacto en el negocio y asegurarse de que todo el equipo esté resolviendo el mismo problema por la misma razón. 

"Mi trabajo no es construirte una funcionalidad", dijo Jonathan. "Mi trabajo es resolver tu problema." 

A veces eso significa hacer una pregunta más. Un cliente podría decir: simplemente pon ese widget justo ahí. En lugar de decir que sí de inmediato, Jonathan pregunta por qué. 

"Cuando un cliente me trae una idea de funcionalidad, trato de profundizar un poco más en lo que realmente está tratando de resolver", explicó. "A veces lo que nos piden construir no es la mejor solución, o hay una manera más fácil de resolver el problema." 

Debajo de la solicitud suele haber un objetivo más grande: un flujo de trabajo más fluido, mayor adopción o una mejor experiencia para el cliente. Entender ese objetivo es lo que permite al equipo construir algo útil, en lugar de simplemente agregar otra funcionalidad. 

Una historia se me quedó grabada. Los clientes estaban creando transferencias, adjuntando documentos de respaldo a un perfil y luego enviando la transacción para aprobación. Desde la perspectiva del cliente, los documentos ya estaban en la plataforma. Pero los archivos relevantes podían estar entre docenas de documentos en el perfil, creando una solicitud de seguimiento evitable por algo que el cliente creía que ya había proporcionado. 

Jonathan escuchó versiones del mismo problema de varios clientes. 

"Esto surgió unas cinco veces cuando entrevisté a diferentes clientes", dijo. 

En lugar de tratar cada instancia como una solicitud única, el equipo identificó la brecha subyacente. Esa percepción se convirtió en la base de una funcionalidad que permite a los clientes adjuntar los documentos de perfil relevantes directamente a una transferencia. El contexto puede viajar con la transacción, ayudando a reducir el ida y vuelta y respaldando una revisión más rápida. 

"La mayoría de los proyectos grandes en realidad se tratan de conectar los puntos", explicó Jonathan. "Uno mira las cosas recurrentes que siguen surgiendo. Eso es lo que nos ayuda a decidir qué priorizar." 

Dos cosas se me quedaron de nuestra conversación. 

Primero, producto es donde convergen diferentes perspectivas. Soporte al cliente escucha la voz del cliente de primera mano. Cumplimiento y operaciones entienden lo que se necesita para hacer avanzar una transacción. Ingeniería sabe qué se puede construir y cómo construirlo a escala. Diseño hace que la experiencia sea intuitiva. Jonathan ayuda a esos equipos a compartir un lenguaje común y alinearse en torno al mismo resultado. 

"Cumplimiento e ingeniería no siempre hablan el mismo idioma", explicó. 

Parte de su trabajo es asegurarse de que el requisito, la razón detrás de él y el resultado previsto sean entendidos por todos. 

Segundo, el progreso no tiene que significar disrupción. A medida que continuamos mejorando la plataforma, Jonathan se enfoca en proteger los flujos de trabajo en los que los clientes ya confían mientras deja clara el valor de cada cambio. 

"Si simplemente migramos a las personas y no explicamos los beneficios, preguntarán: ¿por qué estoy cambiando siquiera?", dijo. "Tenemos que mostrarles: esto es lo que nos dijiste que era difícil, y así es como lo resolvimos para ti." 

Ayudar a los clientes a reconocer su propia retroalimentación en el producto, dije. Él estuvo de acuerdo — eso es exactamente. 

El buen liderazgo de producto, según él, no se trata de lanzar la mayor cantidad de funcionalidades o perseguir la idea más nueva. Se trata de hacer mejores preguntas, escuchar más allá de las fronteras y ayudar al equipo a enfocar su tiempo y energía en lo que más importa. 

Jonathan describió producto como un rol de "aprendiz de todo". Esa amplitud puede ser su fortaleza oculta. Su trabajo no es reemplazar a los especialistas de cada función. Es entender lo suficiente de cada perspectiva para conectarlas, ganarse la confianza con el tiempo y mantener a todos avanzando en la misma dirección. 

Los buenos productos rara vez son el resultado de un único avance. Más a menudo, crecen de docenas de pequeños momentos en los que alguien escucha con atención, detecta un patrón y convierte una frustración recurrente en una mejor forma de trabajar. 

Jonathan ayuda a que eso suceda — con reflexión, colaboración y un problema a la vez.