principales errores al construir producto en una empresa

Este escrito es el resultado de 10 años construyendo experiencias digitales y tres creando productos para startups, pymes y corporativos con un equipo de profesionales en Acueducto.

Está dirigido a cualquier persona que trabaje en una escuadra de producto o a cualquier líder en una empresa que esté considerando resolver retos de negocio mediante software.

La creencia general que se tiene al desarrollar una web app, un ecommerce o cualquier tipo de interfaz digital, suele dejar fuera consideraciones que el paso del tiempo me ha permitido identificar como patrones. Y aunque hay información allí afuera sobre cómo abordar el desarrollo de producto en una empresa; esta es una guía destilada y puntual respaldada por experiencia adquirida en el primer frente de batalla: construyendo software junto a emprendedores y líderes de negocio del mundo.

Hablando de desconsideraciones o ideas erróneas: una de las principales razones que frenan la innovación al desarrollar producto es contar con un roadmap con una lista priorizada de funcionalidades y proyectos; más que una lista de retos de negocio a taclear. Esto convierte la dinámica de desarrollo en una donde la administración ejecutiva demanda una serie de requerimientos dejando fuera el intelecto e ideas de diseñadores, desarrolladores y product managers.

Las escuadras de producto que generan más valor y altos grados de innovación a una compañía piensan, prueban y desarrollan sus propias soluciones con feedback del nivel ejecutivo y todos los stakeholders involucrados en el proyecto, sin embargo, no reciben órdenes jerárquicas. Son lanzados al ruedo confiando en su criterio para entregar soluciones que, más que ser funcionalidades específicas, resuelven desafíos de negocio.

En este escrito aprenderás que es posible crear un producto exitoso dentro de una empresa sin drenar los recursos de la misma con el equipo indicado y la correcta forma de trabajar.

“We need teams of missionaries, not teams of mercenaries. Mercenaries build whatever they’re told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers.” – Marty Cagan, Inspired (2018)

1. Escribir código antes de minimizar los riesgos más comunes en un producto

Al desarrollar producto nos encontramos con cuatro riesgos que suelen causar que un proyecto falle. Estos son:

1. Riesgos de valor: ¿los clientes usarán esto?, ¿cambiarán su herramienta actual por esta alternativa?, ¿cuánto están dispuestos a pagar por la solución?
2. Riesgos de usabilidad: ¿pueden descifrar fácilmente los usuarios cómo usar esta interfaz?, ¿esta te hace pensar el mínimo?, ¿indica siempre naturalmente cuál es el siguiente paso a dar?, ¿entrega resultados lo más rápido posible?
3. Riesgos técnicos: ¿nuestro equipo es capaz, a nivel técnico, de construir esta solución?
4. Riesgos de viabilidad de negocio: ¿la solución funciona para el negocio como existe actualmente?, ¿se están considerando todas las piezas que toca el software en la compañía?

La idea es resolver todas estas preguntas tan rápido y barato como sea posible.

2. Abarcar muchas cosas al principio

Los mejores productos hacen muy bien una sola cosa. Sin embargo, el llamado a la innovación demanda siempre mejorar y crear valor consistentemente para los clientes y el negocio.

Se vuelve entonces un estire y afloje donde, por una parte, cada funcionalidad nueva agrega una capa de complejidad que aumenta el riesgo de que algo se rompa, sea más difícil de mantener y termine por consumir más recursos. Por otra parte, es necesario siempre empujar el producto a alcanzar su potencial completo.

Por eso es importante hacer Quality Assurance (QA) testing donde un equipo se encargue de probar que las nuevas ideas funcionan como fueron propuestas por la escuadra de producto y no introducen nuevos problemas. Los cuales llamamos regresiones.

3. Tener un roadmap de funcionalidades y no de retos de negocio

Generalmente un escenario de desarrollo de software en una empresa luce así: el equipo ejecutivo o algún manager tiene una idea y la “manda a construir”. Después, con ayuda de diseñadores y desarrolladores, esta idea se convierte en una lista de funcionalidades que son escritas en código.

Operar de esta forma limita el intelecto y energía de las personas que conforman la escuadra de producto: el diseñador de producto, el desarrollador y el product manager. La verdadera innovación surge cuando estos perfiles prototipan ideas que prueban con usuarios reales y reducen riesgos antes de determinar qué construir.

La propuesta es que la escuadra trabaje una fase de descubrimiento en la que:

1. El diseñador y el product manager generan prototipos
2. Recolectan feedback del ingeniero sobre estos y lo integran
3. Prueban con usuarios

Y vuelven a repetir el ciclo hasta que están convencidos de tener algo valioso entre manos. Con el resultado de de esta fase se construye el backlog de producto.

Lo más importante de este punto es que al trabajar de estar forma le das entera responsabilidad por los resultados del negocio a los miembros del equipo. Eso los vuelve independientes y competentes. Y sólo gente verdaderamente competente podrá entregar buenos resultados, por lo que tu cultura y reclutamiento tendrán que ser impecables, pero eso es para otro artículo.

