Pregunta → hallazgo → recomendación: el one-pager

Has pasado cuatro días con un análisis. Empezaste descomponiendo el embudo de conversión por canal, aislaste el problema en el tráfico orgánico móvil, descartaste tres hipótesis, encontraste que el tiempo de carga en iOS había subido un 62% desde el último despliegue, y calculaste que eso explica el 70% de la caída en registros de la última quincena. Tienes diecisiete consultas en tu notebook, ocho gráficos exploratorios, y una convicción sólida de qué ha pasado y qué hay que hacer. Ahora te toca presentarlo.

Abres un documento y empiezas a escribir. Contexto, metodología, fuentes consultadas, gráficos de cada paso intermedio, caveats estadísticos, nota al pie sobre la muestra… Cuando llevas por la sexta página te das cuenta de que la directora de producto no se va a leer esto. No porque sea vaga o no le importe: porque tiene ocho reuniones hoy, cuarenta y siete correos sin leer, y necesita tomar una decisión sobre este tema en los próximos treinta minutos. Si tu entregable exige veinte minutos de lectura atenta para llegar a la conclusión, tu conclusión no va a llegar. Se va a quedar enterrada en la página siete de un documento que nadie abrirá por segunda vez.

El one-pager existe para resolver exactamente este problema. Es un documento de una sola página — literal, una — que destila todo tu análisis en lo que un decisor necesita para actuar: qué pregunta se respondió, cuál es la respuesta, qué dato la respalda, y qué se recomienda hacer. No es un resumen ejecutivo pegado delante de un informe largo. Es el formato completo. La página ES la entrega. Todo lo demás — el notebook, las queries, los gráficos intermedios — existe como respaldo por si alguien quiere profundizar, pero no forma parte de lo que presentas.

### Por qué una página y no diez: la economía de la atención directiva

La historia más conocida sobre formatos de documento en empresas de datos es la de Amazon. En 2004, Jeff Bezos prohibió las presentaciones con diapositivas en las reuniones internas y las sustituyó por documentos narrativos de máximo seis páginas — los famosos six-pagers. La razón que dio no era estética: era que una diapositiva con cinco bullets esconde la complejidad del razonamiento. Obliga a simplificar tanto que los matices desaparecen, y quien presenta llena los huecos hablando, lo que hace que la calidad de la decisión dependa de quién esté en la sala, no de qué diga el documento.

El six-pager de Amazon funciona porque las reuniones de Amazon empiezan con veinte minutos de lectura en silencio. Es un contexto muy concreto: un grupo de personas sentadas en la misma sala, sin portátiles, leyendo el mismo documento durante un bloque de tiempo reservado para eso. Fuera de Amazon — en la mayoría de empresas del mundo real — eso no pasa. Lo que pasa es que mandas un documento por correo o por Slack y la persona lo abre entre reunión y reunión, con cinco minutos disponibles. Si el documento tiene seis páginas, lee el primer párrafo, hace scroll hasta el final buscando la conclusión, y si no la encuentra rápido, lo cierra y pasa al siguiente correo.

El one-pager nace de esa realidad. No es una versión reducida del six-pager: es otro formato para otro contexto. El six-pager es para decisiones complejas que requieren debate en grupo. El one-pager es para decisiones que una sola persona puede tomar si tiene la información correcta en el momento correcto. Y la mayoría de los análisis que un analista entrega en su día a día son del segundo tipo: "¿lanzo esta campaña o no?", "¿ampliamos el equipo de soporte o esperamos?", "¿qué canal recortamos si hay que reducir un 15% el presupuesto?".

Los datos sobre atención directiva son contundentes. Un estudio de Microsoft en 2015 estimó que la capacidad de atención promedio había bajado a ocho segundos — menos que un pez dorado, decían, aunque la metodología era cuestionable. Lo que sí es real y medible: en entornos corporativos, el tiempo medio que un ejecutivo dedica a un documento antes de decidir si lo lee completo o lo archiva es de unos treinta segundos. Es el equivalente del "above the fold" de un periódico: lo que no ves sin hacer scroll es lo que no existe para quien tiene prisa. El one-pager es un formato diseñado para ganar esos treinta segundos.

