Nate B Jones
El software barato hizo más difícil tu trabajo de PM, no más fácil. Este es el nuevo trabajo.
Pregúntale al tutor sobre este vídeo
Entra con un email verificado y pregúntale al tutor lo que quieras sobre este vídeo.
TL;DR
Resumen de investigación
▶ La IA desplaza el cuello de botella del trabajo de producto
La ponente abre diciendo que el prototipado con Lovable, Claude Code o Codex está bien, pero considera que ya es un requisito básico y que los cursos exageran su importancia. Propone hablar de cómo debe evolucionar la gestión de producto en la era de la IA. Su argumento es que la IA facilita la generación y desplaza el cuello de botella: los equipos deben aplicar deliberadamente la experiencia y el criterio humanos, que son escasos, para lograr resultados relevantes para el negocio.
▶ De filtrar solicitudes a clasificar la abundancia de software
La ponente cita el caso de Microsoft: más de 1 millón de activos de Power Platform, incluidos más de 18.000 entornos de agentes, 170.000 Power Apps, 50.000 flujos de Power Automate y 1.200 chatbots. Interpreta que la historia central no es solo que más personas puedan crear software con herramientas de bajo código e IA, sino que producto debe clasificar esa abundancia como valor de mercado, herramienta interna útil o software que conviene eliminar. Las conversaciones de producto reciben cada vez más artefactos funcionales —paneles, flujos de trabajo, aplicaciones ligeras, automatizaciones, prototipos y agentes—, por lo que la pregunta a menudo pasa de si construir algo a si debe importar y qué sentido tiene. La ponente sostiene que los mejores PM necesitarán entender mercados, usuarios, flujos, sistemas técnicos, datos, evaluaciones, permisos, costes, fiabilidad y confianza para decidir hacia dónde dirigir esa abundancia.
▶ El criterio técnico y humano sigue siendo esencial
La ponente afirma que queda poco espacio para un PM no técnico; aclara que no significa que todos deban ser ingenieros a tiempo completo, sino que los aspectos técnicos determinan profundamente el comportamiento de los productos de IA. Enumera decisiones sobre comportamiento de modelos, ciclos de agentes, acceso a datos, límites de flujos, recuperación de información, evaluación, latencia, coste, permisos y modos de fallo. En su opinión, quien no pueda razonar sobre esos elementos no está comprendiendo el producto. Al abaratarse la producción de software, el recurso escaso deja de ser el primer prototipo y pasa a ser el buen juicio sobre qué debería existir o eliminarse, para quién, con qué estándar y qué apuestas acepta la empresa.
▶ La experimentación amplia requiere juicio y control
La ponente describe el trabajo tradicional de PM como un filtro diseñado para la escasez: PRD, revisiones de hoja de ruta, planificación, priorización y listas de lanzamiento ayudaban a usar deliberadamente el tiempo de ingeniería, porque no se podía construir cada idea ni permitir que cada departamento clonara el producto. La IA altera ese filtro: antes de llegar a producto o ingeniería, la gente ya puede crear herramientas, paneles, automatizaciones, agentes y productos a medio hacer. Por eso, los líderes no pueden esperar pasivamente casos de negocio pulidos; las señales útiles pueden estar funcionando dentro de un equipo junto con mucho ruido. La ponente rechaza la idea de que solo los PM deban prototipar: cualquiera puede hacerlo, y una automatización local o un agente rudimentario puede revelar una necesidad que el producto oficial aún no cubre. Propone observar los artefactos para descubrir de dónde surgen buenas ideas. La creación amplia deja ver demanda nueva, pero sin criterio genera dispersión: trabajo útil oculto, herramientas arriesgadas sin apoyo y dependencias empresariales desconocidas. La función de producto debe permitir que más personas construyan y decidir cuidadosamente de qué dependerá el negocio.
▶ Gobernanza, exposición de secretos y juicio de mercado
La ponente vuelve al ecosistema interno de Power Platform de Microsoft: más de un millón de activos de desarrollo ciudadano, con gobernanza basada en inventario, telemetría, revisión de permisos, controles de entornos y políticas de datos. Presenta la gobernanza como un medio para permitir la creación de empleados y proteger a la empresa. También atribuye al informe State of Secret Sprawl de GitGuardian de 2026 la afirmación de que los secretos de servicios de IA expuestos en GitHub público llegaron a 1,2 millones en 2025, un aumento interanual del 81%; predice que subirían otro 80 o 100% ese año. Vincula la creación más rápida con más credenciales, flujos locales, integraciones y lugares donde puede filtrarse el acceso. Por ello, pregunta qué datos toca una herramienta, a qué sistemas escribe y quién es su responsable: sostiene que ya son preguntas de producto. Amplía el argumento al mercado: como las primeras versiones son baratas, los PM deben decidir por qué construir, qué problema del cliente merece atención, qué flujo se relaciona con ingresos, retención y confianza, qué solicitudes son ruido o síntomas de problemas profundos y qué prototipos revelan demanda real frente a conveniencia local. A esto lo llama juicio de producto.
▶ El espacio común de prototipos y su cuidado
La ponente llama espacio común de prototipos al ámbito informal donde aparecen herramientas antes de que la empresa las clasifique: scripts, paneles, agentes, automatizaciones y productos a medio hacer que resuelven problemas fuera de la hoja de ruta. Considera que ese espacio desordenado es valioso porque revela demanda oculta, capacidades de plataforma ausentes, dificultades de clientes y flujos internos que el proceso oficial aún no entiende. Necesita alguien que lo cuide: sin responsables, el trabajo útil permanece invisible y el arriesgado se difunde sin apoyo; si producto solo responde que no, los empleados pueden ocultar sus herramientas hasta que algo falle. Recomienda una postura de descubrimiento abierto: preguntar qué se creó, qué problema resuelve, quién lo usa, qué datos toca y qué se aprendió; después, aplicar una escala de clases de producción que fomente la innovación.
▶ Una escala de producción con promoción y descenso
La ponente propone cuatro niveles. Una herramienta personal es para una persona, puede ser rudimentaria y debería evitar datos sensibles salvo que existan reglas para manejarlos localmente. Una beta de equipo, usada por un grupo pequeño, necesita responsable y suplente, una descripción breve, explicar los sistemas que toca y el beneficio para el equipo, además de un plan de fallos. Un producto interno con soporte es software del que depende la empresa: requiere responsable de producto, colaboración con plataforma, gestión de acceso, monitorización, documentación, soporte, auditabilidad y proceso de cambios. Un producto o función para clientes forma parte del proceso externo y necesita los estándares habituales de producto, además de evaluaciones y gobernanza específicas de IA cuando la superficie lo requiera. Insiste en que las clases no deben confundirse y que la primera versión no tiene que cumplir los requisitos de la versión con soporte. En el nuevo modelo, producto decide qué promover desde el espacio de prototipos y también qué rebajar; una escala que solo ascienda se convierte en un cajón de herramientas y obligaciones abandonadas. Las decisiones deben definir qué promesas se hacen a clientes y dentro de la empresa, y qué software se deja deliberadamente en un nivel personal o inferior. De lo contrario, según la ponente, la empresa asumirá costes de soporte de software muerto antes de poder identificarlo; a eso lo llama la nueva deuda técnica.
▶ Qué hacer después de que exista el prototipo
La ponente dice que la conversación se ha centrado en la rapidez con que la IA lleva una idea a un prototipo, lo que mostró que el coste de las primeras versiones cayó y que los PM pueden participar en ello. Considera más importante decidir qué ocurre después: sin plan, la empresa acumula demostraciones abandonadas; si todo pasa a producción, genera caos; si solo producto e ingeniería pueden construir, se desperdicia capacidad creativa habilitada por la IA. Recomienda permitir por defecto la experimentación y establecer una vía de promoción deliberada, gobernada por producto, para el software del que dependerá el negocio. Pide identificar la clase de software —herramienta personal, beta de equipo, producto interno con soporte o compromiso con clientes— y luego preguntar si debería existir, para quién, qué estándar debe cumplir y en qué puede confiar la empresa. Cierra con una valoración positiva del momento para producto: ahora es posible construir mucho más, y el reto es ejercer criterio, crear una escala de clases de producción y dirigir la energía creativa hacia lo que importa a los clientes.
Transcripción completa
[00:30] conversation with my fellow PMs about what is happening in our discipline and how we need to change and evolve in the age of AI because I think the prototyping advice is oversold and we need to be very deliberate about what we're doing because it comes back to the same idea that I've been kind of really sitting with, which is the idea that AI makes generation easier. So, it moves the bottleneck and we need to be very intentional about how we leverage human expertise from there to make sure that
[01:00] we are effective with our intelligence, our scarce human intelligence, and we drive what really matters for the business. If you're wondering what AI looks like at a big company, Microsoft has a story for you. They have built more than 1 million Power Platform assets inside the company. Power Platform is what they call their sort of AI tooling, right? That includes more than 18,000 different robot environments or agent environments, 170,000 Power Apps, 50,000 Power Automate flows, and 1,200 chatbots. The obvious story here
[01:31] is that low code and AI are letting more people build software, right? The real story is that product management is moving from rationing scarce engineering to classifying and strategizing with software abundance. That matters because the thing arriving in the product conversation is no longer just a request in most cases. It's often a working artifact. It's a dashboard, a workflow, a lightweight app, a local automation, a customer-facing prototype, maybe an agent that already touches the system of record. So, the old product question was
[02:02] should I even build this? The new product question often starts a step later. Somebody already built something, now the company has to decide whether it should matter and and sense make out of it. This is the PM shift that I want to talk about today. It is becoming the discipline that classifies software abundance into market value, internal tooling that's useful, or that decides to delete it. And that's a much more strategic job. It's also a much more technical job. The best PMs in the next few years will not be ticket brokers. They will be people who understand
[02:32] markets and users and workflows and technical systems and data and evals and permissioning and cost and reliability and trust well enough to decide where software abundance ought to be pointed. There is not much room left for the non-technical PM. I don't mean every PM has to become a full-time engineer. I mean AI products are technical systems and the technical aspects of AI are profoundly determinative of their overall behavior. So, we need to understand them well to work with them.
[03:03] Product decisions now involve model behavior and agent loops and data access and workflow boundaries and retrieval and evaluation and latency and cost and permissions and failure modes. A PM who cannot reason about those things is missing the product. At the same time, AI does not empty human value out of the product work. It actually just shifts the bottleneck. When software production gets cheaper, the scarcest thing is not the first version, the first prototype. The scarcest thing is great judgment about what ought to exist, what ought to
[03:33] be deleted, who the product is for, the standard it needs to meet, and what the company is willing to bet on. So, the old PM job was really built around scarcity. Product rituals make sense when software is expensive, so PRDs and roadmap reviews and planning cycles and launch checklists, prioritization meetings, all of that is built around slow work so that engineering time is consumed deliberately. That was the whole point. When software is expensive, the company needs a filter, the PM is the filter. You can't
[04:05] afford every stray idea. You can't afford every department cloning the product, and the PM had to run the filter. AI kind of destroys that filter because it changes what people can produce before they ever reach product and engineering. And so the top of the funnel used to be words, and it used to be mock-ups and spreadsheets and persuasion, but now it's got working tools and dashboards and automations and agents and half real products, like zombie products, right? A product leader can no longer wait passively for polished business cases in that world.
[04:37] The useful signal may already be running inside a team along with a lot of noise that isn't useful. So, what you need to do in that world is not to shut it down. I hear a lot of PM instincts to say, "Well, our job now is to prototype." And nobody else's. No, everybody's job is to prototype. The local automation makes full use of platform gap. A messy agent may show that customers want an outcome the official product doesn't support, and maybe the customer service rep built that, not the PM. So, you need to understand where the good ideas in your org are coming from in the form of
[05:07] artifacts and prototypes. The company needs broad building because that is where new demand becomes visible. But broad building without judgment becomes sprawl. Useful work stays hidden, risky work spreads without support, and nobody knows which tools the business now depends on. The product function has to hold both ideas at the same time. Let more people build and decide carefully what the business will rely on. The world is producing more software-shaped work than product organizations were
[05:37] ever built to evaluate. The same pattern is happening inside companies, right? Microsoft's internal Power Platform ecosystem is a great example here. More than a million citizen development assets inside one company with governance built around inventory and telemetry and permission review and environment controls and data policy. Microsoft didn't share all of this as a reason to stop employees from building. Instead, it presented governance as a way to let employees build while protecting the company. GitGuardian's 2026 state of secret sprawl report says
[06:08] AI service secrets exposed on public GitHub reach 1.2 million in 2025. It's up farther now. It was up 81% year-over-year in 2025. It's going to climb another 80 or 100% this year, I bet you. Faster creation means those mistakes. It means more credentials, more local workflows, more integrations, and more places for access to leak. Product leaders inherit that problem when useful tools spread before anyone decides what class of thing they are. The question is not only whether a prototype seems useful. The question is
[06:39] what data does it touch? What systems does it write to? Who owns it? Those are now product questions, not just engineering questions, and they require more of our technical market judgment, not less. It's It's so easy to hear all of this as an internal tooling problem. But that would make the world too small. Cheap software makes PMs more responsible for market judgment, and that includes judgment from the market around all of our tooling inside and outside the business. But now first versions are really cheap, and so the
[07:10] question for us becomes really sharp. Why are we building this at all? The PM has to understand the market well enough to aim production successfully. Which customer problem is really worth solving here? Which workflow is close enough to money and retention and trust so that it's forming a really good habit with customers. Which competitor feature is just noise? Which customer request is a symptom of a much deeper issue? Which internal prototype reveals real demand, and which one is just local convenience for one team? That's not product
[07:41] management. That is product judgement. So, what does the new job look like in practice? Let's start with the prototype commons. The prototype commons is the informal space where new tools appear before the company has classified them, where scripts and dashboards and agents and automations and half real products built because employees can finally solve problems that never made it onto a road map all sprout up together. That space is messy, but it's really valuable. It reveals hidden demand and missing platform primitives and customer
[08:11] pain and internal workflows that the official product process has not yet understood. But, a common still needs stewardship. If nobody owns it, useful work stays invisible and risky work spreads without the right support. If a product shows up only to say no, employees will start hiding useful tools until something breaks. So, within that context, I think the better posture for PMs to adopt is open discovery. Show us what you made. Show us the problem it solves. Who uses it? What data does it touch? What did you learn? Then, use a
[08:42] production class ladder. A production class ladder has a few rungs that help you make sense of this messy prototype commons and apply your PM judgement in ways that encourage innovation rather than discourage it. So, let's start with personal tools. A personal tool is for one person, right? It can be scrappy. It should stay away from sensitive data unless the company has rules for local handling. And, it's something that you don't have to have a lot of other standards around. Go up a level. A team beta is used by a small group. It will need an owner. It will need a backup owner. It should have a
[09:12] short description. It should talk about the systems it touches, why it benefits the team, and there should be a failure plan. Go up another level. A supported internal product is software the company does depend on. It does need product ownership. It needs platform partnership. It needs access management and monitoring. It needs documentation and support and auditability and a change process. It's much more serious. A customer-facing product or a feature is part of the company's external process. This is the fourth rung on the ladder. It needs the usual product
[09:43] standards plus AI-specific evals and governance where the surface requires it. And the important point is that these are very, very different classes and we shouldn't mix them up. The first version of a thing and the supported version of a thing don't have to be the same, right? In the old model, PMs decided what entered engineering and that is what became supported and that's what became official software. In the new model, PMs also decide what gets promoted out of the prototype comments. And demotion matters just as much as
[10:13] promotion here, right? A ladder that only moves upward is going to become a junk drawer. Everything eventually gets to production or gets to some kind of support level and it's just a pile of old obligations that nobody wants to own. So, you need to think about what kinds of customer promises you want to make in production, what kinds of customer promises you want to make internally, and where you want to leave the rest to be intentionally demoted or left at the personal software level. And that is a
[10:43] real PM shift because if you don't do that, the company will pay support cost on dead software faster than it can name it. That is the new tech debt. And so the product conversation has spent a lot of time on how fast AI can move an idea to a prototype. And I hear that over and over again from PMs. That was useful. It showed us that the cost of first versions have collapsed and we get to play a part in that as PMs. I think the next question matters more. What happens after the prototype exists? If the
[11:14] answer is we don't know, we don't have a plan, the company gets a graveyard of demos. If the answer is everything goes to production, the company gets chaos. If the answer is only central product and engineering may build, the company wastes a ton of creative capacity that AI just unlocked. The better answer is a default allow system for experimentation and a very very intentional promotion path governed by product for work the business will rely on. And so that's the decision rule I recommend. If you're a PM, stop asking
[11:44] only whether your team can build faster. Ask what class of software you're looking at. Is it a personal tool? Is it a team beta? Is it a supported internal product? Is it a customer-facing promise? Then ask the harder question. Should this exist? Who is it for? What standard does it need to meet and what are we willing to rely on? That's the new product job. In the meantime, keep your head up as a PM. This is an incredibly exciting time to be in product. For so long, we've had to say we can't build everything. Now we
[12:14] finally get to play the other side of the game board. We get to say we can build everything. What should we build? And I love that we get to challenge of exercising our judgment. So be the PM that is post-prototype. Figure out how to use your judgment to build a true production class ladder to help your organization channel its creative energy to build what matters for customers. I'll see you next time. Cheers.