Construcción de Producto para Startups

A veces estas empresas tienen el equipo de Marketing, o trabajan ya con un estudio de diseño para la imagen corporativa y UX/UI, o incluso tienen parte del equipo de desarrollo internamente pero necesitan cierta especialización que no tienen in-house. En ese punto entramos nosotros. Tenemos el know-how técnico y la experiencia en Symfony para convertir esas ideas en una primera versión robusta, que permita validar la propuesta en el mercado rápidamente y presentarse a nuevas rondas de financiación si fuera necesario.

Cualquiera que haya intentado montar un equipo de desarrollo, y más en los últimos tiempos, con la escasez que hay de especialistas en todos los niveles, sabe que puede ser un camino largo y lleno de pruebas y errores, especialmente para startups en sus etapas tempranas. No solo encontrar las personas adecuadas, luego formarlas en la visión de la empresa e integrarlas con el resto de equipos. Es una inversión de tiempo y recursos que muchas veces no se pueden permitir muchas empresas en una fase inicial.

Antes de ponernos a picar, que nosotros venimos de lo técnico y tradicionalmente siempre hemos tenido una orientación a eso, a remangarnos y ponernos a picar, conviene parar y analizar brevemente si este producto queremos o no hacerlo y si tenemos los recursos para ello. No me refiero en esto a Softspring, a nosotros, si no al propio cliente, quizá la conclusión sea que sí que quiere hacerlo pero nosotros no somos el partner adecuado, y eso descubrirlo cuanto antes es bueno para ambas partes.

En el libro Let's get Real or Let's not Play: Transforming the Buyer/Seller Relationship (enlace en Goodreads) se menciona una metodología, ORDER, en la que las tres primeras letras serían Oportunidad, Recursos y Decisiones, que resultan muy interesantes de cara a plantearnos esto que mencionaba en el anterior párrafo.

En el caso de la Oportunidad, qué estamos intentando resolver, cuál es el problema, por qué no se está resolviendo ya antes, por qué no lo ha resuelto antes la empresa (falta de equipo, etc, pero aclararlo), cómo medimos el éxito de la solución, si llegamos a ella.

Para los Recursos, qué gente, a qué nivel, va a participar por parte del cliente, cuándo esperan los resultados, van a poder implicarse en el proyecto en la medida y forma necesaria, van a facilitarnos a Softspring en este caso, el acceso a las personas adecuadas, cuánto dinero quieren invertir en la solución, esperas un coste fijo, inicial, de una cantidad, o ¿está preparada la empresa para asumir cierto gasto mensual en tecnología?.

En las Decisiones, cuando estemos hablando de distintas soluciones para el problema, en los detalles, quién tomará las decisiones, cómo van a tomarse, con qué ritmo y proceso, ¿tendremos acceso a esas personas que tomarán las decisiones?

Una vez entendidas las necesidades del cliente, los recursos disponibles y el proceso de toma de decisiones, el siguiente paso es modelar la solución. Esto significa transformar todo ese conocimiento en un plan de acción concreto. Aquí te detallo cómo abordaríamos esta fase:

Basándonos en la oportunidad identificada, vamos a detallar qué hará y qué no hará el producto. Aquí en este caso, en fases iniciales, salvo con dinero infinito y recursos temporales también infinitos, hoy en día es mucho más importante decidir lo que no se hará que decidir lo que se hará.

Suele hablarse, para esto, de MVP, Minimo Producto Viable (de las siglas inglesas Minimum Viable Product), y se ha escrito mucho sobre el tema, pero nosotros aquí queremos captar el producto final, la solución al problema real que se ha percibido por parte del cliente, y definir la mínima aproximación que podría ser una solución a dicho problema.

Vale, y cómo definimos entonces una versión mínima de producto pero que se asemeje al producto completo, esa porción de pizza de la que hablábamos (tanto hablar de pizza me está entrando hambre).

Hagamos lo que hagamos, hoy en día, podemos estructurar nuestra solución en partes, componentes, trozos que hablarán entre sí o con otras partes externas o sistemas de otros. Hoy en día es muy habitual que esto ocurra a través de API's y por eso hay tanto desarrollo de API's.