### La estructura del one-pager: cinco bloques, siempre en el mismo orden

Un one-pager no es texto libre comprimido en una página. Tiene una estructura fija, y esa estructura es deliberada: cada bloque responde a una pregunta que el lector se hace en un orden concreto. Si alteras el orden — si pones el contexto antes de la respuesta, o la recomendación antes del dato — el lector tiene que reordenar mentalmente la información, y eso le cuesta tiempo y atención que no tiene. La estructura del one-pager sigue el orden natural de la cabeza de un decisor: "¿de qué va esto?", "¿cuál es la respuesta?", "¿cómo de seguro estás?", "¿qué tengo que saber para no malinterpretar?", "¿qué hago con esto?".

1. 01.La pregunta que se responde. Una frase, máximo dos. No la pregunta técnica que tú investigaste ("¿qué correlación hay entre tiempo de carga y tasa de registro por canal y dispositivo?") sino la pregunta de negocio que alguien hizo ("¿por qué han caído los registros esta quincena?"). Si el lector no reconoce la pregunta como suya, no sigue leyendo.
2. 02.La respuesta en una frase. La conclusión directa, sin rodeos, sin "depende". "Los registros han caído porque el tiempo de carga en iOS subió un 62% tras el despliegue del 1 de julio". Si la respuesta real es "depende de tres factores", entonces tu one-pager no está listo: necesitas una hipótesis principal con las otras dos como matiz, no tres opciones sin jerarquía.
3. 03.El dato que la respalda (1-3 cifras clave). No quince métricas: una, dos, tres como máximo. Las que hacen que tu respuesta pase de ser una opinión a ser una evidencia. "Registros móvil iOS: −34%. Tiempo de carga: 2.1s → 3.4s (+62%). Correlación temporal: ambas métricas cambian el mismo día del deploy".
4. 04.El contexto mínimo. Qué período miras, qué segmento, qué fuente, qué no incluyes. "Período: 1-15 julio 2024. Solo tráfico orgánico — el de pago no muestra caída. Fuente: Google Analytics + logs de rendimiento del CDN. Excluye: Android, que se mantiene estable". Es lo justo para que el dato no se malinterprete, sin convertirse en un párrafo de caveats.
5. 05.La recomendación o siguiente paso. Qué propones que se haga con esta información. "Recomendación: revertir el despliegue, medir el impacto durante 48h, y programar un test de rendimiento antes de cada release en iOS". Sin recomendación, tu análisis es un informe que se archiva. Con recomendación, es una propuesta que se discute.

Fíjate en algo contraintuitivo de este orden: el contexto va DESPUÉS del dato, no antes. En un informe académico o en un paper científico, primero se describe el método y luego se dan los resultados. Pero un directivo no es un revisor de papers: es alguien que busca la respuesta y solo necesita el contexto si la respuesta le sorprende o le genera dudas. Si pones el contexto primero, lo leerá pensando "vale, vale, pero ¿cuál es el número?" y cuando llegue al número ya habrá olvidado el contexto. Si pones el número primero y el contexto después, lo leerá pensando "interesante, ¿de dónde sale esto?" — y entonces sí le importa el contexto.

### Qué NO incluir: el one-pager no es un cuaderno de laboratorio

La parte más difícil de escribir un one-pager no es llenar la página: es decidir qué dejas fuera. Después de cuatro días de trabajo, todo parece importante. Cada gráfico intermedio te costó esfuerzo. Cada hipótesis descartada te enseñó algo. Cada caveat estadístico es técnicamente relevante. Pero incluirlo todo es exactamente lo que convierte un one-pager en un informe de diez páginas con letra pequeña. La disciplina del one-pager es la disciplina de la exclusión: saber que algo es verdad y relevante, pero decidir conscientemente que no entra en esta página porque no ayuda a tomar la decisión.

