Cómo construir un roadmap desde cero (y no morir en el intento)

Hace menos de un año nos aventuramos a crear una empresa de producto SaaS (Software as a Service). Teníamos una hipótesis sobre un pain muy claro a resolver: las finanzas para CEOs de agencias y consultoras digitales.

Y precisamente en ese contraste es donde surge la verdadera necesidad: mientras los recursos financieros internos están al alcance de unos pocos, la gran mayoría empieza con una mochila llena de incertidumbre.

¿Son valientes o suicidas?

Hay quien dirá que claramente lo segundo, sobre todo porque hacer crecer una empresa incrementa tu riesgo y tu responsabilidad a partes iguales.

Por eso, en cierto punto, tener un buen asesoramiento financiero es vital. Pero surge la duda: si todavía somos demasiado pequeños, ¿cómo lo pagamos? El asesoramiento financiero in-house supone un alto coste y, en muchos casos, el externo también resulta prohibitivo.

Con esta hipótesis surge Sherpa Platform: con el objetivo de poder ayudar a CEOs de agencias, estudios y consultoras digitales a hacer crecer sus negocios reduciendo su riesgo. Queríamos que fueran vistos principalmente como valientes, y no como suicidas.

Y todo esto sonaba muy bien, pero… ¿Por dónde empezamos?

Antes de escribir una sola línea de código, sabíamos que teníamos que validar nuestra idea con quienes iban a ser nuestros futuros usuarios. Teníamos la experiencia, intuición y conocimiento de negocio, pero eso no era suficiente. Para construir algo valioso, necesitábamos conocer de primera mano las verdaderas necesidades de nuestros posibles clientes.

Por eso, realizamos un proceso estructurado de entrevistas en profundidad con CEOs y fundadores de agencias. Nuestra intención era:

• Entender sus retos financieros.
• Su relación con la tecnología.
• Cómo toman decisiones en su día a día.

Si te interesa saber en detalle cómo llevamos a cabo este proceso de entrevistas —desde cómo conseguimos a los entrevistados, hasta el guión y las herramientas que usamos— lo contamos de forma más extensa en este post, donde también podrás descargarte el modelo de entrevistas que utilizamos.

Este proceso nos permitió afinar el enfoque, detectar patrones comunes de pain y decidir con mayor seguridad los primeros pasos del producto. Las conclusiones y decisiones más destacables fueron:

• Nuestros posibles clientes, en la mayoría de los casos, tenían escasos conocimientos financieros. Por eso, además de adaptar nuestro lenguaje y cuidar la UX/UI al extremo, teníamos que mentorizar y formar en finanzas a nuestros futuros usuarios.
• Poner el foco en un nicho de mercado —agencias y consultoras digitales— nos facilitaría la implementación de la plataforma SaaS. Además, este nicho tenía un ecosistema de herramientas muy parecido, lo que también simplificaba las integraciones.
• Había muchos pains entre nuestros posibles clientes, pero identificamos cuatro muy claros y comunes entre ellos, que se podían abordar relativamente con facilidad. A partir de ellos, elaboramos una primera lista de Jobs to Be Done.

Con los Jobs to Be Done definidos y validados, tocaba construir. Al hacer una lluvia de ideas inicial, surgió una lista larguísima de funcionalidades típicas de cualquier plataforma:

• Pantalla de signup o identificación
• Pantalla de configuración del perfil usuario
• Funcionalidad “Reset Password”
• Wizard para gestionar pagos y facturas
• Monitorización del uso de la plataforma
• Y un largo etcétera.

Pero al analizarlas con detenimiento, nos dimos cuenta de que muchas de ellas no aportaban valor inmediato ni nos acercaban al core de lo que queríamos entregar.

Tras priorizar, solo una funcionalidad destacaba por su impacto real: las integraciones con las herramientas donde ya viven los datos financieros de nuestros usuarios. Esa era la base para poder construir cualquier solución útil y empezar a recibir feedback real del mercado.

Así que descartamos el resto y nos enfocamos en conectar Sherpa con los bancos y ERPs que usaban nuestros primeros clientes.

Empezamos con GoCardLess para las integraciones bancarias, y con Holded, el ERP más común en nuestro nicho.

La pantalla de login también la hicimos 😉 , pero lo importante era empezar a aportar valor lo antes posible, y lo hicimos por donde más importaba: los datos.

Nos llevó solo 3 meses resolver los primeros 4 Jobs to Be Done, pero durante todo ese periodo intentamos estar el mayor tiempo posible con nuestros clientes, escuchando qué nos decían, cómo veían las nuevas funcionalidades que desplegábamos y las nuevas necesidades que se les ocurrían.

