La gestión de producto consiste, en esencia, en contar historias. Así que permíteme compartir cómo yo pienso sobre la gestión de producto y cómo la IA ha cambiado esto, contándote una historia.
La pregunta de entrevista que nunca olvidaré
Comencé mi carrera como ingeniero en RealNetworks, y en pocos años fui responsable del equipo de producto e ingeniería de RealPlayer. Era un producto de consumo bastante significativo en ese momento: tenía cientos de millones de usuarios y ayudó a llevar el audio y el video a los inicios de internet. Me sentaba en reuniones con personas del lado comercial, quienes sugerían ideas como: "Deberíamos mostrar un anuncio cada vez que se inicie el reproductor". Sabía que no era lo correcto, pero no tenía forma de argumentar contra sus hojas de cálculo de Excel que mostraban cuánto dinero ganaríamos. Quería convertirme en un gestor de productos de verdad, y concluí que probablemente debería ir a una escuela de negocios.
Empecé mis estudios en Berkeley, y poco después de llegar vi en mi lista de correo electrónico de la universidad anterior que LinkedIn estaba contratando. Apliqué y me encontré en una entrevista con Reid Hoffman. Se sentó y me hizo una pregunta de entrevista que nunca olvidaré:
"Entonces, quieres ser gestor de productos. ¿Cuál es el artefacto que produce un gestor de productos?"
Él elaboró. Los ingenieros tienen un artefacto: código. El desarrollo de negocio tiene un artefacto: contratos firmados. Los diseñadores crean la apariencia visual y los gráficos. El CEO tiene el organigrama, el plan de financiación y la visión que mantiene unido a todo el mundo. ¿Y qué hay del gestor de productos?
Le dije que no estaba seguro de que los gestores de productos tuvieran realmente "artefactos" así, pero que lo fundamental que hacemos es recopilar todo lo que está ocurriendo y escribirlo en una especificación. La especificación es el plano. Es donde definimos los requisitos y todo lo que vamos a hacer, y se convierte en uno de los documentos más importantes de la empresa porque desbloquea a todos los equipos para construir desde ahí.
Estaba claramente nervioso. Creo que él lo notó, porque me aseguró que era una buena respuesta. Terminé consiguiendo el trabajo, dejé la escuela de negocios para unirme a LinkedIn, y he estado pensando en esa pregunta desde entonces.
La evolución de la especificación a la historia
Porque di la respuesta equivocada.
Esto todavía era la Era del Modelo Cascada (Waterfall) para construir software. En LinkedIn intentábamos reinventar una plataforma de empleo dentro de una plataforma social: donde los responsables de contratación podían ver las solicitudes de empleo en el contexto de contactos mutuos, y los candidatos podían ver ofertas de trabajo y encontrar formas a través de su red para llegar a la puerta principal. Durante este proceso de descubrimiento, escribí una especificación de 120 páginas definiendo toda la experiencia y cuáles eran los requisitos.
He pensado mucho en ello en los años posteriores. Porque esa especificación, obviamente, no es el artefacto más importante. La historia sí lo es.
La especificación describe un sistema, lo que debe hacer y qué casillas deben marcarse antes de que esté terminado. Esa no es el arte de la gestión de producto. La gestión de producto trata de contar la historia de las personas que van a usar el producto y por qué importará en sus vidas. Debe ser inmediatamente comprensible, para quien sea que estés hablando. Y debe ser repetible: la gente necesita poder pasarla fielmente, sin que tú estés en la sala.
Ese es un documento completamente diferente, y un trabajo completamente diferente.
Hace diez años di una charla sobre gestión de producto, y la gente todavía me la envía; lo cual es halagador o una señal de que el campo no ha avanzado. Consideraré ambas posibilidades. De todos modos, toda la charla se reducía a una frase: "Un gestor de productos ayuda a su equipo (y a su empresa) a lanzar el producto adecuado a sus usuarios." Pasé la mayor parte de la charla desglosando esa frase, palabra por palabra.
- Ayuda a su equipo. No eres el líder. Mucha gente piensa que el gestor de productos es el líder. Eres la persona que ayuda a que las cosas sucedan. Lo que significa que debes...
- Entender a tu equipo y a tu empresa. Tu equipo es tu dominio: ¡tienes que entenderlo! Y tienes que entender cómo encaja en el panorama general, para poder servir a los objetivos de la empresa y no solo a los tuyos.
- Lanzar. Podemos hablar todo lo que queramos, pero al final del día, lo único que importa es poner el producto frente a los clientes.
- El producto adecuado para tus usuarios. Finalmente hemos llegado al trabajo: afinar qué significa realmente "adecuado".
¿Cuánto cambia eso en un mundo de IA?
Lo que está cambiando
Obviamente algo ha cambiado, varias cosas en realidad. Por un lado, está cambiando cómo codificamos y qué tan rápido podemos pasar de una idea a algo funcional. Por otro lado, está cambiando lo que los usuarios esperan que un producto sea. Creo que apenas hemos rascado la superficie, especialmente en el consumo. Poder describir lo que necesitas y que el producto lo entregue, quizás con agentes ejecutándose en segundo plano, sin que tengas que aprender ni interactuar manualmente.
No hay duda de que el costo de hacer cosas se ha desplomado. Ya no es tan difícil definir el alcance de algo y probarlo; eso te da una flexibilidad enorme. Pero el costo del juicio no ha cambiado en absoluto. Descubrir qué construir es ahora más importante que nunca.
El desarrollo de producto es un ciclo. Solía ser que alguien tenía una idea -y no tiene que ser necesariamente tuya; en una buena empresa puede venir de cualquier lugar-. La pruebas. Escribes una especificación, o un resumen de producto, o como llames a ese documento. Hay un costo inicial asociado: definición del alcance, diseño, debates -todo lo que debe ocurrir antes de gastar tiempo precioso de ingeniería-. Estos son rituales que inventamos para proteger el tiempo de ingeniería de malas decisiones. Porque solo tenías seis u ocho vueltas alrededor de ese ciclo al año.
Luego, hacer cosas se volvió absurdamente barato. No algo más barato; un orden de magnitud diferente. Y lo que ha ocurrido es realmente interesante. Ese viejo ciclo sigue muy presente -solo reorganizado en un nuevo orden-.
El viejo ciclo iba así: idea, especificación, costos, alcance, todo lo demás, y luego construcción. Ahora:
- Primero, toma la idea y constrúyela rápidamente con IA, solo para ver cómo funciona y cómo se siente.
- Juegas con ella y descubres cómo se siente y cómo encaja en el panorama general. Los prototipos ganan a los "qué pasaría si", siempre.
- Entonces la diseñas. Ahora que has jugado con ella, sabes qué es, y puedes hablar realmente de lo que se necesitará para que esto sea más que un prototipo. Me refiero al diseño aquí en ambos sentidos: diseño visual y de UX, y también diseño de ingeniería.
- Luego lanzas y aprendes.
Se invierte completamente: de especificar-y-definir-alcance, a construir-y-jugar. Creo que eso cambia la gestión de producto más que cualquier otra cosa que esté ocurriendo ahora mismo.
Esto finalmente significa que la especificación ya no es el entregable; de verdad. No tienes que empezar escribiendo un documento largo y acertándolo todo en papel. Esto solía ser cierto en un sentido aspiracional, pero ahora es simplemente obvio, en un sentido literal.
Pero quiero tener cuidado, porque hay un error igual y opuesto que puedes cometer.
Las demos son casi gratuitas ahora. Los productos funcionales no lo son. Sigo viendo el reverso de este nuevo enfoque: "Genial, solo lánzalo". Eso todavía no es cómo funciona. Todos seguimos teniendo que respetar que la distancia de un prototipo a algo real aún requiere tiempo para recorrerse.
Hay un cliché sobre los gestores de productos, que su trabajo consiste principalmente en preguntar: "¿Encaja en el cronograma?". Desecha esa idea por completo. La pregunta más importante es: ¿Encaja en el producto?
Todos tenemos grandes ideas, y ahora todos tenemos agentes que pueden programar por nosotros. Decidir qué construir ya no es oficialmente un debate de recursos. Es un debate de impacto. "Esto o aquello", no "esto o nada". El gusto y la curación importan mucho aquí, cuando tienes una visión y sabes realmente qué estás tratando de hacer por el mundo. Pero el sistema que construyas aún tiene que sentirse completo.
Mi mayor preocupación sobre la IA es que nos permite ir más rápido y, por lo tanto, meterlo todo. Hablamos de "basura de IA" (AI slop) en contenido; esto es lo que significa la basura de IA para el producto. Lo he visto ocurrir en algunos lugares ya, y creo que todos estamos un poco preocupados por ello. Cuando cualquiera puede construir cualquier cosa, decidir qué construir es todo el trabajo. Y eso es un problema de narrativa. ¿Qué historia quieres contar? ¿Qué historia quieres que entiendan tus clientes? ¿Qué historia quieres que viva en sus cabezas?
Tu trabajo como PM no es escribir una especificación de lo que hará el producto. Se trata de crear una comprensión compartida -una imagen compartida de qué estamos haciendo y por qué-. ¿Por qué está el usuario aquí? ¿Qué sienten en cada paso y por qué importa eso? ¿Dónde es impresionante y dónde es aburrido? Está bien que un producto sea aburrido ocasionalmente, siempre y cuando sepas dónde. Pero si no puedes escribir un buen guion, el producto será tedioso.
El regalo que te da la IA es que ahora puedes averiguar esto gratis, desde el principio. Puedes construirlo rápidamente, hacerte una idea, jugar con él y descubrir esa única frase: ¿qué hace este producto por alguien en su vida? Porque si puedes responder eso, puedes responder a mi pregunta: "¿La gente realmente lo está usando?". Porque ahora has dicho qué hace, y estás preguntando si ellos lo hacen.
Lo que no está cambiando
¿Qué significa tener una "visión" para tu producto?
Cuando digo visión, no me refiero a una declaración de misión. Esas importan, pero no son una visión. Una visión es la razón de fin a fin para que el producto exista para los usuarios. Tengo un marco simple para esto:
- Propósito. ¿Por qué alguien recoge tu producto y lo pone en su vida?
- Acciones principales. Cuando lo recogen, ¿qué están haciendo realmente? Puede haber más de una cosa, tienes que entenderlas todas.
- Ciclo. ¿Cuál es la frecuencia esperada de cada una de esas acciones principales?
Durante toda mi carrera, mientras me reunía con fundadores y otros profesionales de producto, les pregunto: ¿está la gente usando tu producto? Y casi siempre saltan directamente a los datos de usuarios. "Tenemos una relación DAU/MAU del 50%. Cruzamos los 10,000 registros. Tenemos un millón de personas en la lista de espera. Nuestro ARR es de un millón. Estamos procesando cuatro mil millones de tokens al día. Llegamos al puesto #3 en la App Store."
¿Alguno de esos es una respuesta a la pregunta que hice?
A veces hago la pregunta de nuevo, pero agrego una palabra más: ¿está la gente realmente usando tu producto? Y entonces, a veces, captan lo que estoy preguntando.
El propósito de LinkedIn era encontrar y ser encontrado. Quizás la acción principal, para algunas personas, era simplemente responder cuando alguien se ponía en contacto. Para la mayoría de las personas, eso no es algo diario; podría ser una o dos veces al año.
Mira ese ciclo -una o dos veces al año-. Entender esto fue crítico para que LinkedIn funcionara, porque la red necesitaba un número muy grande de personas dispuestas a ser encontradas, y al menos algunas personas haciendo el hallazgo.
LinkedIn era una red social, después de todo, así que podrías sentirte tentado a empujar a los usuarios a tomar acciones todos los días. No hicimos eso. En cambio, pasamos un tiempo enorme en los primeros días asegurándonos de que las personas mantuvieran sus perfiles precisos. Estaba perfectamente bien si solo eras encontrado una o dos veces al año, siempre y cuando cuando ocurriera, hicieras clic y entendieras: "alguien se está poniendo en contacto conmigo, eso es genial".
Cuando mides si tu producto está funcionando, esas acciones principales son lo que importa. Enfócate en el tráfico directo: encuentra a las personas que literalmente vinieron a ti. Tienen la aplicación instalada y tocan el icono, o escribieron tu dominio a mano; fueron hacia ti, por su propia voluntad. Ese es el tráfico que importa, a diferencia de todas las otras formas en que puedes conseguir que alguien regrese en el momento.
Y luego cuenta realmente solo a las personas que realizan las acciones principales. No "abrieron brevemente la aplicación", sino que realmente interactuaron con ella. En Discord sería: "entró en una sesión en vivo. Leyó y envió mensajes realmente".
Si no puedes definir cuáles son esas acciones principales, entonces no tienes un producto, porque no tienes algo que entiendas.
Ahora, una cosa que es nueva, y que me encanta, es que en los productos de IA donde el usuario habla con el producto, o le da instrucciones de alguna manera, ahora tienes una transcripción literal de tu recorrido de usuario. Puedes ver lo que la gente dice con sus propias palabras. Puedes ver el momento exacto en que alguien se rindió y reformuló. Puedes ver qué esperaban que hiciera el producto y no hizo. ¡LEE ESTOS! La IA es genial para sacar a la luz cosas que no habrías visto antes, pero no puedes dejar que resuma todo, y no puedes dejar que forme tu opinión por ti. Formar tu opinión -descubrir cuál es la historia realmente- es el trabajo y el arte de la gestión de producto.
Onboarding
El onboarding es el momento más importante que tienes para contar tu historia a un cliente. Han descubierto tu producto -quizás a través de un anuncio, una invitación viral, un artículo, lo que sea-. Saben que existes; tienen curiosidad y quieren probarlo. Nunca obtendrás tanta atención de ellos jamás.
Tienes que recordar, en este punto, que no todos llegan a tu producto con la misma motivación. Están los entusiastas. Quieren entrar con muchas ganas. Están listos para ir. Y, para que quede claro, si trabajas en la empresa, vives en el país de los entusiastas. A todos los internos de tu empresa se les debe tratar como entusiastas; ya están inmersos en el producto todos los días. Cuando se incorporan al producto piensan: "Sé lo que estoy haciendo, esto es aburrido, ¿por qué está este paso aquí?".
Por otro lado, están los pasajeros. Simplemente no están tan interesados en ti. Oyeron hablar de ello, lo revisaron, pero el mensaje no caló, y van a abandonar.
Esos dos tipos de usuarios son los extremos de la distribución. En medio hay un gran centro difuso. Estas son personas que llegaron por una razón: ¡tienen curiosidad! ¡Quieren saber más! Y genuinamente puedes convertirlos en usuarios centrales de tu producto. Estas son las personas alrededor de las cuales necesitas construir. Obtendrás a los entusiastas de todos modos. El centro es quien necesitas entender.
Supón que tus usuarios están motivados y son curiosos. Toma el tiempo para presentar el producto, paso a paso. Más pasos simples vencen a menos pasos complejos. He demostrado esto en pruebas A/B en múltiples empresas durante los años. Si cada paso es discreto y simple, y está claro qué estás pidiendo y qué estás enseñando, eso vence a pantallas grandes únicas, o opciones complejas para mantener bajo el número de pasos. Siempre.
Entonces, ¿cómo construyes eso realmente?
Empieza repitiendo el mensaje central: Aquí está para qué sirve esto. Declara el contexto, dentro del producto. Está bien pedir lo básico -correo electrónico, contraseña, teléfono-. Para todo lo demás, explica por qué lo estás pidiendo y cómo se relaciona. Luego divide tu producto en sus conceptos clave, cada uno con una acción clara para que el usuario tome.
Los productos de IA han hecho esto más difícil, no más fácil. Obtienes la caja de prompt en blanco. En algunos sentidos, es la peor pantalla de onboarding jamás diseñada. Es una caja mágica. Puede hacer cualquier cosa. Entonces... ¿qué quieres hacer?
Muchos productos hoy en día empiezan con: "Hola, estoy aquí para ayudar, pregúntame lo que quieras". Hablando por mí mismo, no soy la persona más articulada o creativa en ese momento. Tienes que enseñar capacidades concepto por concepto. "Si preguntas algo como esto, puedo hacerlo". Y luego deja que el producto lo haga. Lleva al usuario al menos a un caso de uso valioso rápidamente, idealmente con sus propios datos, para que sea realmente valioso para ellos.
La gente me pregunta a veces: con un flujo más largo, ¿no abandonarán más personas? ¡Sí! Pero aquellos que terminan son mucho, mucho más propensos a usar realmente tu producto. Si estás probando A/B dos flujos de onboarding diferentes, NO mires cuántas personas llegaron al final del flujo. Mira cuántas personas regresan al día siguiente, o la semana siguiente, y cuántas realizaron una acción principal. Si les preguntas, en ese momento, "¿Qué es este producto?", deberían darte más o menos la respuesta correcta. Tus datos de retención, a partir de este punto, son tu boletín de calificaciones.
Una historia de Twitter
Voy a unir todo esto contándote una historia de Twitter.
Me uní a Twitter a finales de 2009. Teníamos un problema de crecimiento -excepto que no era realmente un problema de crecimiento-. Twitter estaba constantemente en las noticias. La gente escribía blogs sobre ello, los medios hablaban de ello, y muchas personas preguntaban: "¿Qué es esta cosa de Twitter? Necesito averiguarlo y registrarme". Y luego millones de ellos lo hicieron. Pero nunca volvieron.
El problema era que nadie podía decirte qué era Twitter. Puedo demostrar esto:
Leyenda: "eventualmente llegamos al número uno".
La forma en que hacíamos el onboarding era que las personas se registraban y veían opciones para "Encuentra a tus amigos" o "Sigue a 20 personas aleatorias". La mayoría se saltaba esto, y luego aterrizaban en una página que se veía así:
¡Esto es bastante terrible! Es una gran caja vacía. Las personas miraban y pensaban: "...No tengo nada que decir". Y luego se iban. Si les preguntabas en ese momento, "¿Qué es Twitter?", dirían: "Creo que se trata de decirle algo al mundo. ¿O encontrar a mis amigos? No sé".
Así que reconstruimos el onboarding durante un par de años, y encontramos lo que funcionaba, que era el Flujo de Aprendizaje (Learn Flow). Les enseñamos Twitter, un concepto a la vez, como una historia. Y movió la retención más que cualquier otra cosa que lanzamos ese año.
El Learn Flow, pantalla por pantalla
Primero, la nueva página de inicio: "Bienvenido a Twitter". No intentamos poner contenido allí, solo: "Descubre qué está pasando ahora con las personas y organizaciones que te importan". Esa es una descripción bastante buena de Twitter, honestamente.
Luego: Este es un tweet. Es un mensaje corto, hasta 140 caracteres, y puede contener enlaces. Ahora sabes que los tweets son la unidad de esta cosa.
A continuación tienes que construir tu línea de tiempo. Así que te mostramos una línea de tiempo. Te hicimos hacer clic en "seguir" a personas en la izquierda. Y cuando hacen clic en seguir, sus tweets aparecían a la derecha. Así que obtienes toda la idea, en un movimiento: Hago clic en seguir, aparecen tweets, esa es mi línea de tiempo. Que es el concepto real de Twitter -tweets, seguimiento y una línea de tiempo-.
Y luego, finalmente, tu línea de tiempo. Reconocerías cada cuenta en ella, porque tú mismo las habías seguido realmente.
El onboarding es tu historia.
El producto adecuado para tus usuarios
Tu trabajo como gestor de productos es ayudar a tu equipo y a tu empresa a lanzar el producto adecuado a tus usuarios. En un mundo de IA, el lanzamiento es menos problema de lo que solía ser. Descubrir el producto adecuado, y quiénes son tus usuarios, es tan importante como siempre. Si no más.
Pregunta siempre si la gente está realmente usando tu producto. Entiende qué significa eso. Piensa en el propósito, las acciones principales, el ciclo. Dedica más tiempo al onboarding de lo que parece razonable. Es donde conviertes al centro difuso, y es donde realmente cuentas la historia de tu producto.
Usa la IA para ir más rápido en los prototipos —pero no aceleres tu juicio—. No renuncies a tu juicio. No digas simplemente: "Bueno, probémoslo y veamos". Así es como terminas con un producto descuidado. Mantén tu juicio en todas partes. La parte más difícil del trabajo sigue siendo equilibrar toda nuestra creatividad como gestores de productos contra todos los datos a los que ahora tenemos acceso.
¡Buena suerte!