Hay una analogía perfecta: la cocina de un restaurante con estrella Michelin. El chef prueba treinta combinaciones de sabores para llegar a un plato. Pero cuando lo sirve, no te pone las treinta en el plato "para que veas todo lo que probé". Te pone la que funciona. Las otras veintinueve existen — están en su cuaderno de desarrollo, en su memoria — pero no son el plato. Son el camino hacia el plato. Tu one-pager es el plato. Tu notebook es el cuaderno de desarrollo.

• ▹El cómo técnico. La query que escribiste, el JOIN que te costó dos horas, el pipeline de limpieza de datos, la librería que usaste para el gráfico. Al directivo no le importa si usaste un LEFT JOIN o un INNER JOIN. Le importa el número y si puede confiar en él.
• ▹La exploración. Los veinte gráficos que hiciste para entender los datos antes de encontrar el patrón. Esos gráficos te sirvieron a ti para pensar, no sirven al lector para decidir. Son andamios: se usan para construir y se retiran cuando el edificio está terminado.
• ▹Las caveats infinitas. "Hay que tener en cuenta que la muestra excluye a los usuarios que…", "cabe mencionar que el intervalo de confianza para el segmento de…", "existe la posibilidad marginal de que…". Cada caveat que añades diluye la conclusión principal. Si hay una limitación que cambia la interpretación del dato, va en el contexto mínimo. Si es una nota técnica que solo importa a otro analista, va en un apéndice que enlazas al final, no en el cuerpo.
• ▹Las alternativas descartadas. "También investigué la hipótesis del precio, pero el dato no la respalda". Eso es interesante para quien te pregunte, pero no para quien necesita decidir. Si solo una hipótesis ha sobrevivido, presénta esa. Las descartadas las guardas por si te preguntan — y si te preguntan, te harás el interesante un minuto y medio explicándolo de viva voz.

### Ejemplo concreto: el mismo análisis, dos formatos

Veamos un caso real simplificado. Situación: la empresa tiene un producto SaaS (software como servicio, es decir, que se paga una suscripción mensual). El churn — la gente que cancela su suscripción — ha subido del 4.2% al 5.8% en el último trimestre. La CEO quiere saber por qué y qué hacer. Tú has hecho el análisis. Has encontrado que el churn se concentra en usuarios del plan básico que llevan entre 3 y 6 meses, y que el detonante principal es que esos usuarios nunca adoptaron la funcionalidad de automatizaciones, que es lo que diferencia al producto de la competencia.

El informe largo de ese análisis tendría: dos páginas de contexto sobre la evolución histórica del churn, una página explicando la metodología de segmentación por cohortes (grupos de usuarios según su fecha de alta), tres páginas con gráficos de supervivencia por plan y antigüedad, una página de análisis de correlación entre uso de funcionalidades y retención, una página de limitaciones, y una página final con la conclusión y tres recomendaciones. Nueve páginas. Tiempo de lectura: quince minutos para quien ya conoce el producto, veinticinco para quien no.

El one-pager del mismo análisis:

1# Estructura del one-pager — ejemplo: churn Q3
2
3one_pager = {
4    "pregunta": (
5        "¿Por qué el churn ha subido del 4.2% al 5.8% este trimestre?"
6    ),
7    "respuesta": (
8        "El churn extra viene de usuarios del plan básico (3-6 meses) "
9        "que nunca adoptaron la funcionalidad de automatizaciones."
10    ),
11    "datos_clave": [
12        "Churn plan básico 3-6 meses: 11.3% (vs 4.1% del resto)",
13        "Adopción de automatizaciones en ese segmento: 8% (vs 67% general)",
14        "Usuarios que usan automatizaciones: churn 2.1% (independiente del plan)",
15    ],
16    "contexto": (
17        "Período: Q3 2024 (jul-sep). "
18        "Base: 12,400 suscriptores activos al inicio del trimestre. "
19        "Fuente: tabla fact_subscriptions + eventos de producto. "
20        "Excluye: plan enterprise (contrato anual, churn 0.3%)."
21    ),
22    "recomendacion": (
23        "Lanzar un programa de onboarding guiado de automatizaciones "
24        "en la semana 4 del usuario básico. Estimación: si la adopción "
25        "sube del 8% al 30%, el churn de este segmento baja a ~6%, "
26        "lo que devuelve el churn global al rango 4.0-4.5%."
27    ),
28}