4. Idear sin incluir al desarrollador desde temprano

Uno de los errores más comunes al hacer producto es no incluir al desarrollador en la etapa temprana del proceso de ideación. Generalmente se les da una lista de funcionalidades y hasta entonces, ya que la idea está definida, pueden hacer aportaciones desde su profesión.

Esto sencillamente frena la innovación.

Descarta muchas posibilidades que pudieron haberse considerado si se hubiera involucrado a este perfil técnico desde un inicio. Es por eso que en una escuadra de producto el product manager y el diseñador siempre están en comunicación con el desarrollador para:

1. Pedir feedback sobre los prototipos que quieren probar con usuarios
2. Resolver dudas que pueda tener el programador del diseño o lógica de la herramienta

Es importante incluir a los desarrolladores desde el inicio de la fase de experimentación, que atiendan periódicamente a pruebas de usuario y que su intelecto siempre busque resolver el reto de negocio que está tacleando la escuadra.

5. No testear/hablar con usuarios

Todo puede estar marchando y si no hablas con usuarios podrías tirar todo tu dinero a la basura.

Hablar con tus clientes (o potenciales usuarios) es la manera más sencilla de reducir los riesgos de usabilidad y valor de un producto. Tus usuarios son quienes perciben la utilidad de tu herramienta y haciendo preguntas y grabando sesiones encontrarás toda la información que necesitas para resolver una verdadera necesidad.

Bien dicen en Y Combinator que la columna vertebral de toda startup es hablar con usuarios y construir tu producto.

6. No administrar el cambio

Otro error que cometen las compañías es tratar de que sus equipos adopten una nueva herramienta de inmediato en vez de paulatinamente. O intentar introducir un nuevo servicio a toda su base de clientes antes de validar si una idea funciona.

En Acueducto siempre empujamos desarrollar el producto de la mano de seis usuarios beta quienes, a cambio de un precio preferencial, te permiten experimentar y diseñar una solución hasta que todo mundo es feliz. Por un lado la empresa construye un producto valioso, los usuarios se benefician de este valor y, más importante, están lo suficientemente satisfechos que serían capaces de recomendar el producto.

En pocas palabras: ve de menos a más.

7. Creer que tu primer idea será la mejor que tendrás

Una realidad es que muchas de las agencias y estudios de producto allá afuera fallan constantemente al intentar definir estimaciones de sus costos. Principalmente por dos razones:

1. La primera es que no hacen un análisis de riesgo para verificar si los programadores del proyecto tienen las capacidades técnicas y recursos para cumplir con la solución que se busca construir. Esto causa retrasos por regresiones y malos cálculos.
2. La segunda, más importante para este punto, es que se cree de manera sobre optimista que la primer solución a la que llegue la escuadra de producto será la correcta.

Es muy raro que algo así suceda. De hecho, las mejores escuadras de producto asumen a priori que lo primero se construya cambiará definitivamente, pues aunque la idea pueda ser la correcta; la forma del diseño y cómo entrega valor cambiará definitivamente.

Hay que tener espacio para esta experimentación y adecuación continua. Lo que nos lleva al último punto.

8. Construir código personalizado sin los recursos necesarios

No engañemos a nadie: desarrollar software es caro. Los salarios de programadores, product managers y diseñadores de producto son altos. Y no sólo se trata de construir la máquina, sino también de mantenerla y mejorarla conforme avanza el tiempo.

Es por eso que es vital que antes de emprender cualquier proyecto que involucre el desarrollo de un producto digital se tengan los recursos necesarios para mantener a una escuadra de producto trabajando tiempo completo por lo menos 8 meses. De igual forma, es importante considerar lo que serán los costos de mantenimiento de la herramienta en cuestión y el servicio técnico.

Si al hacer este análisis las cosas quedan apretadas o tu estómago duda, es mejor probar el concepto con una herramienta no-code y después pensar en desarrollar código personalizado. Esto te permitirá arrancar y validar más rápido tu idea.

Cada uno de los puntos mencionados es materia suficiente para tener un artículo propio. De hecho, tenemos un podcast en el que después de 100 episodios grabados seguimos discutiendo y encontrando nuevas formas de enfrentar estas problemáticas. Sin embargo, tomar estas consideraciones aumentará la probabilidad de éxito de cualquier proyecto que involucre desarrollar productos digitales.

En resumen, hay que evitar:

1. Programar código antes de minimizar los riesgos más comunes en un producto
2. Abarcar muchas cosas al principio
3. Tener un roadmap de funcionalidades y no de retos de negocio
4. Idear sin incluir al desarrollador desde temprano
5. No testear/hablar con usuarios
6. No administrar el cambio
7. Creer que tu primer idea será la mejor que tendrás
8. Construir código personalizado sin los recursos necesarios

Si te gustó este artículo ayúdanos compartiéndolo con alguien que creas que puede servirle. De igual forma, escucha nuestro podcast donde cada semana invitamos a inversionistas, fundadores y líderes de las startups de tecnología más emocionantes de Latinoamérica.