Saltar al contenido

Elige qué categorías permites. Las necesarias no se pueden desactivar.

Emendu · SaaS B2B · IT Management

De vender a mano a un SaaS con canal propio

Rol
Product Manager
Periodo
- Actualidad
Sector
SaaS B2B · IT Management
Tamaño
De 8 a 16 personas
Reporting
Miembro del equipo de liderazgo

01 — En un minuto

01. Darle a un SaaS recién creado un modelo de negocio

  • Estrategia de producto end-to-end, empezando por el ICP. Lo redefiní con discovery fuera del pipeline comercial (empresas de 20 a 150 empleados sin IT interno) y reorienté con él el onboarding y los flujos clave: de 0 a más de 50 clientes de SaaS en el primer año.
  • De operativa manual a sistema digital y apificado. Sales, Accounts y Operaciones trabajaban fuera del software y la operativa apenas dejaba rastro: del 23% al 90% de trazabilidad del pipeline.
  • Partnership estratégico con Sesame HR, liderado junto al Tech Lead: integrar en un software de RRHH todo el flujo de renting y MDM. Fase 1 entregada en 7 semanas de producto, y un canal de adquisición nuevo para Emendu.
  • LISA, el agente de IA: de un sistema inconsistente a un agente funcional, con acceso dinámico a datos, documentación viva y capacidades multilingües.
  • Del SaaS de agencia externa a equipo técnico propio. La plataforma en Bubble había validado el modelo, pero frenaba justo las dos áreas de más valor. Empujé el cambio y participé en la incorporación del Tech Lead.
  • Como product builder, construí el hub de herramientas internas, desarrollado con Claude Code para reports, informes y propuestas: un 38% menos de tiempo de gestión operativa.

02 — La historia

02. Cómo hacer que el SaaS dejara de ser un añadido

La premisa que nadie había puesto en duda

Emendu vendía y operaba con solvencia haciendo las cosas a mano. Era una empresa sales-led con un SaaS encima, y el encargo no era gestionar un roadmap: era convertir un SaaS recién creado en el principal modelo de negocio de la compañía.

Debajo había una premisa que nadie había cuestionado: se daba por hecho que la cartera de clientes de renting era, uno a uno, la cartera del SaaS. Para comprobarlo acompañé al equipo comercial a más de 20 reuniones y entrevisté a 10 empresas que no estaban en el pipeline. La premisa se reveló incierta, y eso explicaba la poca aceptación entre esos usuarios: usaban la beta, pero no daban el paso a cliente de pago.

El hallazgo partía el mercado en dos. Las empresas con IT interno ya tenían cubierto casi todo lo que ofrecíamos. En las que no lo tenían, el trabajo de IT caía en RRHH, en la office manager, en el CEO o «en quien tocara». De ahí salió el ICP (empresas de 20 a 150 empleados sin IT interno, con al menos uno de tres dolores: gestión de dispositivos, soporte remoto y falta de criterio técnico para decidir) y con él el roadmap entero de 2025: evolucionar el SaaS hacia esos dolores, poner foco en soporte remoto, reorientar LISA y reescribir el lenguaje del producto para quien de verdad lo iba a usar.

El techo de la plataforma

Lo que no quedaba validado era con qué estaba construido. La plataforma la había hecho una agencia externa sobre Bubble, y fue la decisión correcta para validar. Pero no aguantaba el ritmo de desarrollo ni el peso técnico de lo que venía (LISA y el MDM, las dos áreas de más valor) y arrastraba tres deudas: sin trazabilidad (solo el 23% de las operaciones quedaba registrado en algún sistema; el resto vivía en emails y llamadas, y ni siquiera existía como dato), modelo conserje (dar de alta un dispositivo se resolvía a mano) y datos fragmentados, sin repositorio con el que alimentar automatismos ni al agente.

Por eso empujé el paso a equipo técnico propio. La incorporación del Tech Lead confirmó las necesidades que ya teníamos detectadas y añadió lo que yo no podía poner: un roadmap técnico con orden y fechas.

Cuando el desarrollo es el recurso escaso, lo construyo yo

Con el equipo técnico centrado en las bases y la agencia bajando volumen, lo que pedían los stakeholders internos no tenía por dónde salir. En vez de ponerlo en una cola, lo construí con Claude Code: una calculadora financiera de renting y un sistema de propuestas integrado con HubSpot para Sales, generación de reports desde el MDM para los Account Managers, y un sistema de diseño de presentaciones para toda la empresa. No para mí: cada pieza tiene su equipo.

Es también donde la IA dejó de ser una herramienta de consulta. Analizar entrevistas con IA me dejó revisar no solo al usuario, sino a mí mismo como entrevistador; v0 puso prototipos funcionales en manos de clientes en el tiempo que antes costaba describirlos.

De eficiencia a canal

Con el roadmap técnico sobre la mesa apareció Sesame HR, y cambió la naturaleza del proyecto. Hasta ese momento, digitalizar la operación era eficiencia: ordenar por dentro, quitar trabajo manual, poder medir. Un proyecto así tiene un techo conocido.

Un partnership lo cambia de raíz. Cuando un tercero va a consumir tu operación desde su propio producto, esa operación deja de poder ser «nuestros procesos, ahora documentados» y tiene que ser una interfaz: contratos de datos, estados explícitos y un comportamiento que no dependa de que alguien de Operaciones sepa lo que hay que hacer. Lo mismo que iba a hacer a Emendu más eficiente por dentro se convierte, por fuera, en un canal de adquisición.

