Cómo auditar un producto SaaS en una semana

Casi todas las auditorías de producto que me han enseñado mis clientes tienen el mismo final: un PDF de sesenta páginas, muy bien maquetado, que nadie ejecutó. El diagnóstico solía ser correcto. El problema es que no era accionable, llegó tarde y no decía qué hacer el lunes siguiente.

Auditar un producto no es documentarlo, es decidir dónde intervenir primero. Y eso, en un SaaS B2B con dos o tres flujos críticos, cabe en una semana de trabajo enfocado. Este es el método que uso.

Qué es auditar un producto, y qué no

Una auditoría de producto responde a una pregunta muy concreta: ¿dónde está tu producto perdiendo valor y qué se arregla primero? Nada más.

No es un rediseño, ni un test de usabilidad, ni un informe exhaustivo de todo lo que se podría mejorar. Esa exhaustividad es justo lo que la vuelve inútil: cuando entregas cuarenta recomendaciones, el equipo no prioriza ninguna. Una auditoría que funciona termina con cinco acciones y un orden.

Tampoco es un juicio estético. En los productos que audito, la interfaz rara vez es el problema principal. El problema suele estar en decisiones anteriores: a quién dejas entrar, qué le pides antes de darle algo de valor y qué le prometiste al venderle.

Antes de mirar nada: la pregunta de negocio

El error de método más común es empezar abriendo el producto. Antes de eso hay que fijar la pregunta que la auditoría tiene que contestar, y tiene que ser una pregunta de negocio, no de producto.

“Se registran usuarios y no llegan a activarse” es una pregunta auditable. “Queremos mejorar la experiencia” no lo es.

Ejemplos de preguntas que sí acotan el trabajo:

• Entra tráfico cualificado y la activación se queda en el 20 %. ¿Dónde se pierde?
• Los clientes renuevan pero el uso semanal baja. ¿Qué dejó de aportar valor?
• Queremos meter IA en el producto este trimestre. ¿Dónde tiene sentido y dónde es ruido caro?
• El equipo de soporte repite las mismas veinte respuestas. ¿Qué falla en el producto que las provoca?

Con la pregunta fijada, el alcance se cierra solo: se revisan los flujos que la afectan y se dejan fuera los demás. Sin ella, la auditoría se expande hasta ocupar todo el tiempo disponible y no concluye nada.

Las cuatro capas que reviso, en este orden

El orden importa. Cada capa explica lo que ves en la siguiente, y saltarse las primeras es lo que produce auditorías que solo hablan de botones.

1. Negocio y métricas

A quién le vendes, cuánto cuesta traerlo, qué se supone que hace en su primera semana y cuál es la métrica que le importa al equipo directivo. Sin esto no hay forma de ordenar nada por impacto: cualquier mejora parece igual de urgente.

Aquí también pregunto por el precio y el modelo de contratación. Es habitual que la fricción que se ve en el producto sea en realidad una consecuencia del pricing o del proceso de venta.

2. Los datos que ya tienes

Nunca hacen falta datos perfectos, pero conviene mirar lo que hay antes de opinar: embudo por pasos si existe, retención por cohorte, eventos del primer día, tickets de soporte agrupados por tema. Los tickets son la fuente más subestimada de todas: son tu producto explicado con las palabras del usuario y sus problemas ya vienen ordenados por frecuencia.

Si no hay analítica, se audita igual y se sale con la lista de eventos que hay que instrumentar. Lo que no se puede es fingir certeza sobre magnitudes que nadie ha medido.

3. Los flujos críticos, recorridos como un usuario nuevo

Ahora sí, el producto. Se eligen dos o tres flujos según la pregunta inicial (registro y onboarding, la tarea central que se repite cada semana, el momento en que se invita al equipo, el reporting que justifica la renovación) y se recorren desde cero, con cuenta nueva y capturando cada paso.

En cada paso miro tres cosas:

