Adopción de funcionalidad.

La adopción de una funcionalidad es la parte de tus usuarios activos que usa una función concreta del producto dentro de un periodo. Una división: los que la usan entre los que podrían usarla. Nada más.

Existe porque en toda empresa de producto hay dos listas y casi nunca coinciden. La primera es la de lo entregado: lo que salió del roadmap, lo que se anunció en la newsletter, lo que se enseña en las demos. Esa se la sabe todo el mundo. La segunda es la de lo que la gente abre de verdad, y esa no la ha mirado casi nadie. La adopción es lo que pone las dos listas una al lado de la otra.

Es la activación aplicada a un objeto más estrecho. La activación pregunta si un usuario nuevo llega al punto en el que el producto le sirve para algo —su momento aha—. La adopción hace la misma pregunta con la lupa puesta encima de una sola función: de la gente que ya está dentro y ya usa el producto, ¿cuántos han tocado esta?

El malentendido que resuelve es corto de enunciar y caro de tener: lanzada no es adoptada. Una funcionalidad entregada existe en el changelog el día que se publica. Solo existe en la cuenta de adopción el día que alguien la abre. Y hay una pregunta que un director de producto debería tener contestada y casi nunca tiene: qué funcionalidades no se utilizan nunca. Duele, porque cada una costó semanas de equipo, pero mantenerlas vivas es un despilfarro de recursos que nunca sobran: soporte, documentación, pruebas y deuda técnica todos los meses.

En el ejemplo de arriba, sobre 6.000 usuarios activos, la función más usada llega al 62% y la última al 2%. Las seis salieron del mismo equipo y ocupan el mismo sitio en el menú. Sin este número, las seis pesan lo mismo en la reunión del lunes.

Arriba van usuarios, no usos. Usuarios distintos que dispararon el evento de esa función al menos una vez en el periodo. Si cuentas usos, la adopción sube cada vez que alguien se atasca y repite la misma acción cuatro veces, que es justo lo contrario de lo que quieres medir.

Y arriba va un evento de producto, no una visita. Esto no se mide con analítica web: la analítica web te dice qué páginas visitó alguien antes de registrarse, y la adopción vive dentro de la aplicación, donde no hay páginas sino acciones. Si el evento no está instrumentado, el número no existe; lo que existe es una estimación de alguien de producto.

Abajo hay tres candidatos, y no es un detalle: cambian el resultado por un factor de catorce con el mismo hecho debajo.

Los mismos 1.200 usuarios son un 2,9% sobre los 42.000 registrados acumulados, un 20,0% sobre los 6.000 activos del mes y un 40,0% sobre los 3.000 que tienen la función desbloqueada en su plan. El primero no vale para nada: los registrados acumulados desde el lanzamiento son una métrica de vanidad de manual, solo suman, nunca restan y no dirigen ninguna decisión. El tercero es el honesto, porque nadie puede adoptar una función que no tiene. El del medio es el que sirve para comparar funciones entre sí dentro del mismo producto.

La regla práctica: elige el denominador más estrecho que sea honesto y publícalo siempre pegado al número. Un 40% sin denominador al lado no es un dato, es una frase.

Queda el periodo, que es donde se cuela el otro error. Se mide por cohortes mensuales, no en acumulado desde el día uno. Un acumulado solo puede subir: en cuanto un usuario abre la función una vez, ya cuenta para siempre, y una función que nadie ha tocado en ocho meses seguirá enseñando el mismo porcentaje que el mes que se lanzó.

Y con eso tienes la mitad. La adopción es amplitud: cuántos la han tocado. La otra mitad es la profundidad: de esos, cuántos vuelven al mes siguiente y cuántas veces la usan. Son dos números y hacen falta los dos, porque el primero solo no distingue una función imprescindible de una que se prueba una vez por curiosidad.

Cada cuadrante lleva una acción distinta, y las cuatro son concretas. Arriba a la derecha están tus acciones CORE: mucha gente y repite. Eso no se toca en un rediseño sin medir antes y después, porque es lo que sostiene el producto aunque no sea lo que más ilusión hace enseñar.

Abajo a la derecha está lo que más engaña: mucha adopción y nadie vuelve. Ahí el problema no es de descubrimiento, la gente la encuentra perfectamente. El problema es la función, o la promesa con la que la vendes dentro del producto. Ese cuadrante es el que más se confunde con un éxito en la presentación trimestral.

Arriba a la izquierda está la buena noticia barata: poca gente la encuentra y la que la encuentra repite. Eso no se rehace, se enseña. Un aviso dentro del producto en el momento en que hace falta, un correo a la cohorte que tiene el problema que resuelve, un paso del onboarding que apunta a una sola acción y no un recorrido turístico por todo el menú.

Y abajo a la izquierda está la decisión que nadie toma: matarla. Una función sin amplitud y sin profundidad se retira, y el trabajo que ahorras se va al cuadrante de arriba. Lo que hay que exigir cada trimestre no es un informe de uso, es esto: el porcentaje de funcionalidades que no usa nadie, revisado, y una decisión tomada sobre cada una — matarla o promocionarla. Sin decisión, la lista solo crece.

Una advertencia antes de montar tableros: esto pide volumen. Para sacar conclusiones fiables de lo que pasa dentro del producto hacen falta del orden de 10.000 usuarios al mes pasando por el registro. Por debajo de esa cifra no fuerces la analítica —los porcentajes bailan con cuatro personas— y haz lo otro: siéntate a gente delante del producto o grábala usándolo. Vale más lo que ves que lo que crees que ves. Con esos volúmenes, cualquier movimiento se valida con un experimento antes de darlo por bueno.