En casi cualquier equipo de producto el research se documenta bien. Alguien lo lee para escribir una PRD y ahí se queda. Nadie vuelve a abrir esa entrevista, ni ese proyecto con veinte usuarios del que salieron conclusiones buenísimas. Construir con IA en un equipo de producto empieza justo ahí: no se trata de pedirle resúmenes a un chat, sino de diseñar un sistema con reglas y proceso que convierta cada fuente en algo que se pueda consultar, actualizar y refutar. Es lo que Ignacio Alonso (Alons), Head of Product de Shakers, enseñó en la primera parada del AI Tour en Madrid: cómo su equipo pasa de entrevistas a insights con agentes de IA, y en qué punto sigue decidiendo una persona.
Un insight es un hallazgo basado en datos, con un porqué, con implicación de producto, refutable y no obvio. Cuatro agentes lo capturan, lo extraen, lo consultan y lo revisan cada mes, y una persona valida antes de que se escriba nada. Sin ese proceso alrededor, el research acaba en un cementerio de información.
¿Cómo se construye con IA en un equipo de producto?
Significa tratar cada sistema de agentes como un producto más. Tiene un problema que resolver, un input, un output y un flujo en medio, y la única diferencia con cualquier otro producto que ya tengas es que la interfaz es un chat.
El problema de partida en Shakers era sencillo de contar. Había más gente del equipo en contacto con talento, clientes y equipos internos, y todo eso dejaba feedback en muchos sitios. Una información aislada sirve para una cosa, y su valor real solo aparece cuando otra persona la usa para tomar una decisión, aunque nunca haya estado en esa reunión.
Y hay una regla que aplica a todo lo demás: cuanto más le expliques a la IA lo que tiene que hacer, mejor lo hará. Cuanto más vago seas, más va a variar lo que te devuelve. Por eso, antes de montar ningún agente, hay que definir con precisión qué queremos que salga.
¿Por qué empezar por el research?
Porque es donde más se nota el contexto disperso. Las entrevistas viven en un sitio, los proyectos de research en otro, el feedback suelto en Slack, las reseñas en la App Store, las encuestas de NPS en su herramienta y los informes de data en una newsletter mensual. Cada pieza tiene valor, pero ninguna habla con las demás.
El primer paso no es técnico: es llevar todo eso a un sitio ordenado, con el orden que puedas, antes de pensar en montar ningún agente. En Shakers empezaron con bases de datos en Notion: el research queda estructurado y dentro de cada ficha cabe todo el contenido que haga falta. Si tus notas están repartidas por carpetas y documentos sueltos, ese es el trabajo previo. Sin él, ningún agente va a saber dónde mirar.
¿Cuándo un hallazgo cuenta como insight?
El cambio de fondo es pasar de research a insights. El research es un documento cerrado, mientras que un insight es una entidad viva que se alimenta de todas las fuentes, se actualiza, puede quedarse desactualizada y puede refutarse.
Para que un agente los cree bien, primero hay que definir qué cuenta como insight. En Shakers tiene que cumplir cinco criterios:
- Basado en datos, cuantitativos o cualitativos.
- Con un porqué. "Si no sabes por qué pasa, no es un insight". Que las ventas han caído un 40% no es un insight. Que han caído por un error en el proceso de facturación, sí.
- Con implicación de producto. Ese error lleva a una acción: revisar y arreglar el flujo. Si las ventas han caído por un tornado, no hay nada que hacer desde producto, así que no entra.
- Refutable. Si dentro de un mes el error ya no está y las ventas se han recuperado, el insight pasa a estar refutado. Es lo que evita que las cosas se queden ahí para siempre.
- No obvio. Si cualquier persona de la empresa ya lo sabe, no es un insight.
Queda una pregunta que se hace todo el que lo monta: ¿de qué tamaño es un insight? Si son demasiado grandes, todo parece hablar de lo mismo. Si son demasiado pequeños, acabas con cientos de fichas con las que no haces nada. La regla en Shakers es que la acción que desencadena tiene que dar, como mínimo, para una feature nueva o para la iteración de una que ya existe. Si se resuelve con un cambio pequeño, se agrupa con otras cosas. Algo sobre un paso concreto del registro no es un insight. Algo sobre el flujo de registro en general, sí. Y como siempre con la IA: con ejemplos lo hace mucho mejor.
Cada insight tiene tres dimensiones que pueden cambiar con el tiempo: su contenido, su nivel de confianza y su validez.
¿Cómo decide un agente cuánto creerse una fuente?
No todas las fuentes pesan igual. "Una review en la App Store no pesa lo mismo que una entrevista de 45 minutos con un usuario de pago". Un hallazgo que sale de un proyecto de research, que alguien ha hecho con método y del que ha sacado conclusiones, vale más que un comentario que se ha compartido en Slack.
Ese criterio hay que convertirlo en reglas que el agente pueda aplicar. En el workshop la escala de niveles de evidencia quedó así:
| Nivel | Qué lo define | Ejemplos |
|---|---|---|
| 1. Anécdota | Comentario suelto o feedback de segunda mano | Un mensaje en Slack, alguien del equipo contando lo que dijo un usuario |
| 2. Patrón | Fuente directa o un mismo tema repetido | Entrevistas directas, el mismo problema en tres personas distintas, una consulta de datos reproducible |
| 3. Validado | Información curada, con método y síntesis | Un proyecto de research cerrado, comportamiento observado, un informe de data curado |
La confianza alta llega cuando hay dos cadenas de evidencia independientes en nivel 2 o superior: varias entrevistas que mencionan el mismo problema y un dato reproducible que lo confirma. Ojo con un riesgo que aparece enseguida, que es inflar la confianza contando dos veces la misma evidencia. Hacen falta reglas para detectar cuándo dos fuentes en realidad son una.
La validez, en cambio, responde sobre todo al tiempo:
- Necesita revisión: tres meses sin actualizarse, o cualquier indicio de contradicción.
- Outdated: seis meses sin que nadie lo toque. Puede seguir siendo cierto, pero no te lo creas tanto.
Cuando un insight necesita revisión, el agente propone qué investigar para ponerlo al día: una encuesta, una entrevista, un dato concreto. Esas propuestas se convierten en tareas para PMs y diseñadores, y quien consume la información sabe en todo momento si le están dando algo con baja confianza o algo que hace meses que nadie mira.
¿Qué agentes forman el sistema?
El sistema que usa el equipo de producto de Shakers tiene cuatro skills, cada una con un trabajo claro:
| Skill | Qué recibe | Qué hace | Qué escribe |
|---|---|---|---|
| Feedback Capture | Fuentes sueltas: Slack, reseñas de la app, encuestas de NPS | Una vez a la semana las recorre y las ordena | Una base de feedback dentro del research, y sugerencias de edición que llegan por Slack |
| Insight Extractor | Una o varias fuentes | Comprueba los 5 criterios, busca duplicados y propone crear, editar o refutar | La base de insights, siempre tras la confirmación de una persona |
| Insight Questions | Una pregunta de cualquiera del equipo | Responde con lo que dicen los insights | Nada: solo lee |
| Insights Report | El estado de la base cada mes | Revisa qué se va a desactualizar y obliga a reflexionar sobre la validez | Actualizaciones a través de Insight Extractor |
El flujo del Insight Extractor es el corazón del sistema. Entra una fuente. El agente comprueba si lo que ha detectado cumple los cinco criterios y, si falta evidencia, la pide o lo descarta. Después busca en la base para no crear duplicados ni insights que parecen decir lo mismo y no lo dicen. Si el insight ya existe, propone editarlo: el contenido, la evidencia o la validez. Si no existe, prepara un borrador. Antes de escribir nada en la base, una persona confirma, y solo entonces el insight se guarda en Notion y se avisa por Slack.
Con Feedback Capture hubo que ajustar sobre la marcha: ahora no crea insights nuevos a partir del feedback suelto, salvo que el mismo tema se repita en más de cinco feedbacks distintos. Lo normal es que solo proponga ediciones.
Y un aprendizaje de cuando el sistema creció: con varios agentes, a veces uno entendía que querías hacer otra cosa, y escribirles reglas sobre cuándo no tienen que actuar redujo mucho los errores. Parece una tontería. No lo es.
¿Dónde sigue decidiendo el PM?
"Para nosotros, la IA, de momento, solo propone". Nada se escribe en la base de insights sin que una persona lo confirme.
La razón es práctica. En una prueba rápida todo parece funcionar genial. Cuando ese insight lo vas a usar para justificar una decisión ante dirección, empiezas a dudar de verdad de lo que te dice la IA, y ahí es cuando hay que pararse a pensar. Alons lo enseñó con un caso real: le pasó a Claude varios informes de data y el agente sacó seis conclusiones. Aceptó unas y descartó otras, porque había leído esos informes y sabía lo que decían, y sin ese filtro la base se habría llenado de cosas que no eran verdad.
De ahí sale otra regla: solo el dueño de un research puede convertirlo en insights. Los matices viven en las transcripciones, en las llamadas, en lo que no está escrito. Cuando alguien toca un insight que creó otra persona, ese insight tiene su hilo en Slack y su dueño recibe un aviso: le han añadido evidencia, se lo han cambiado o se lo quieren refutar. Con varias personas trabajando sobre la misma base, estas dinámicas son las que más cuestan y, al mismo tiempo, las que hacen que el sistema sea útil de verdad.
El día a día del PM cambia de forma. "El 60% de mi jornada es esto: hablarle", cuenta Alons, que dicta por voz en lugar de escribir. El trabajo deja de ser redactar documentos y pasa a ser decidir qué entra en la base, qué se descarta y qué hace falta investigar a continuación.
¿Cómo se mantiene vivo el sistema?
"Si no creas procesos alrededor de los agentes, se quedan en un cementerio de información". Da igual cuántos agentes montes.
En Shakers, ese proceso tiene tres piezas:
- Un informe mensual. El Insights Report obliga a revisar qué ha pasado ese mes, qué está a punto de desactualizarse y si hay algo que el sistema todavía no sabe.
- Tareas programadas, con dueño. Feedback Capture corre una vez a la semana y manda sus sugerencias por Slack a quien tiene que decidir. El riesgo de automatizar mucho es que las cosas empiecen a pasar en silencio y nadie les haga caso.
- Una conversación de mejoras siempre abierta. Cada vez que algo no funciona, se anota ahí y se itera. Lo que se detecta y no se resuelve queda como pendiente, en lugar de olvidarse.
Sobre cómo se mejoran las skills, el equipo lo tiene claro: las escribe la IA, nunca a mano. Hace seis meses las escribían ellos, convencidos de que una skill bien redactada sería la leche, y nunca salía tan bien como la que escribe la IA con skill creator. Y cuando la skill ya existe, basta con decirle qué cambiar: propone los cambios y tú los confirmas.
Cuando el sistema lo usa más de una persona, el listón sube. "Lo van a usar cinco personas de cinco formas diferentes y vas a encontrar cinco fugas". Si algo se va a compartir, hay que ser exigente con cómo se usa y con quién puede editarlo. Claude permite compartir una skill para que otros la usen sin poder editarla. Una regla dentro de la propia skill ("solo el dueño puede cambiarme") ayuda, pero cualquiera puede saltársela. La protección de verdad llega cuando todo vive en un repositorio: quien puede publicar en la rama principal decide qué cambia para todos.
¿Y después de los insights?
Los insights no son el final. Son la primera pieza de cómo construye producto un equipo con IA.
Antes de escribir una PRD, el primer bloque es explicar por qué haces algo y qué esperas que pase. Ese bloque consulta la base de insights y te dice qué problemas detectados resolvería lo que propones, sin tener que reconstruirlo cada vez. A partir de ahí, una skill de specs se alimenta de esos insights para preparar la especificación que necesita diseño.
Diseño y desarrollo trabajan en el meta-repo de Shakers: un sistema de carpetas donde cada agente tiene sus instrucciones, el contexto que necesita y una rama por cada feature. Cuando alguien de diseño empieza a prototipar, el agente le pregunta en qué PRD se basa y sabe qué buscar en ella. Y antes de construir nada, todos los agentes pasan por una skill de preguntas, el grill me, para que quien está al mando entienda bien lo que se va a hacer. Así personas que no habrían hecho algo de esa manera aprenden por el camino.
Hoy es un híbrido: diseño y desarrollo ya viven en git, mientras que el trabajo de los PMs y la analítica todavía no ha dado el salto. La cuenta, con sus dos lados, es esta:
- ¿Por qué empezar en Notion? Porque mucha gente del negocio vive ahí, porque es más fácil para quien no sabe git y porque fue la forma de arrancar rápido.
- ¿Por qué migrarlo? Porque la integración con Notion consume muchos tokens y porque en un repositorio el control de cambios es real.
La dirección es que todo viva en git y Notion quede para compartir hacia fuera. Toda esa estructura, del meta-repo a cuánta autonomía se gana cada agente, es la que el equipo ha documentado en el AI Builders Playbook.
Errores al empezar a construir con IA en producto
- Empezar con el research desordenado. Si ni tú sabes dónde está cada cosa, el agente tampoco.
- Meterlo todo en un único proyecto. Separar el trabajo en skills hace que cada pieza se pueda mejorar sin tocar el resto.
- No definir qué es un insight. Sin criterios ni ejemplos, cada ejecución te devuelve algo distinto.
- No decirle al agente cuándo no actuar. Con varios agentes, se pisan.
- Escribir las skills a mano. La IA las escribe mejor, y luego las actualiza ella misma.
- Convertir en insights el research de otra persona. Sin el contexto de quien lo hizo, lo vas a hacer mal.
- Creer que ya está. "La primera vez te vas a creer que has construido una cosa infalible". Los problemas aparecen cuando lo usas en serio.
- Automatizar sin dueño. Lo que corre solo y nadie revisa acaba ignorado.
Preguntas frecuentes sobre el sistema de insights
- ¿Hace falta saber programar para montar un sistema de insights con agentes?
-
No. El sistema de Shakers empezó en Notion precisamente porque no hacía falta saber git. Lo que sí hace falta es tener el research ordenado y definir bien las reglas.
- ¿Qué modelo de IA conviene usar?
-
La recomendación de Alons es usar el más avanzado que tengas disponible y cambiar según los resultados. Si algo no sale bien, antes de pensar que lo estás haciendo mal, prueba con un modelo mejor.
- ¿Cómo se evita que cualquiera cambie una skill compartida?
-
Compartiéndola con permisos de uso y no de edición. Para un control real, llevando las skills a un repositorio, donde los permisos de publicación en la rama principal deciden qué cambia para todos.
- ¿Y si el consumo de tokens se dispara?
-
Díselo al agente mientras lo construyes: que tu límite es el coste y quieres optimizarlo. Te propondrá alternativas, incluido montar flujos en herramientas como n8n.
- ¿Se puede automatizar del todo?
-
Se puede con tareas programadas que llamen a las skills: por ejemplo, revisar cada semana los research completados que todavía no se han procesado y avisarte de qué tienes que actualizar. Pero lo que corre en silencio tiende a ignorarse. Por eso en Shakers el paso clave no fue automatizar más, sino asegurarse de que el proceso se usa.
El research es la primera pieza, no el sistema entero
Lo que se vio en Madrid es una parte de cómo trabaja el equipo de producto de Shakers con agentes de IA. Todo el sistema está en el AI Builders Playbook: el meta-repo donde vive el contexto de producto, la rúbrica que decide cuánta autonomía gana un agente y cuándo la pierde, los 8 errores que cometimos gobernando agentes y las plantillas de AGENTS.md y repos.yml. En palabras de Alons: "es literalmente lo que hemos estado haciendo desde hace un año". Está en inglés y pensado para CTOs y Heads of Engineering, así que si quieres llevar algo parecido a tu equipo, es un buen documento para compartir con tu CTO, sobre todo si ya os habéis preguntado qué equipo necesita una empresa para IA. Descarga el AI Builders Playbook.
La próxima parada del AI Tour es en Valencia el 19 de noviembre, con Belén Beneyto, Product Design Manager de Shakers, sobre diseño con IA: de Figma a código. La programación del tour y la inscripción de cada parada, en la página de eventos de Shakers.
