Product Owner con criterio técnico.
Definí, construí y sostuve una plataforma que hoy usan alrededor de 200 alumnos y docentes para armar unos 30 proyectos por año. Escribo código, así que cuando digo que algo no vale la pena construir, sé lo que estoy descartando.
La prueba
- ~200
- usuariosplataforma en producción durante 2 cursadas
- ~300
- ideas de proyectoprocesadas de punta a punta
- ~30
- proyectos por añoen dos años de una carrera técnica
- 0
- experiencia previadefiniendo producto cuando empecé
El último dato no es un chiste. Está ahí porque es la pregunta que vas a tener después de leer los tres primeros.
TIC Platform
El proceso de ideación y armado de equipos de una materia técnica corría sobre un tablero de notas compartido, sin roles ni permisos. Los alumnos publicaban ideas, los docentes las coloreaban para aprobarlas, y las postulaciones a proyectos iban en los comentarios. Un docente levantaba todo a mano en Excel. Hubo alumnos que recolorearon ideas rechazadas para que se las dejáramos hacer, y a veces se nos escapó: el que rechazaba no era el que después formaba los grupos.
Construí la plataforma que lo reemplazó. Arrancó como una prueba de concepto de una pregunta corta —si lo codeo yo, ¿a qué llego rápido?— y creció cursada a cursada hasta cubrir el proceso completo.
La decisión que define el producto es una que dije que no. Me pidieron que la plataforma armara los equipos automáticamente cruzando postulaciones con proyectos. No lo construí: el criterio real de armado es implícito, un docente sabe qué perfiles no funcionan juntos y eso no está en ningún campo de un formulario. Cada nombre asignado a un grupo decide dónde trabaja esa persona los siguientes meses. Tiene que ser un clic intencional.
Leer el caso completo(decisiones, build vs. buy, lo que no funcionó)
Cómo trabajo
Hablo con desarrolladores como par, no como intermediario.
Escribo código. Cuando estimo, sé si el número tiene sentido. Cuando defino un requerimiento, sé cuál de las tres formas de resolverlo va a costar el triple. Tu equipo no me va a tener que traducir nada.
Diez años enseñando.
El trabajo diario de un docente es transmitir una visión, sostenerla frente a gente que todavía no la comparte, y explicar el por qué detrás del qué. Es la competencia central del rol, y casi ningún perfil que viene del carril técnico la trae.
Prefiero el "no" fundamentado al backlog largo.
El caso de arriba es, en buena medida, un inventario de lo que decidí no construir: el matching automático, las postulaciones públicas, la IA para redactar ideas. Es la parte del rol que menos se muestra y la que más define el resultado.
Otros proyectos
HT Lab
Herramienta de análisis para managers de Hattrick, con licencia CHPP aprobada por el juego. Optimización de alineaciones, estimación de resultados de temporada y planificación de estadio. Node/Express, PostgreSQL.
Generador de paletas de colores
Generación y gestión de paletas con seis tipos de armonía cromática. Astro, Supabase, Vercel.
En qué punto estoy
No vengo de un rol formal de Product Owner en industria. Vengo de haber tenido que decidir qué construir, construirlo, y sostenerlo con usuarios reales durante dos años, sin equipo y sin presupuesto.
Si tu equipo necesita a alguien que ya sepa cómo se hace en tu empresa, no soy yo. Si necesita a alguien que sepa decidir qué vale la pena construir y pueda discutirlo de igual a igual con quien lo va a construir, hablemos.
Si llegaste desde un mensaje mío, respondelo y seguimos ahí.
Veinte minutos, sin CV y sin proceso de por medio. Si preferís, contame en qué está tu producto ahora y te digo qué haría yo con eso.