learning-front

Nivel 12 · Cómo es el trabajo de verdad

Entender el producto y el negocio

Por qué un dev que entiende el porqué decide mejor: la cadena visión → estrategia → roadmap → OKRs → métricas, los OKRs (objetivo + key results), las métricas leading vs lagging, las vanity metrics, el MVP y los stakeholders.

El capítulo anterior terminó con una idea: comunicar bien incluye saber explicar por qué importa lo que haces. Para eso hay que levantar la vista del código hacia el producto y el negocio. Y aquí mucha gente técnica tuerce el gesto: “eso es cosa del Product Owner, yo programo”. Es un error, y de los caros.

No se trata de que te vuelvas product manager. Se trata de entender lo suficiente para ser mejor ingeniero: alguien que toma decenas de microdecisiones al día que el ticket no especifica, y que las toma a favor del objetivo en vez de a ciegas.

Por qué te importa a ti#

Dos desarrolladores cogen el mismo ticket del filtro por rol. El primero solo mira el ticket: lo implementa de la forma que primero se le ocurre. El segundo sabe que el objetivo del trimestre es que la gente complete equipos y vuelva, y que este filtro existe para ayudar a descubrir héroes. Con eso en la cabeza, elige una solución que haga el filtro fácil de encontrar y usar, y cuando va con prisa recorta el adorno, no la parte que mueve el objetivo.

Mismo ticket, dos resultados distintos. ¿Y qué marca la diferencia? Entender el porqué. Quien no lo entiende ejecuta literalmente lo que pone el ticket y, con toda la buena intención, a veces pule lo que no importa mientras descuida lo que sí. Por eso este capítulo no es “cultura general de empresa”: es una herramienta de ingeniería.

La cadena: de la visión a la métrica#

Las decisiones de una empresa de producto no salen de la nada: bajan por una cadena que va de lo más aspiracional a lo más concreto y medible.

text
VISIÓN        Adónde queremos llegar (a años vista, inspirador)
   │          "Ser la forma más rápida de armar un equipo competitivo"
   ▼
ESTRATEGIA    Cómo vamos a llegar: las grandes apuestas
   │          "Centrarnos en la velocidad de armado, no en features sociales"
   ▼
ROADMAP       Qué construimos y en qué orden (por temas, no fechas exactas)
   │          "Este trimestre: filtros y búsqueda del roster"
   ▼
OKRs          Las metas medibles del trimestre
   │          "Que el 40% complete un equipo"
   ▼
MÉTRICAS      Los números que vigilamos para saber si vamos bien
              "Usuarios que completan equipo, retención a 7 días"

Tu ticket vive al fondo de esa cadena: sirve a un OKR, que sirve a la estrategia, que persigue la visión. ¿Y qué aporta verla entera? Saber situar lo que haces. Cuando alguien no ve la cadena, confunde estar ocupado con avanzar: cierra tickets sin preguntarse hacia qué. Vamos a las dos piezas que más vas a tocar como dev: los OKRs y las métricas.

OKRs: objetivo y key results#

Un OKR (Objectives and Key Results) es la forma más extendida de fijar metas de trimestre. Tiene dos partes:

  • El Objetivo: cualitativo, ambicioso, inspirador. El “qué queremos lograr”.
  • Los Key Results: 2 o 3 resultados medibles que demuestran que lo lograste. El “cómo sabremos que lo conseguimos”.

La regla que casi todo el mundo incumple al principio: los key results son resultados, no tareas. Compara:

text
MAL (key results que son tareas)
Objetivo: que la gente use más el Team Builder.
KR: lanzar el filtro por rol.
KR: lanzar la búsqueda por nombre.

BIEN (key results que son resultados)
Objetivo: que la gente arme equipos de verdad y vuelva.
KR: subir del 15% al 40% quienes completan un equipo.
KR: subir la retención a 7 días del 12% al 25%.

¿Y qué tiene de malo el primero? Que puedes lanzar el filtro y la búsqueda —marcar los KR como hechos— y que nadie use más el producto. El OKR diría que “lo lograste” mientras el objetivo real no se ha movido un milímetro. Un key result que es una tarea es una lista de tareas con corbata. El bueno mide el efecto, así que no puedes engañarte.

Métricas: leading vs lagging#

Para saber si vas bien, miras métricas. Y hay una distinción que cambia cómo las usas:

  • Una métrica lagging (rezagada) mide un resultado que ya ocurrió: ingresos, retención a 7 días. Es lo que de verdad quieres mover, pero llega tarde y no la tocas directamente.
  • Una métrica leading (adelantada) anticipa ese resultado y sí es accionable: cuánta gente usa el filtro esta semana, cuántos completan el primer equipo.

Ejemplo en el Team Builder: tu lagging es la retención (lo que persigues), pero tarda semanas en reflejarse. Tu leading es el uso del filtro en la primera sesión: se mueve a los pocos días de lanzar. Si la leading no sube, sabes pronto que algo falla y reaccionas en este sprint.

¿Y qué pasa si te guías solo por las lagging? Conduces mirando el retrovisor. Para cuando ves caer la retención, el problema lleva semanas haciéndose y ya es caro de arreglar. Las leading son el parabrisas: te dejan corregir mientras aún se puede.

Vanity metrics: los números que engañan#