Hoy la fase 2 (el MDM) está en desarrollo y la apificación avanza módulo a módulo: cada integración que entra retira una intervención manual. Lo siguiente es replicar el modelo con otros sectores, para que los partnerships sean un canal y no un acuerdo aislado.

03 — El caso

03. El partnership con Sesame HR

Sesame HR es uno de los mayores actores de software de RRHH en España, y la propuesta tenía doble sentido: sus clientes podrían pedir y gestionar el equipo de un empleado nuevo desde el mismo sitio donde ya lo dan de alta; nosotros ganaríamos un canal B2B dentro del flujo de trabajo nativo del cliente. El objetivo operativo no cambió: cambió la arquitectura, el resultado fue un éxito y el proceso ahora te lo cuento.

Discovery en tres frentes, para digitalizar sin parar la operación en marcha. Dentro: entrevistas con Operaciones, Ventas y Account Managers para mapear cada tarea manual. Fuera: el mapa de dependencias del que cuelga una operación de renting: entidades financieras, proveedores de hardware, verificación de identidad, aseguradoras, firma digital. Y Sesame: sus flujos y el enfoque con el que querían ofrecer el servicio.

La decisión técnica fue una transición, no una reescritura. Un backoffice único detrás de una API, alimentado en primera fase por el equipo interno (human in the loop) para que la trazabilidad no esperase a las integraciones; ese backoffice como cerebro y fuente de datos de LISA; y apificación progresiva, cada herramienta externa retirando una intervención manual. Para llegar al plazo del partner acoté el alcance: fase 1, renting de punta a punta; el MDM, a fase 2.

Los artefactos. Un product spec con funcionalidades, contratos de datos y subprocesos; diagramas de flujo como código con sus estados y transiciones (el equipo de desarrollo acababa de incorporarse, y un diagrama de estados no deja sitio a la interpretación donde una lista de requisitos sí); y un prototipo HTML navegable, en baja fidelidad y sin UI, que fue el único lenguaje común de cuatro interlocutores a la vez: técnico, Operaciones y Ventas, Sesame y producto.

El módulo MDM, como máquina de estados

Mapa de estados del módulo MDM en cuatro bloques. Activación (flujo 0): desde el módulo de renting activo, el superadmin entra en la sección MDM, ve los dispositivos activables y confirma, lo que deja el MDM activo; si cancela, vuelve a la sección. Con el MDM activo se abren tres superficies en paralelo: el módulo MDM del parque, con dashboard consolidado, catálogo y paquetes (flujo 4), políticas de empresa y equipo (flujo 5), equipos como fuente única que consume Renting (flujo 7) y la pestaña de configuración; el inventario y su pestaña MDM, con datos administrativos, gestión del dispositivo y línea de tiempo; y el enrollment (flujo 1), donde los ordenadores quedan pendientes de instalación y pasan a activos cuando el empleado instala el agente, a desconectados si el agente pierde conexión, y de vuelta a pendientes si se desinstala por una baja; los smartphones, tablets y accesorios quedan como no elegibles. Por último, la cancelación (flujo 6): el superadmin la programa, puede reactivar antes del fin de periodo, y al terminar se cursa la baja en el proveedor MDM y el módulo queda cancelado.

El flujo principal: todo el proceso en una sola vista. El equipo de desarrollo, recién incorporado, lo usó como contrato, con siete flujos numerados, sus estados y los saltos entre ellos; cada uno tenía además su propio diagrama con el detalle de su fase. Una lista de requisitos deja sitio a la interpretación; un diagrama de estados no, y de paso ubica al lector dentro del documento.

Resultados

  • 23% → 90%

    de trazabilidad del pipeline, 67 puntos porcentuales más de operaciones con rastro en sistema

  • −24%

    de tiempo manual en los equipos internos

  • 31%

    de los procesos automatizados de punta a punta, con la apificación aún en curso

Fase 1 entregada en 7 semanas de producto, con entregas semanales; el desarrollo posterior ya está en producción. Fase 2, 5 semanas de producto, hoy en desarrollo. El sistema de documentación, el prototipo y la lógica de negocio quedaron validados por el partner en la primera entrega.

Y un resultado que no es una cifra: los cambios de proceso dejaron de diseñarse alrededor de lo que cada área hacía a mano y pasan a diseñarse desde el backoffice.

04 — Aprendizajes

04. Cuatro aprendizajes, y el más caro fue una premisa

  1. Lo más caro del primer año no fue construir nada: fue una premisa que nadie había puesto en duda. Dar por hecho a quién sirves cuesta más que cualquier funcionalidad mal priorizada, porque no se ve hasta que miras fuera de tu propio pipeline.
  2. Un prototipo navegable alinea mejor que una especificación larga. Con un partner externo y un equipo técnico recién incorporado, un HTML de baja fidelidad hizo en días lo que un documento no habría hecho en semanas.
  3. Digitalizar un proceso es cambiar quién manda. No es escribir código: es que la operación se adapte al sistema, en vez de que el sistema documente la operación.
  4. La IA dejó de ser una herramienta de consulta y pasó a ser parte del método. En las entrevistas, en los specs, en la priorización y en los prototipos. De ahí sale mi etapa como product builder.