### Los seis errores que convierten un one-pager en ruido

Después de revisar cientos de one-pagers — propios y ajenos — hay seis patrones que se repiten siempre que un one-pager falla. No son errores de redacción: son errores de pensamiento. Cada uno refleja una confusión sobre para quién es el documento y qué se espera de él.

1. 01.Demasiadas cifras. Si pones quince métricas, ninguna destaca. El ojo del lector las escanea todas, no retiene ninguna, y cierra el documento con la sensación de que "hay muchos números pero no sé cuál importa". La regla de tres: máximo tres cifras clave. Si necesitas más, es porque no has identificado cuál es la que realmente sostiene tu argumento.
2. 02.Sin recomendación. Un análisis sin recomendación es un informe que se archiva. El directivo lo lee, piensa "interesante", y no hace nada — porque no le has dicho qué hacer con la información. Tu trabajo no es solo encontrar la respuesta: es proponer la acción. Aunque la decisión final no sea tuya, la propuesta sí lo es.
3. 03.Demasiado técnico. "Hicimos un LEFT JOIN entre fact_sessions y dim_users filtrando por device_type = iOS y calculamos la media ponderada del page_load_time_ms". El directivo no necesita saber esto. Necesita saber que el tiempo de carga subió un 62% en iOS. El cómo lo calculaste es tu credibilidad profesional — se da por hecha, no se demuestra en cada frase.
4. 04.Conclusión ambigua. "Los datos sugieren que podría haber una relación entre el tiempo de carga y los registros, aunque hay otros factores que podrían estar influyendo". Eso no es una conclusión: es una abdicación. Si no estás seguro, di el nivel de confianza: "Con un 85% de certeza, la causa principal es X". Pero no te escondas detrás de condicionales para cubrirte las espaldas — eso no ayuda a nadie a decidir.
5. 05.Contexto antes de la respuesta. El "síndrome del novelista": tres párrafos de antecedentes antes de llegar al punto. El lector pierde la paciencia en el segundo párrafo y hace scroll hasta el final. Pon la respuesta primero, el contexto después. Si necesita el contexto para entender la respuesta, lo leerá — pero solo si ya sabe que merece la pena.
6. 06.Pedir "más análisis" como recomendación. "Recomendamos investigar más a fondo la correlación entre…". Eso no es una recomendación para un decisor: es un presupuesto para ti. El decisor necesita una acción de negocio, no una propuesta de trabajo analítico. Si genuinamente necesitas más datos para concluir, dilo, pero propón una acción interina: "Mientras se investiga X, recomendamos pausar Y como medida preventiva".

### El one-pager como herramienta de pensamiento, no solo de comunicación

Hay un beneficio del one-pager que nadie te cuenta cuando te lo enseñan como formato de entrega: es una herramienta de pensamiento. Obligarte a rellenar los cinco bloques antes de entregar te obliga a verificar que realmente tienes los cinco. Y muchas veces descubres que no los tienes todos.

Abres la plantilla. "Pregunta": vale, la tengo clara. "Respuesta": la tengo. "Dato clave": tengo seis, ¿cuáles son los tres que importan? Hmm, necesito pensarlo. "Contexto": ¿cuál es el período exacto? Espera, ¿es el trimestre completo o solo desde que cambió la política de precios? Déjame verificar. "Recomendación": ¿qué propongo? Ah, todavía no tengo una recomendación clara, solo tengo un diagnóstico. Necesito pensar qué acción tiene sentido antes de presentar esto.