Este trabajo de pensar en nuestra solución como partes que se hablan, componentes, nos va a permitir, en función de los recursos que tengamos, decidir qué cosas no haremos, para qué cosas utilizaremos un componente externo ya existente y qué otras cosas haremos nosotros a medida. No solo eso, en muchos casos puede que ya de antemano tuviéramos claro que nuestra solución tendrá que conectarse con muchos elementos externos (por ejemplo queremos usar una solución de pagos de Stripe y/o enviar correos con Sendgrid); pensar en nuestra solución como un conjunto de componentes conectados nos facilitará esto último.

Hago un inciso aquí para decir que dividir en componentes no implica hacerlo todo con microservicios (tenemos un artículo sobre el tema), podemos tener muchos de nuestros componentes en un mismo monolito. Esto es más una separación funcional que tecnológica, ya pensaremos un poco más adelante cómo resolverlo todo.

Al descomponer el MVP en distintos módulos, podemos iterar rápidamente, realizar pruebas y ajustes sobre la marcha, y garantizar que cada parte del sistema se comunica eficazmente con las demás. Ya sea que estemos integrando un sistema de gestión de bases de datos, aprovechando una plataforma de análisis de datos de terceros, o enlazando con otros servicios digitales, nuestro objetivo es siempre el mismo: construir soluciones cohesivas, robustas y escalables que respondan no solo a las necesidades actuales del producto, sino que también estén preparadas para el futuro.

En este enfoque de trocear y buscar qué componentes hacer y cuáles no, podemos llegar en algunos casos a ver que hace falta un determinado componente, que no tenemos en este momento, que igual en un momento dado podríamos desarrollar nosotros, pero que igual de forma temporal o en un proceso de validación, podemos conectar con un sistema externo que luego migraremos.

Aunque determinadas migraciones son costosas, a veces ese coste extra merece la pena para centrarse antes en otras partes de la solución, más valiosas, llegar antes a una validación y saber antes si nuestra solución encaja en el mercado.

Hay muchos productos externos, soluciones, con las que podemos conectar para ampliar y complementar nuestro producto. En futuros artículos haremos una lista de los mismos, pero por ejemplo Airtable, Notion, o facilitar API's con las que poder conectar desde Make (antiguo Integromat).

Tras identificar la solución, el siguiente paso es desglosarla en un roadmap realista y alcanzable, decidiendo qué partes se harán primero, qué partes como hemos dicho se usarán sistemas externos ya existentes y qué partes no se harán en un primer momento y se harán más adelante.

No se trata solo de lanzar un MVP y ya está; es un proceso continuo de crecimiento y adaptación. Nos centramos en planificar no solo lo que se va a hacer a corto plazo, sino también en anticipar y preparar las siguientes etapas de desarrollo, siempre alineados con la visión y capacidad de la startup.

En Softspring, la comunicación no es un mero trámite, es una parte integral de cómo trabajamos. Nos sumergimos en tu proyecto, entendiendo tus necesidades y adaptándonos a ellas. Esta colaboración estrecha asegura que estemos siempre en la misma página y que podamos ajustar nuestras estrategias y acciones de manera ágil y efectiva.

Para esto es importante, si queremos que el producto vaya a buen puerto, tener acceso a las personas que podrán tomar las decisiones, como decíamos en la metodología ORDER anteriormente.

En Softspring, adoptamos un enfoque de entrega continua para garantizar que aportamos valor a tu proyecto en cada etapa. Nos basamos en metodologías ágiles y ciclos de desarrollo iterativos, lo que significa que tu producto no solo llega al mercado más rápido, sino que también evoluciona constantemente en respuesta al feedback real de los usuarios.

Esta metodología nos permite realizar ajustes y mejoras de manera regular, asegurando que el producto no solo cumpla, sino que supere las expectativas del mercado y las necesidades cambiantes de tu startup. La retroalimentación continua es clave en este proceso: nos permite afinar y perfeccionar la solución, asegurando que cada iteración aporte un valor significativo y tangible a tu negocio.