11 señales para inventar trabajo cuando nadie te asigna nada

Tu jefe no te va a asignar esta semana. No hay ticket, no hay sprint, no hay nadie que te diga "ocho, después haz el módulo de pagos". Y en una plataforma interna eso no es un problema de Product Management: es el diseño del puesto.

Sujith Nair, staff engineer en una empresa de infraestructura, publicó una guía que reventó Hacker News esta semana: 230 puntos y 45 comentarios en dos días. Su tesis es directa: en un equipo de plataforma el trabajo no existe hasta que un ingeniero lo inventa. No hay hoja de ruta, no hay línea de ingresos, no hay mercado que perder. Y esa guía incluye once señales concretas para encontrarlo.

La leí completa. Y tiene razón en algo que casi nadie dice en voz alta: el backlog vacío casi nunca es falta de ideas. Es falta de criterio para elegir entre once ideas.

Las señales que emite el sistema

Tu infraestructura habla todo el tiempo. El problema es que solo te avisa de lo que duele hoy, no de lo que te va a doler en seis meses.

1. Los postmortems. Los crashes y sus análisis son la señal más obvia y la más mal usada. Un postmortem bien hecho te dice qué arreglar, no qué construir. Pero si cruzas varios, aparecen patrones. Sujith lo admite: es un indicador muy rezagado y sesga al equipo hacia el fallo más ruidoso y más reciente, no hacia la mayor oportunidad.

2. El costo. La factura de la nube es tu estrella polar. Pero no te quedes en optimizar la query. El autor propone algo más agresivo: revisar el P&L de tu unidad de negocio, línea por línea, y preguntarte qué pasaría si dejaras de externalizar esa función. Y al revés: qué tienes en tu scope que deberías estar delegando a un proveedor. Su conclusión es la que más me gustó: buy-versus-build no es una decisión única, es revisable cuando cambian el scope, el equipo o el mercado.

3. Tu propio toil. Todo equipo tiene trabajo basura. Casi nunca se prioriza. Pero aquí viene el giro que me parece el más valioso del artículo: tu toil no es el toil de tu usuario. Arreglar el tuyo mejora la economía unitaria. Arreglar el suyo mejora la experiencia. Son dos mediciones distintas con dos métricas distintas, y confundirlos es el error más común que veo en equipos de plataforma.

Las señales que emiten los usuarios

Aquí está la parte que más me hizo ruido, porque es la que más se contradice con lo que se enseña en cualquier curso de product.

4. Descubrimiento continuo. Hablar con usuarios cada semana. No para preguntar qué quieren — eso devuelve caballos más rápidos — sino para entender el espacio del problema. Su guion tiene cuatro preguntas, y la cuarta es la que casi nadie hace: "¿quién más tiene este mismo problema?". Y una regla de oro: casi todo problema real ya tiene un hack. Si nadie lo resolvió con un parche improvisado, el dolor no es lo bastante agudo para justificar trabajo nuevo.

5. Casos de uso sobrecargados. Este es el favorito del autor y también el mío. La gente usa tu plataforma para cosas para las que nunca fue diseñada. Eso no es abuso: son prototipos que tus usuarios construyeron gratis para ti. Un equipo de soporte que mete tickets de RRHH en tu base de datos no está rompiendo tu sistema, te está diciendo exactamente qué construir. La prueba para decidir si lo asimilas es la misma: ¿quién más tiene el mismo problema?

6. Partner-to-prototype. Lo mismo, pero arreglado a propósito: montas el experimento con el usuario en lugar de esperar a que lo haga por su cuenta. Un prototipo no es una promesa de feature. Es una exploración conjunta. Cuesta más, pero la evidencia es de la misma calidad.

Las señales que emite la organización

7. Los OKRs. Si tu equipo tiene uno, el trabajo ya está inventado. Felicidades, siguiente.

8. La heurística de repetición del manager. Si escuchas a tu jefe —o al jefe de tu jefe— decir lo mismo dos veces en una semana, hay una preocupación sin atender detrás. Anótalo en el 1:1. Pero Sujith es honesto: es la más débil de todas, porque mientras más alto el cargo, más lejos de los usuarios y más probable es que construyas lo que dice la persona mejor pagada.

9. Los escombros de una migración. Cada cambio grande deja cola. La adopción tiene una curva con cola larga —con early adopters al frente, y luego un grupito que se arrastra y nunca se sube. Ese grupito rezagado es una señal ignorada: te dice por qué tu offering está incompleto. Tu solución para el usuario mediano no está sirviendo a los extremos, y ahí es donde vive el trabajo que falta.

Las señales de la industria

10. Escribir para descubrir. Esta es la favorita de Sujith y también la más barata. Describir un sistema que ya existe —un documento de diseño para tus pares, para un nuevo ingreso, para quien sea— y compararlo con sistemas equivalents de primer nivel en la industria. Ese acto de escribir saca a la luz decisiones que ya no tienen sentido. Es pensar escribiendo, y no cuesta nada.

11. El arbitrage del rezago. Cualquier dominio de la computación oscila entre fases de empaquetado y desempaquetado. Empaquetamos cómputo y almacenamiento en data warehouses, los separamos en data lakes, y ahora los volvemos a empaquetar en lakehouses. Los monólitos dieron paso a microservicios, que están dando paso al monólito modular. Las plataformas internas oscilan igual, pero con retraso. Y ese retraso no es un bug: es la grieta por donde entra la evidencia gratis —postmortems públicos, benchmarks comparativos,-flexbox posiciones que la industria ya abandonó— sin tener que pagarla generándola tú mismo. El único error es demorarse demasiado y quedarte en el grupo de los rezagados.

El problema nunca fue la falta de ideas

Aquí está el cierre del artículo, y es la frase que me voy a robar conceptualmente porque define todo lo demás:

El modo de fallo de un equipo de plataforma no es el backlog vacío. Es un backlog armado con las señales más ruidosas —normalmente el crash más ruidoso, a veces el skip-level.

Inventar trabajo se trata menos de encontrar una señal que de ser capaz de decir por qué esta y no las otras diez. Eso es una habilidad de criterio, y por eso no se enseña en ningún curso.

Y antes de que alguien me diga "esto es demasiado de nicho": en 2026 el boom de infraestructura como producto trajող un montón de gente a roles de plataforma. Los que sobreviven no son los que ejecutan más rápido, son los que saben elegir. El resto espera tickets.

¿Tú cómo decides qué construir cuando nadie te lo pide? ¿Inventas tú o esperas la orden? Cuéntamelo en los comentarios — me interesa especialmente el argumento de los que dicen que esperar es lo correcto.

Comparte esto con ese compañero que lleva tres semanas esperando que le asignen algo. Le vas a ahorrar un trimestre entero.