Producto
Liderazgo de producto para empresas técnicamente complejas.
A medida que implementar se vuelve más barato, el criterio, el entendimiento del cliente, las decisiones estratégicas, el diseño organizacional y la velocidad de aprendizaje se vuelven más valiosos.
Lidero producto y tecnología en empresas donde el producto tiene un piso operativo que nunca se detiene: conectividad, aprovisionamiento, facturación, cumplimiento. Estas son las posiciones que sostengo y la evidencia detrás de ellas.
Also available in English.
Estrategia de producto
La estrategia es lo que rechazas. La mayoría de roadmaps que heredo son listas de cosas a las que nadie se opuso, y eso no es un conjunto de decisiones. Me importa nombrar para qué cliente somos, qué restricción aceptamos y qué alternativas no vamos a perseguir este año — y dejarlo lo bastante claro para que un equipo pueda decir no sin pedir permiso.
Descubrimiento de producto
El descubrimiento es una disciplina, no una fase. La parte que los equipos se saltan es definir, antes de empezar, qué resultado cambiaría la decisión. Sin ese umbral, cualquier resultado se lee como un éxito parcial. Ingeniería entra desde el inicio: una opinión de viabilidad entregada al final no es un insumo, es un veto.
Modelos operativos de producto
Un modelo operativo es la respuesta a una pregunta estrecha repetida muchas veces: para este tipo de decisión, quién decide, a quién hay que consultar y qué evidencia se necesita. Los derechos de decisión escritos le ganan al cambio estructural casi siempre, porque los derechos no escritos terminan en manos de quien escala con más insistencia.
El modelo que uso →Producto e ingeniería: responsabilidad compartida
Especialidades distintas, resultados compartidos. La división clásica — producto es dueño del qué, ingeniería del cómo — hace que cada lado responda por un resultado que el otro controla, así que ambos pueden tener razón mientras el producto no avanza. El trabajo de continuidad es la señal: si compite caso por caso contra features, pierde hasta que gana de forma catastrófica.
Derechos de decisión y antipatrones →Desarrollo de producto con IA
Implementar más barato movió la restricción hacia el criterio, el contexto, la distribución, la confianza y la adopción. La consecuencia práctica es una regla de asignación: gastar la capacidad nueva en experimentos reversibles, y usar el tiempo ahorrado para ir más despacio en las decisiones irreversibles. Los equipos que solo producen más rápido producirán más de lo equivocado.
Dónde quedó la restricción →Estrategia de productos de plataforma
Una plataforma es un producto solo cuando tiene capacidades reutilizables, consumidores que puedes nombrar, gobernanza que de verdad operas y apalancamiento que puedes expresar por consumidor. Si falla una prueba, tienes infraestructura compartida — que está bien, pero se gestiona distinto y no debería venderse internamente como estrategia.
Las cuatro pruebas →Métricas y resultados
La métrica que predice resultados es la velocidad de aprendizaje: cuánto pasa desde iniciar una apuesta hasta tener evidencia que cambie la decisión. Junto a ella sigo la latencia de decisión, el cumplimiento de la asignación de continuidad, la tasa de fallas por cambio y qué porcentaje del trabajo es trazable a un problema declarado. Velocity y número de features miden movimiento, así que no los reporto hacia arriba.
El conjunto de métricas →Argumentos completos
Los ensayos largos están escritos en inglés.
- Product leadership CTO and product leadership are converging, but they are not the same job Technical leadership is expanding from controlling implementation toward shaping product direction, organizational capability, and strategic choices. That expansion has limits worth naming.
- Product operations A product-engineering operating model with separate specialties and shared ownership Product and engineering should specialise differently and be accountable for the same outcomes. This is the model I use, including the decision rights, the metrics, and the antipatterns it is designed to prevent.
- AI product systems AI moved the constraint, it did not remove it When implementation gets cheaper, the binding constraints move toward judgment, context, distribution, trust, and organizational adoption. Teams that only get faster at producing will produce more of the wrong thing.
- Platform products A platform is a product only when it has consumers, governance, and measurable leverage Four tests separate a platform product from a pile of shared services. Most internal platforms fail at least one of them, and the honest response is usually to stop calling it a platform.
Preguntas en las que estoy trabajando
- ¿Dónde está la línea honesta entre implementación generada y código que debe razonarse línea por línea? Mantengo un estándar más estricto en movimiento de dinero, aprovisionamiento e identidad, pero aún no puedo defender ese límite como principio en lugar de preferencia.
- ¿Cómo se financia el trabajo de continuidad en una empresa a la que todavía no le ha dolido descuidarlo? Todos los mecanismos que conozco dependen de una cicatriz.
- ¿Qué reemplaza al roadmap como artefacto de comunicación cuando la velocidad de aprendizaje importa más que las fechas, sin perder la coordinación que el roadmap sí daba?
- ¿Cuánto descubrimiento se puede delegar a un equipo de operaciones que ya habla con clientes todo el día, y qué se rompe cuando lo haces?
Trabajo seleccionado
- AI product systems Building a seven-server MCP ecosystem as a developer product, not a code dump Seven Model Context Protocol servers published on npm, six in Rust and one in TypeScript. The interesting decisions were about credentials, install friction, and tool granularity — not about the protocol.
- Product strategy Five public apps, and what shipping small things in the open actually teaches A resume builder that stores nothing, a VS Code extension that interrupts you, a tax-registry API, an image tool, and a game. Each one is a decision about scope, and one of them I would not build again.