Hace unas semanas hablamos sobre por qué todo PM necesita una cuenta de GitHub. La respuesta inmediata fue: "OK, pero ¿qué hago exactamente una vez que la tengo?"
Este playbook responde eso con tres escenarios: desde un fix de 20 minutos hasta liderar una feature completa, con un framework claro sobre qué construir, cómo hacerlo y qué nunca saltarse.
Pero primero, dos verdades incómodas.
La era del "no soy técnico" terminó
La brecha entre PMs que pueden construir y PMs que solo pueden llegar hasta una especificación se está convirtiendo en una brecha grande de trayectorias profesionales y skills.
La IA colapsó la curva de aprendizaje, y esto no se trata de convertirse en desarrollador. Se trata de cerrar la distancia entre tus ideas y software funcionando, lo suficientemente rápido como para dejar de depender del bandwidth de otros para validar tu pensamiento.
Necesitás ser lo suficientemente peligroso para prototipar, para arreglar, para mostrar en lugar de contar. Ese es el nuevo baseline: ponete técnico ya.
La IA construye rápido, y expone tu taste
La parte más difícil del producto nunca fue construir. Es decidir. La IA construye rápido, pero no puede decidir qué construir ni por qué... todavía. Ejecuta con una confianza aterradora: dale una idea a medio formar y te va a devolver una versión pulida de algo incorrecto.
Por eso el discovery sigue importando: entender el problema tan profundamente que la solución se vuelva obvia. Ganar convicción más rápido, antes de empezar a construir.
La IA puede acelerar partes de este trabajo, pero no puede reemplazarlo. El discovery es tuyo, el juicio es tuyo, y el juicio tiene un nombre: taste.
Taste es escuchar "necesitamos un dashboard" y entregar un solo número. Taste es matar la feature que testeó bien porque ensucia la experiencia. Taste es elegir la solución aburrida que sale el lunes sobre la ingeniosa que no sale nunca.
La IA amplifica tu taste, o expone tu falta de él.
El discovery está más vivo que nunca
Cada caso en este playbook arranca con las mismas cuatro preguntas. Saltealas y la IA va a construir felizmente algo incorrecto en tiempo récord (y ni siquiera completo).
¿Qué problema estoy resolviendo? No el feature request, la oportunidad subyacente de mejorar, validada, no asumida.
¿Cómo se ve "terminado"? El cambio de comportamiento, la métrica que se mueve. Si no podés articularlo, no estás listo.
¿Cuál es la versión más chica que puedo testear? La versión que responde tu pregunta más riesgosa más rápido.
¿Con quién tengo que validar antes de shippear? Eng, design, legal, tu manager, saltealos ahora, quedate bloqueado después.
Esto es design thinking, comprimido. Podés correr todo este proceso con 021, desde el problema hasta el scope de qué construir, antes de empezar a vibe codear. Es la capa de metodología que hace que todo lo demás en este playbook funcione.
El Playbook: Los Tres Casos
Se construyen uno sobre otro: el Caso 1 te enseña el workflow y te gana credibilidad, el Caso 2 te permite validar ideas sin esperar a nadie, el Caso 3 cambia cómo shippea tu equipo.
No te adelantes, cada caso construye skills y confianza que vas a necesitar para el siguiente.
CASO 1: El Quick Fix | "Shippealo vos en lugar de esperar 2 sprints"
Hay algo chico trabado en el backlog: un label de botón que confunde usuarios, un link roto en el onboarding, un cambio de copy que legal aprobó hace tres semanas y nadie tuvo tiempo de implementar.
Podrías escribir otro mensaje en Slack preguntando cuándo va a ser priorizado, o podrías arreglarlo vos.
Por qué importa
Tu primer fix va a tomar dos a tres horas, incluyendo setup y tropezarte con comandos de Git que nunca usaste. Te vas a sentir perdido en el codebase, pero para tu quinto fix, vas a hacer lo mismo en veinte minutos sin pensarlo. La curva de aprendizaje es empinada pero corta.
Cuando los arreglás vos, pasan dos cosas: el problema se resuelve, e ingeniería ve que respetás su tiempo lo suficiente como para manejar lo que podés manejar. Ese respeto se acumula en confianza, que se acumula en influencia con el tiempo.
Qué necesitás antes de empezar
Acceso al repo de tu equipo (ver sección "Cómo Empezar" abajo para cómo ganártelo)
Cursor o Claude Code instalado en tu máquina
Cómo hacerlo
En Cursor / Claude Code, en modo Agent, describí lo que querés en lenguaje natural: "Encontrá dónde está definido el texto del botón 'Enviar' en el flujo de signup y cambialo a 'Continuar'." El agente hace la búsqueda, el fix, y te muestra los cambios.
Correlo localmente, revisalo cuidadosamente. ¿Tiene sentido? ¿Está tocando solo lo que esperabas? Pedile a tu agente que lo revise, que analice riesgos de tu cambio en modo Ask: "¿Estamos listos para pushear nuestros cambios? ¿Estamos tocando algo más además de nuestro fix deseado?"
Una vez que estés seguro, commiteá y abrí un pull request: podés hacerlo manualmente en la sección de Changes, o pedirle a tu agente que lo haga. Asegurate de escribir una descripción clara: qué cambiaste, por qué, y cualquier contexto que un reviewer necesite. Después taggeá y pedile a un ingeniero que lo revise.
Qué puede salir mal
a) Romper algo. Para evitarlo:
Solo tocá cambios aislados, preguntale al agente sobre el blast radius antes de empezar.
Usá las Cursor rules / Claude skills corporativas que sigan los guidelines de ingeniería.
Siempre abrí un pull request en lugar de pushear directo a main.
Si seguís estas reglas, el peor caso es que tu PR sea rechazado y aprendas algo.
b) Arreglás algo incorrecto. Asumís que un link roto está bloqueando conversiones. Lo arreglás, pero las conversiones no se mueven. Acabás de aprender tu assumption, así que usá frameworks de producto y revisitá la pregunta uno: ¿esto es realmente lo que está bloqueando la métrica?
c) Los ingenieros se ponen territoriales. Algunos ven la participación del PM como una intromisión. Pedí permiso primero: "¿Puedo intentar con esto para sacártelo del plato?" La mayoría va a apreciar la ayuda. Algunos no, leé la sala.
Cómo se ve el éxito: Un PR mergeado con tu nombre. Una métrica que se movió porque vos la moviste, un cambio silencioso en cómo te ves: ahora sos alguien que arregla cosas.
Tu PR va a tener comentarios: quizás te faltó algo, o hay un approach más limpio. Esto es el proceso funcionando, así que hacé los cambios, aprendé del feedback, no te lo tomes personal.
Cómo se ve el fracaso: Tu PR queda una semana sin review, acordate de hacer follow up. Rompés algo en staging, flaggealo inmediatamente, revertí, aprendé. Pasás cuatro horas y abandonás, intentá de nuevo la semana que viene con algo más chico. La mecánica se vuelve más fácil cada vez.
CASO 2: El Prototipo | "Traé Evidencia, No Slides"
Tenés una hipótesis. Quizás los usuarios abandonan en el paso tres del onboarding porque pedís demasiada información de entrada. Estás razonablemente seguro de que tenés razón, pero no tenés pruebas.
El camino tradicional: spec → diseño → prototipo → testeo → síntesis. Este ciclo toma de cuatro a ocho semanas, y a veces nunca termina: el prototipo se desprioriza, el aprendizaje nunca pasa, y la hipótesis vive para siempre en un Google Doc que nadie lee.
Ahora podés comprimir este proceso a días u horas.
Por qué importa
Cuando aparecés con un prototipo que usuarios reales tocaron, con su feedback adjunto, la conversación cambia. No estás pidiendo que la gente imagine cómo podrían reaccionar los usuarios, se lo estás mostrando. Esa es una autoridad diferente.
Qué necesitás
Una cuenta de v0 o Lovable, O un branch desde el repo usando Cursor / Claude Code.
Una hipótesis clara (revisa las cuatro preguntas de discovery si no estás seguro)
Acceso a usuarios que puedan testear
Eligiendo tu herramienta
Tenés dos caminos: herramientas de prototipado standalone (v0, Lovable) o branchear directamente en el codebase de tu producto con Cursor / Claude Code.
a) v0 o Lovable funcionan mejor cuando estás explorando un concepto nuevo que no existe en tu producto todavía, cuando querés testear algo radicalmente diferente de la experiencia actual, o cuando necesitás moverte rápido sin dependencias del codebase.
Estas herramientas generan prototipos limpios y funcionales en minutos.
El tradeoff: tu prototipo vive fuera del producto, así que no podés aprovechar componentes existentes, design systems, o data real. Es una simulación, no lo real.
b) Branch nueva en Cursor funciona mejor cuando estás iterando sobre algo que ya existe: un flujo modificado, un paso nuevo en un proceso existente, una variación de la UI actual. Creás un branch, hacés cambios contra el codebase real, y deployeás un preview.
El tradeoff: necesitás acceso al repo y suficiente familiaridad con el codebase para navegar (skills del Caso 1). El upside es significativo: tu prototipo usa componentes reales, styling real, y puede traer data real. Los usuarios están testeando algo mucho más cercano a lo que realmente experimentarían.
Para tus primeros prototipos, v0 o Lovable se van a sentir más fáciles. A medida que te pongas cómodo con los workflows del Caso 1, branchear se vuelve más poderoso.
Qué puede salir mal
Prototipás algo incorrecto. Te salteás la hipótesis y simplemente empezás a construir. Una semana después tenés algo pulido que no prueba nada. Escribí tu hipótesis primero, siempre: "Creo que [segmento de usuario] va a [comportamiento] si [cambio]."
Definí cómo se ve "validado" antes de construir.
Los stakeholders confunden tu prototipo con un compromiso. Ven algo funcionando y asumen que está en el roadmap. Enmarcá claramente cada vez que compartís: "Esto es un prototipo de research para testear una hipótesis. No es un compromiso."
Diseño se siente bypasseado. Si construís sin involucrar a los diseñadores, creás fricción política. Involucralos temprano: "Quiero obtener señal temprana antes de invertir recursos de diseño". La mayoría va a apreciar el approach.
Los usuarios te dicen lo que querés escuchar. Preguntás "¿te gusta esto?" Dicen que sí porque son educados. No pidas opiniones, dales una tarea. Observá dónde dudan. El comportamiento revela lo que la cortesía oculta.
Cómo hacerlo
Escribí tu hipótesis con precisión: hipótesis vagas producen aprendizajes vagos. "A los usuarios les va a gustar el nuevo flujo" no te dice nada. "Si les mostramos a los usuarios un preview de su dashboard antes de pedir el tamaño de la empresa, la completitud del onboarding va a aumentar 15%" te dice exactamente qué construir y medir.
Construí el prototipo:
En v0 o Lovable, describí lo que querés con screenshots de tu producto adjuntos:
"Un flujo de onboarding de tres pasos donde los usuarios ven un preview del dashboard antes de que les pidamos información de la empresa"
Si estás usando Cursor, creá un branch y describí los cambios en modo Plan, después aprobá para construir:
"Estamos construyendo un prototipo para testearlo, así que no te enfoques en código de backend / api, solo enfocate en componentes y UI y si es necesario mockeá comportamientos. El objetivo es modificar el flujo de onboarding para mostrar el componente de preview del dashboard después del paso dos, antes del formulario de info de la empresa"
Revisá lo que genera la IA. Resistí el impulso de pulir, el objetivo es testeable, no hermoso. Cuando commitees y publiques este branch, Vercel (o similar) debería crear el build y darte una URL funcionando.
Obtené el feedback:
a) Podés embeber un formulario simple al final, o botones de reacción después de pasos clave. Cada usuario que toque tu prototipo debería dejar data.
b) Corré sesiones de usuario y compartí el link. Mirá a la gente usarlo via screen share o video asincrónico. Anotá dónde dudan, qué preguntas hacen, qué intentan clickear que no funciona. Solo observá.
c) Resumí con IA. Pegá tus notas en GPT o Claude: "Acá están notas de cinco tests de usuario. Identificá patrones en qué confundió a los usuarios, qué funcionó, y cualquier comportamiento inesperado." Vas a tener una síntesis en minutos que te tomaría una hora manualmente.
d) Decidí: validado, invalidado, o inconclusivo. Si validado, tenés evidencia para priorización. Si invalidado, salvaste a tu equipo de construir algo incorrecto. Si inconclusivo, refiná y testeá de nuevo.
Cómo se ve el éxito: Entrás a una discusión de roadmap y decís: "Testeé esto con ocho usuarios la semana pasada. Seis completaron el flujo en menos de dos minutos, 40% más rápido que el onboarding actual. Acá está el prototipo, acá está el feedback, acá está mi recomendación."
Cómo se ve el fracaso: Los usuarios lo odiaron, bien, aprendiste esto en una semana en lugar de un trimestre. Sintetizá por qué y testeá un approach diferente.
Nadie interactuó con tu prototipo, tu distribución estaba mal, no tu idea. Encontrá mejores canales. Construiste algo hermoso que no testeó tu hipótesis, volvé al paso uno. Escribí la hipótesis primero la próxima vez.
CASO 3: La Feature Completa | "Entregale a Ingeniería una Referencia, No un Doc"
Estás liderando una feature desde discovery hasta delivery: scope real, stakes reales, ingeniería va a pasar días o semanas en esto.
Handoff tradicional: escribís un spec, lo ojean, construyen lo que entendieron. Revisás y decís "eso no es lo que quise decir", el timeline se corre. Approach diferente: después del discovery, construís una referencia funcionando vos mismo, no un prototipo descartable, sino algo lo suficientemente cercano a producción como para que ingeniería pueda usarlo como base.
Ven exactamente lo que querés decir: comportamiento, edge cases, flujo. Refactorean si es necesario y lo endurecen en lugar de reconstruir desde cero.
En qué difiere del Caso 2
En el Caso 2, estás testeando una hipótesis. La velocidad importa más que la calidad del código, mockeás comportamientos, salteás backends, y tirás el prototipo una vez que aprendiste lo que necesitabas.
El Caso 3 es diferente: estás construyendo algo que ingeniería realmente va a shippear. Tu referencia necesita ser lo suficientemente limpia como para que puedan trabajar con ella. Componentes reales, flujos de data reales, patrones que matcheen tu codebase, y código que siga los standards de tu equipo.
Esto significa trabajo más lento y deliberado: planear antes de construir, seguir las reglas y convenciones de tu equipo, crear PRs que realmente puedan ser revieweados.
Por qué importa
La ambigüedad del handoff es el costo oculto más grande del desarrollo de producto. Un ingeniero lee "flujo de onboarding simple" y se imagina algo diferente a lo que vos te imaginaste.
Una referencia funcionando elimina esa ambigüedad: clickean los edge cases, preguntan "¿el estado de error debería verse así?" en lugar de "¿cómo debería verse el estado de error?"
Pero el verdadero unlock del Caso 3 es que ingeniería no arranca de cero. Heredan tu estructura, tus elecciones de componentes, tu manejo de estado, refactorean y mejoran en lugar de interpretar y adivinar.
Semanas de ida y vuelta se comprimen en días de refinamiento.
Esperá invertir de quince a treinta horas en dos a tres semanas. Reservá esto para features donde los stakes justifiquen la inversión.
Qué necesitás
Comodidad con los Casos 1 y 2 (múltiples ejemplos completados de cada uno)
Capacidad de leer y navegar un codebase (con ayuda de la IA)
Buy-in de ingeniería de que van a usar tu referencia
Disciplina metodológica fuerte, acá es donde saltearse pasos se pone caro
Qué es realmente una implementación de referencia
Una versión funcionando de la feature que le muestra a ingeniería exactamente lo que querés decir. Qué tan cerca llega a producción depende de la feature.
a) Features frontend: nuevos flujos, cambios de UI, componentes, tu referencia puede estar lista para producción. Componentes reales, styling real, estado real. Ingeniería revisa, endurece edge cases, agrega tests, y shippea: tu código se convierte en la base.
b) Features que necesitan trabajo de backend: vos construís el frontend, mockeás la capa de data, documentás lo que la API necesita devolver. Ingeniería lo conecta a infraestructura real.
c) Cambios de sistema complejos: tu referencia cubre el happy path con data placeholder. Ingeniería construye el sistema debajo.
Llegá tan cerca de producción como tus skills permitan. Si podés shippear el frontend, shippealo. Si necesitás trabajo de backend, mockealo y especificá lo que necesitás. Dale a ingeniería algo que puedan ver y clickear, no un documento que tengan que interpretar.
Cómo hacerlo
Planificá primero. Antes de escribir código, usá modo Plan en Cursor o Claude Code para pensar el approach. Describí lo que estás construyendo, pedile a la IA que outline los componentes y flujos de data, revisá el plan antes de aprobar cualquier código. Esto atrapa errores arquitectónicos antes de que se acumulen.
Seguí las reglas de tu equipo. Si tu equipo tiene Cursor rules, Claude skills, usalas. Si no existen todavía, pedilas. Tu referencia debería sentirse familiar para ingeniería, no como código extranjero tirado en el repo.
Construí incrementalmente. No intentes construir la feature entera en una sesión. Trabajá en chunks chicos y lógicos: flujo de autenticación primero, después la interacción principal, después el manejo de errores. Commiteá después de cada chunk, esto hace tu trabajo revieweable y tus errores recuperables.
Pedile a la IA que revise tu trabajo. Antes de compartir con ingeniería, pedile a la IA que audite lo que construiste. "Revisá este código por gaps, edge cases que me haya perdido, issues de manejo de errores, y mejoras." La IA atrapa cosas que vas a perder, issues de accesibilidad, estados de loading, error boundaries, patrones inconsistentes. Arreglá lo que puedas, anotá lo que dejás para ingeniería.
Creá un PR real. No solo compartas un link al branch. Abrí un pull request propio con una descripción clara: qué construiste, por qué, qué es intencional, qué es placeholder, qué necesitás que ingeniería termine. Tratalo como un documento de handoff que resulta que incluye código funcionando.
Pedí review antes del handoff. Pedile a tu partner de ingeniería que revise el PR antes de que lo consideres terminado. No un code review completo, un chequeo direccional. "¿Tiene sentido esta arquitectura? ¿Estoy usando componentes correctamente? ¿Qué harías diferente?" Incorporá el feedback, esto saca issues a la superficie mientras todavía podés arreglarlos.
Qué puede salir mal
a) Te salteás el discovery y construís algo incorrecto rápido. Este es el fracaso más común, como siempre pasa con tu equipo de ingeniería. Pasás dos semanas construyendo una referencia funcional para una feature que nadie necesita, el craft es impresionante pero la dirección está mal. Ahora podés construir rápido y decidir mal, así que antes de escribir una sola línea de código: hablá con usuarios, validá sus necesidades y planificá cómo vas a validar la solución.
b) Ingeniería se siente menospreciada. Si perciben tu referencia como "hacer su trabajo" o cuestionar su competencia, creás problemas políticos que duran más que el proyecto. Enmarcá correctamente cada vez: "Construí esto para mostrar lo que quiero decir, vos vas a refactorear todo a standards de producción. Estoy tratando de comunicar más claramente, no de reemplazar tu expertise."
c) Tu referencia es tan desordenada que confunde más de lo que clarifica. Hackeas algo junto que técnicamente funciona pero es tan enredado que ingeniería no puede distinguir qué es intencional versus qué es accidental. Enfocate en el happy path y los edge cases clave. Pedile a tu agente de IA que escriba un archivo .md explicando qué hiciste, qué está incompleto.
d) Te convertís en el cuello de botella. Si pasás sesenta horas en una referencia mientras el equipo espera, enlenteciste a todos. Timeboxeá agresivamente, poné un límite de entrada, y si la referencia no es útil después de eso, shippeá el spec solo y aprendé para la próxima.
e) No podés soltar. Lo construiste, estás orgulloso, pero cuando ingeniería sugiere un approach diferente, resistís porque se siente como crítica. Recordá: la referencia es una herramienta de comunicación. Ingeniería va y debería refactorear todo, tu trabajo es transmitir intención, no shippear tu código.
Cómo se ve el éxito: Ingeniería shippea en la mitad del tiempo usual. No hay conversaciones de "eso no es lo que quise decir" porque pudieron ver lo que quisiste decir. El spec y la referencia juntos eliminaron la ambigüedad que usualmente quema ciclos. Los reviews van más rápido, la estimación es más precisa. Ingeniería quiere trabajar así de nuevo: cambiaste cómo shippea tu equipo.
Cómo se ve el fracaso: Te salteaste el discovery y construiste algo impresionante que nadie necesitaba, doloroso, pero instructivo: hacé el discovery la próxima vez.
Ingeniería ignoró tu referencia completamente, preguntá por qué. Quizás no era útil, quizás era muy desordenada. Esto es feedback para tu próximo intento.
El proyecto tardó más por tu involucramiento, posible en tu primer intento. Trackeá si mejora en los intentos dos y tres. Te quemaste, no timeboxeaste: poné límites más duros la próxima vez.
IMPORTANTE: Colaborar con Ingeniería
Podés aprender Cursor y crear una cuenta de GitHub por tu cuenta, o hacer uno de nuestros cursos. Pero conseguir acceso al repo, conseguir que ingeniería confíe en vos con su codebase, conseguir que tu manager vea esto como valioso, ese es un desafío diferente. Así es cómo navegarlo.
Construí tu caso antes de pedir acceso. No empieces pidiendo acceso al repo de la nada. Empezá mostrando que vas en serio: creá un proyecto personal primero, construí un prototipo con v0 o Lovable, pushealo a tu propio GitHub. Mostrá tu gráfico de contribuciones, mostrá que hiciste lo básico.
Empezá con un pedido específico y de bajo riesgo. No pidas "acceso al repo", pedí acceso para arreglar UNA cosa específica.
Ganá confianza incrementalmente. Tu primer PR probablemente va a necesitar cambios, está bien. ESO ES el proceso. No intentes impresionar, intentá ser útil. Arreglá cosas chicas, hacé buenas preguntas en el PR review. Cada PR que mergees te gana más confianza y más acceso.
Encontrá tu aliado interno. Encontrá a la persona que es paciente, curiosa, o que ya está interesada en que los PMs se pongan más técnicos. Pedile que sea tu code buddy. Esta relación es lo más importante para que esto funcione dentro de una empresa.
El futuro es brillante, si te vuelves técnico
El rol del PM está evolucionando en tiempo real. Construir con IA es una parte de un cambio más grande en cómo trabajamos, y todos todavía estamos descubriendo qué significa ese cambio. Hay un nuevo skillset formándose alrededor de cómo escribir prompts que realmente den resultados, cómo estructurar documentos de proyecto para que la IA pueda trabajar con ellos, cómo pensar en archivos markdown como tus nuevos specs, cómo armar workflows que te dejen ir de idea a prototipo funcionando en horas en lugar de semanas.
Nadie tiene esto completamente resuelto todavía. Las mejores prácticas se están escribiendo ahora mismo, por gente que está experimentando y compartiendo lo que aprende.
Los PMs que descifren esto primero no solo van a mantenerse al día con el cambio. Lo van a definir, an a marcar el ritmo para todos los demás.
Arrancá, construí algo con tus propias manos. From zero to one.