1. Qué le pido al usuario y si tiene contexto para decidirlo en ese momento.
2. Qué recibe a cambio y cuánto tarda en recibirlo.
3. Qué pasa cuando algo va mal: estados vacíos, errores, esperas y casos límite. Es donde se cae la mayoría de productos y lo que casi ninguna demo interna enseña.

Esta capa es la que más se solapa con el trabajo de fricción del onboarding. Si tu pregunta es de activación, el método detallado está en cómo reducir la fricción en el onboarding de un SaaS B2B.

4. La distancia entre lo que prometes y lo que entregas

La última capa es comparar el mensaje de la web, el pitch de ventas y la demo con lo que el producto hace en los primeros dos minutos. Cuando hay hueco, el usuario no percibe una feature que falta: percibe que le engañaron, y ese daño no se arregla con un tooltip.

Cómo cabe todo esto en una semana

No cabe porque se trabaje más rápido, cabe porque el alcance está cerrado desde el primer día y las decisiones se toman por el camino en lugar de acumularse para el informe final.

• Día 1: contexto. Una sesión de 90 minutos con quien conoce el negocio, las métricas y el roadmap. Aquí se fija la pregunta y se eligen los flujos.
• Días 2 a 5: análisis. Recorrer los flujos, revisar los datos que haya, mapear la fricción y diseñar las oportunidades, incluidas las de IA.
• Día 6: entrega. El informe y el mapa de flujos anotado, ya priorizados.
• Día 7: cierre. Una sesión de 45 minutos para discutir, ajustar y salir con las acciones de los próximos 30 días.

El límite real de una auditoría casi nunca es analítico, es de coordinación. Si los accesos tardan tres días y la sesión de contexto se aplaza dos veces, la misma semana de trabajo se convierte en un mes de calendario.

El entregable no es un informe, es un plan

Un diagnóstico que no ordena no sirve. Todo lo que sale de la auditoría se entrega con tres datos por cada hallazgo:

• Qué está pasando y con qué evidencia lo sostengo (dato, ticket, paso concreto del flujo).
• Qué coste tiene para la métrica que elegimos el día 1.
• Qué cuesta arreglarlo, distinguiendo lo que es un cambio de copy o de orden de pasos de lo que es trabajo de ingeniería de semanas.

De ahí sale el orden. Las primeras acciones suelen ser vergonzosamente pequeñas: quitar dos campos, cambiar el momento de una decisión, reescribir un estado vacío. Eso es buena señal, no falta de ambición: si las mejoras de mayor impacto son también las más baratas, es que había fricción acumulada y no un problema de arquitectura.

Con las oportunidades de IA el criterio es el mismo, con una variable extra: el coste de operarlas. Lo desarrollo en cómo priorizar features de IA por impacto y esfuerzo.

Los errores que veo una y otra vez

• Auditar todo el producto. Sin pregunta que acote, el resultado es un inventario, no un diagnóstico.
• Empezar por la interfaz. Se llega a conclusiones cosméticas y el problema real, que casi siempre está en negocio o en expectativas, queda intacto.
• Confundir opinión con evidencia. Cada hallazgo necesita algo que lo sostenga: un dato, un ticket recurrente o un paso del flujo que cualquiera pueda reproducir.
• Entregar sin priorizar. Cuarenta recomendaciones equivalen a cero decisiones.
• Auditar sin nadie que ejecute. Si al cerrar no hay una persona con nombre y una fecha para cada acción, el informe ya está muerto.

Por dónde empezar

Resumido: fija una pregunta de negocio, revisa negocio, datos, flujos y promesa en ese orden, y entrega cinco acciones priorizadas en lugar de un inventario. Una semana de trabajo enfocado da mejor resultado que un mes sin alcance cerrado.

Este es exactamente el trabajo de la Product & AI Audit Express: en 7 días te devuelvo el diagnóstico de tus flujos críticos, las oportunidades de IA que sí aportan y las cinco acciones de los próximos 30 días. Y si prefieres hacer la primera pasada tú, el checklist de oportunidades de IA en producto usa este mismo criterio, flujo por flujo.