Ese momento — el de darte cuenta de que te falta una pieza — es el valor oculto del one-pager. Sin la estructura, habrías entregado un informe largo donde la ausencia de recomendación queda disimulada entre páginas de gráficos. Con la estructura, la ausencia es obvia: el bloque cinco está vacío. No puedes disimularlo. Y eso te empuja a completar el razonamiento antes de entregar, no después.

### Cuándo NO usar un one-pager

El one-pager no es el formato universal para todo análisis. Hay tres situaciones en las que una sola página no basta y forzarlo haría más mal que bien:

• ▹Decisiones con múltiples opciones legítimas. Si la respuesta no es "haz X" sino "puedes hacer A, B o C, y cada una tiene estos trade-offs", una página no da para presentar las tres opciones con la honestidad que merecen. Ahí necesitas un documento de opciones (a veces llamado decision doc) donde cada alternativa tiene espacio para respirar.
• ▹Análisis para otro equipo técnico. Si tu audiencia es el equipo de ingeniería de datos y necesitan saber exactamente qué tablas tocaste, qué filtros aplicaste y cómo replicar tu trabajo, el one-pager se queda corto. Necesitan el cuaderno completo. No los obligues a pedir "la versión larga" de algo que podrías haberles mandado directamente.
• ▹Regulación y auditoría. Si el análisis tiene implicaciones legales o regulatorias, la trazabilidad completa importa: quién hizo qué, con qué datos, qué supuestos se tomaron. Un auditor no quiere un one-pager: quiere el rastro completo. Aquí la documentación exhaustiva no es burocracia: es protección.

La regla de cuándo usar un one-pager es sencilla: cuando tu audiencia es una persona (o un grupo reducido) que necesita tomar UNA decisión, y tu análisis apunta a UNA dirección clara. Si hay múltiples decisiones, múltiples audiencias, o múltiples direcciones igualmente válidas, necesitas un formato más largo. Pero en la práctica del analista junior y mid, la mayoría de las entregas caben en un one-pager. El resto se nota: sabes que no cabe porque te frustras intentando comprimir.

### La versión digital: el one-pager como correo, como Slack, como slide

Un one-pager no tiene que ser literalmente un documento con formato. En muchos equipos, la entrega natural de un análisis no es un PDF ni un Google Doc: es un correo electrónico, un mensaje de Slack, o una slide en la reunión semanal. La estructura del one-pager funciona en todos estos formatos porque es una estructura de pensamiento, no una plantilla visual.

Un correo electrónico que sigue la estructura del one-pager se lee en un minuto y genera acción. Asunto: "Análisis churn Q3: causa identificada + recomendación". Primera línea: la pregunta y la respuesta. Segundo párrafo: las tres cifras clave. Tercer párrafo: el contexto y la recomendación. Un enlace al final: "Notebook completo aquí por si quieres profundizar". Ese correo se lee, se entiende, y se responde con "vale, hazlo" o "tengo una duda sobre X". El informe de diez páginas adjunto se descarga, se guarda en una carpeta, y se olvida.

### Resumen: el checklist antes de enviar

Antes de dar al botón de enviar, pasa tu one-pager por estas cinco preguntas. Si respondes "no" a cualquiera, no está listo:

1. 01.¿La pregunta está formulada en lenguaje de negocio, no en lenguaje técnico?
2. 02.¿La respuesta cabe en una frase y no es ambigua?
3. 03.¿Las cifras clave son tres o menos, y cada una sostiene el argumento?
4. 04.¿El contexto dice lo justo para no malinterpretar, sin convertirse en un párrafo de caveats?
5. 05.¿La recomendación es una acción de negocio concreta, no "seguir investigando"?