No toda métrica que sube es buena noticia. Una vanity metric (métrica de vanidad) es la que queda bonita en un informe pero no informa ninguna decisión. El ejemplo clásico: “usuarios registrados totales”. Solo crece —nadie se borra del histórico—, así que siempre “va bien”, aunque el producto se esté vaciando por dentro.

text
VANITY:      usuarios registrados totales (solo sube, da igual lo que pase)
ACCIONABLE:  usuarios activos esta semana (baja si el producto deja de servir)

¿Y qué peligro tiene? Que optimizas para el número equivocado. Si tu marcador es “registros totales”, harás más campañas de registro y celebrarás, mientras la gente que entra se va a medias y nadie lo nota. La métrica accionable equivalente —usuarios activos— sí baja cuando el producto falla, y por eso duele y por eso sirve. Ante cualquier métrica, pregúntate: ¿qué decisión cambiaría si este número subiera o bajara? Si la respuesta es “ninguna”, es vanidad.

MVP: mínimo en alcance, no en calidad#

Cuando se va a construir algo grande, oirás “hagamos primero un MVP” (producto mínimo viable): la versión más pequeña que ya aporta valor y permite aprender de usuarios reales. Para “guardar equipos”, un MVP podría ser guardar UN equipo en el navegador, sin sincronización entre dispositivos todavía: pequeño, pero completo y útil.

Cuidado con la confusión más común: MVP no es “v1 cutre y con bugs”. Mucha gente entrega algo roto en nombre de la rapidez y lo llama MVP. Eso no es viable: es una mala primera impresión que ahuyenta justo a los usuarios de los que querías aprender. El MVP es mínimo en alcance (hace pocas cosas), no en calidad (lo que hace, lo hace bien). Es, en el fondo, la vertical slice que ya viste llevada al nivel de producto: el corte más pequeño que funciona de verdad.

Stakeholders: quién tiene algo en juego#

Un stakeholder (parte interesada) es cualquiera con interés en el producto o afectado por él: el negocio, los usuarios, soporte, legal, otros equipos que dependen de lo tuyo. No es solo “el cliente”.

¿Y por qué te importa a ti? Porque saber quiénes son te dice a quién afecta una decisión y de quién conviene recoger feedback (en la review del sprint, por ejemplo). El filtro del roster puede afectar a soporte (recibirá menos preguntas de “cómo encuentro a X”), a negocio (si mejora la retención) y a legal (si en algún momento toca datos personales). Olvidarte de un stakeholder relevante hace que su problema aparezca tarde, cuando ya lo has construido y rehacerlo cuesta caro.

Lo que es de Data y Product (de pasada)#

Verás más herramientas para decidir con datos: los A/B tests (enseñar dos versiones a dos grupos y comparar), el análisis por cohortes (seguir a grupos de usuarios en el tiempo), la atribución (saber qué trajo a un usuario). Son potentes, pero son sobre todo territorio de Product y Data.

¿Qué se espera de ti? Entender qué son y para qué sirven —para colaborar bien y, a veces, implementar la medición que necesitan—, pero no dominar su estadística ni cargar con su análisis: ese no es tu rol. Saber dónde acaba tu responsabilidad es tan profesional como hacer bien tu parte: ni te desentiendes ni te pones a hacer el trabajo de otro.

Comprueba lo que sabes#

Pregunta 1 de 9

¿Por qué le interesa a un desarrollador entender el producto y el negocio, si su trabajo es programar?

Tu turno#

El ejercicio te pone en el sitio donde producto y desarrollo se tocan: escribir un OKR con key results que de verdad midan, elegir una métrica leading y una lagging, y cazar una vanity metric. Hazlo tú y compara con las soluciones, que suben de “tareas con corbata” a un OKR que guía decisiones.

Ejercicio · hazlo en local

Un OKR y sus métricas

El Team Builder tiene un problema: la gente entra, monta medio equipo y se va sin volver. Escribe un OKR del trimestre (objetivo + key results medibles) y, para la feature de filtros, elige una métrica leading y una lagging, más una vanity metric que descartarías. Las soluciones muestran tres niveles. Hazlo tú primero y compara.

Paso 1: Un OKR con la forma correcta

  • Escribes un objetivo y unos key results.
  • Eliges alguna métrica para la feature.

Cómo hacerlo en local

Clona el repositorio del curso, entra en la carpeta del ejercicio y abre el index.html en tu navegador. Toda tu solución va en solucion.js. 

git clone <repo>
cd exercises/nivel-12/entender-producto-y-negocio
# abre index.html en el navegador y edita solucion.js
Ver soluciones 
# OKR del trimestre

**Objetivo:** mejorar el Team Builder.

**Key results:**

- Lanzar el filtro por rol.
- Lanzar la búsqueda por nombre.
- Rediseñar la home.

## Métricas de la feature de filtros

- Mediremos el número total de usuarios registrados, que seguro que sube.

## Vanity metric

(No marco ninguna.)

Por qué este nivel

  • Tiene la forma de un OKR y eso ya es algo. Pero el objetivo es vago ("mejorar el Team Builder") y los key results son TAREAS (lanzar esto, rediseñar aquello): podrías cumplirlos todos y que nadie use más el producto. Y la métrica elegida —registrados totales— es una vanity metric que siempre sube.
  • La consecuencia: este OKR no sirve para decidir ni para saber si ganaste. Marcas tareas como hechas, el número de vanidad sube, y el problema real (la gente se va a medias) sigue igual mientras todo "va bien" en el informe. El tier "mejor" convierte las tareas en resultados.