• Creamos un canal de WhatsApp Business para que nos pudieran contactar fácilmente, aceptando mensajes de texto, audio y vídeo.
• Manteníamos el email como canal más formal para aquellos que lo preferían.
• Usamos formularios con Google Forms para recoger feedback y puntuaciones del servicio.
• Mandábamos pequeños vídeos con Loom para mostrar funcionalidades y obtener respuestas rápidas.
• En reuniones 1:1 para revisar sus finanzas, también aprovechábamos para recopilar feedback sobre la herramienta.

Toda esta información la documentábamos meticulosamente, primero en Airtable y después en Hubspot, para que todo el equipo tuviera acceso y pudiera actuar en consecuencia.

• Elegir un nicho nos ayudó a centrar el lenguaje y las integraciones, pero dentro del nicho hay subsegmentos: CEOs que facturan 200K, 800K o 2M de euros tienen retos distintos. Así que nuestras funcionalidades debían priorizarse en función del subtarget que más se ajustara a nuestro mejor ICP.
• Algunos pains que en las entrevistas parecían importantes, luego no lo eran tanto en el uso real. Por eso, la validación de ideas no concluye hasta que las funcionalidades están en producción. Cuanto antes se lance algo al mercado, mejor.
• Aunque empezamos con un enfoque muy personalizado (inspirado en el modelo del Mago de Oz), notamos que los clientes valoraban más el servicio a medida que este se automatizaba y profesionalizaba como un verdadero SaaS.

Al cerrar el primer trimestre, descubrimos que casi todo lo que teníamos planeado para el segundo trimestre ya no era relevante. Las necesidades reales habían cambiado gracias al feedback continuo.

Desde el principio, habíamos anotado todo el feedback en Asana: ideas del equipo de ventas, de marketing, de producto, de atención al cliente. Cuando una idea resonaba mucho, la marcábamos.

En ese punto, era hora de hacer algo más con esa información. Aprovechamos una sesión de coaching con una Product Manager de una multinacional, quien nos presentó diferentes frameworks. Elegimos el Framework ICE.

Es una metodología para priorizar funcionalidades basándose en tres factores:

• Impact (I): El impacto potencial en clientes actuales y futuros.
• Confidence (C): Qué tan seguros estamos de que tendrá ese impacto.
• Ease (E): Qué tan fácil es implementarlo.

Multiplicando esos tres factores, obtienes una puntuación. Ordenas y priorizas.

Le puedes añadir algunas modificaciones o hacks para también adaptar esas funcionalidades a otros objetivos superiores de negocio 😅, pero eso lo dejamos para otro momento 😬.

Pasamos todas las propuestas de Asana a una hoja de cálculo de Google Sheet y empezamos a ejecutar el Framework ahí. Desde entonces, nuestro roadmap se nutre de él. Pero hay que tener en cuenta lo siguiente:

Re-evaluamos las funcionalidades cada dos semanas:

• • El impacto cambia, según el feedback que recibamos.
  • La confianza puede verse incrementada gracias a algún experimento que hayamos hecho.
  • Y la facilidad de ejecución también es variable: positiva si hemos realizado algo que ayude con otra funcionalidad o, negativa si el equipo técnico ha evaluado su desarrollo técnico con más cuidado y descubre algunos obstáculos.
• Producto y Negocio se reúnen el día después de la re-evaluación y añaden alguna variable más a la fórmula: así se elige el roadmap de las próximas semanas.
• Se van incluyendo funcionalidades o ideas diariamente, provenientes de usuarios o posibles clientes, con una evaluación inicial.

Para terminar, solemos seleccionar un conjunto de funcionalidades de todos los tamaños: pequeñas, medianas y grandes.

Nuestro objetivo es lanzar nuevas funcionalidades constantemente, recoger nuevo feedback y alimentar más la “maquinaria”.

Es cierto que con funcionalidades grandes los impactos pueden ser más grandes: pero los ciclos de feedback se alargan mucho más eso es un riesgo para una startup que necesita velocidad.

Construir un roadmap en una startup no es solo cuestión de intuición ni de inspiración. Es una disciplina. Y como cualquier disciplina, necesita datos, escucha activa, priorización consciente y adaptación constante.

En Sherpa, decidimos construir en público para compartir tanto los aciertos como las decisiones difíciles. Ojalá esta experiencia te ayude a dibujar tu propio mapa con más claridad, aunque la brújula siempre apunte al mismo norte: tus clientes.