No te preocupes, el objetivo de este artículo no es decidir si estás "a favor o en contra del no-code" en términos absolutos.
Lo que quiero es que nos proyectemos en el mundo al que nos encaminamos rápidamente. Un mundo en el que una gran parte, o incluso la mayoría, de los equipos de producto podrían basarse en el no-code... Reflexionemos sobre las grandes implicaciones que este cambio tendrá en todos los ámbitos (competencias, contratación, perfiles, procesos, organización...)
Con motivo del anuncio de la ronda récord de Bubble (100 millones de dólares en julio de 2021), me remonté a las últimas intervenciones de uno de sus fundadores, Emmanuel Straschnov.
En una entrevista en Station F, Straschnov hablaba de la misión de Buuble y recuerdo cuánto me chocó la contundencia de esta declaración: "Hacer obsoleto al cofundador de la tecnología".
La colaboración con los CTOs y el trabajo en equipos ágiles en los que el producto y la tecnología van de la mano, están muy arraigados en la cultura actual del producto. Su punto de vista me pareció muy diferente a esta forma de pensar.
Pero rápidamente empecé a imaginar todos los beneficios que traería esta revolución que nos obligaría a repensar todos nuestros métodos de funcionamiento con los equipos técnicos.
Para saber más: descarga el libro organizaciones de producto
La apropiación del no-code por parte de los equipos de Producto en su conjunto no es ni más ni menos que la culminación de los principios fundacionales de la cultura de Producto al "eliminar" uno de los componentes de la ecuación: los equipos técnicos. Un componente que, hay que admitirlo, se ha convertido en un obstáculo en demasiados casos con el paso del tiempo.
Creo que hoy en día, la comunidad de Producto no es consciente del alcance del no-code, ni de la urgencia de aprovecharlo.
¿Llega tarde la comunidad de producto?
Los límites reales o imaginarios del no-code van cayendo uno a uno
Hoy en día, los escépticos del no-code señalan siempre las mismas objeciones relacionadas con la seguridad, la escalabilidad o la propiedad de las aplicaciones y/o los datos, sin ser exhaustivos.
Sin embargo, cada semana se anuncian nuevos productos no-code dentro de la comunidad para superar estas limitaciones.
Las soluciones pragmáticas (seguridad de los datos de extremo a extremo, desacoplamiento Front/Back con mezcla de código/no-code, código abierto, generación de código a partir de herramientas sin código, especialización vertical y horizontal, etc.) están surgiendo o ya existen.
Dentro de unos meses o años, los detractores ya no tendrán argumentos reales para oponerse. En mi humilde opinión, es sólo cuestión de tiempo.
Desde el punto de vista del usuario, casi no hay diferencia en la calidad percibida
Una de las razones que me llevó a escribir este artículo surgió de una discusión con un miembro activo de la comunidad no-code en Francia, que me comentó su escepticismo sobre la viabilidad de un servicio basado en herramientas sin código en el sector médico (confidencialidad, alojamiento de datos sanitarios, etc.)
Así que le presenté un servicio existente (un marketplace entre Profesionales de la Salud y Pacientes) y le pregunté si había sido hecho en no-code y para mi gran sorpresa después de haber analizado el servicio desde un punto de vista cualitativo y técnico (a través de una herramienta tipo Wappalyzer), fue incapaz de detectar que este servicio había sido hecho por: WeWeb.
Si un miembro experto de la comunidad ya no puede distinguir la diferencia, está claro que estamos cerca del punto de inflexión.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
Los Product Managers «de toda la vida», infrarrepresentados entre los usuarios no-code
No me malinterpreten, hay por supuesto muchos contraejemplos dentro de la comunidad de producto y declaraciones recientes de evangelistas, fundadores de academias de no-code (Poke Milan Boisgard, Florent Isidore, Timothé Frin) e incluso Product Managers que utilizan herramientas de no-code en el día a día o que han sido reclutados para hacerlo.
Pero si se observa con detenimiento, a menudo se trata de casos especiales:
- Perfiles específicos (antiguos devs, growth hackers que han pasado a productos, etc.)
- Contextos específicos (Jetlang en Payfit, ...)
Para cuantificar mejor el problema, revisé los canales de Slack u otras secciones de "introducción" de diferentes comunidades y formaciones sin código para darme cuenta de que los usuarios existentes se dividen en 4 categorías principales:
- 1. Desarrolladores: aunque el no-code es a veces objeto de acalorados debates en la comunidad tecnológica, hay muchos evangelistas y pioneros que lo utilizan como una simple evolución del nivel de abstracción de los marcos de desarrollo. Habiendo comenzado yo mismo mi carrera en 1997 como desarrollador en lenguajes que entonces se llamaban L4G (lenguaje de 4ª generación, término formalizado en 1982 por J.Martin, probablemente el precursor del enfoque NoCode, hace 40 años con su libro "Desarrollo de aplicaciones sin programadores"), puedo atestiguar que los frameworks, las bibliotecas, los módulos, etc. disponibles para los equipos tecnológicos de hoy en día, son de bajo código en comparación con las tecnologías utilizadas hace más de 20 años. En este caso, todo es una cuestión de perspectiva y de calendario. Esta es una de las razones por las que digo que esta evolución es inevitable.
- 2. Growth Hackers: pongo detrás de este término, un poco comodín, a todos los perfiles que trabajan en stacks de marketing más o menos independientes de los principales stacks de producto, y que se basan en herramientas interconectadas a través de APIs estándar o no estándar. Al principio, pocos equipos de Producto "clásicos" se dedicaban a apoyar a los equipos de marketing y adquisición, aunque esto está cambiando con la creación de equipos de "Growth", "Site Discovery" (usuarios offline), etc. Lógicamente, todo el ecosistema lleva años estructurando soluciones basadas en herramientas no-code para hacer frente a estos retos.
-
- 3. Equipos pequeños: agencias o PYMES que no tienen el presupuesto y el área de empleo circundante para contratar equipos técnicos o proveedores de servicios. En este caso, no queda más remedio que utilizar herramientas no-code para prestar simplemente su servicio o desarrollar herramientas internas.
- 4. Empresarios que buscan el Product Market Fit: este es el principal objetivo que se plantea sistemáticamente cuando se habla de los beneficios del no-code (flexibilidad, rapidez, iteración con los usuarios, costes, etc.) y de los casos de uso en el desarrollo de nuevos productos. Estos beneficios se aplican y son igual de relevantes con un producto y un equipo de Producto/Tecnología más maduro. La única diferencia viene del contexto: en el primer caso, el fundador no tiene todavía un equipo técnico y, por tanto, no tiene ninguna opción real para encontrar su PMF. En el segundo caso, los equipos de producto ya están entrelazados con los equipos técnicos y, por lo tanto, no tienen otra opción percibida que trabajar con ellos....
- Los Product Managers «de toda la vida» (en el sentido de «ya integrados en una organización de producto madura, dentro de un equipo de 3-6 devs») no se encuentran, por tanto, entre los principales usuarios de no-code. Un estudio realizado Product Managers love no-code muestra que sólo el 20% de los Product Managers encuestados (de un público que ya está sesgado porque está muy interesado en el tema) aplica regularmente el no-code.
Si tomo como ejemplo concreto la formación Notion Secrets ofrecida por Shubham Sharma, uno de los Youtubers no-code más influyentes, sólo hay 4 Product Managers entre los 150 Miembros que participan en la primera promoción de esta formación, es decir, ¡menos del 3%!
Habían más agentes inmobiliarios registrados que Product Managers.
Esta observación se confirma de nuevo en el estudio Product Managers love no-code, que indica que sólo el 4% de los Product Managers encuestados utilizan no-code para su producto interno (excluyendo la automatización de procesos y la productividad).
No obstante, el tema está ganando adeptos: 949 personas de producto, principalmente Product Managers, se han apuntado a la serie de webinars no-code. A principios de 2022, sin duda asistimos a una toma de conciencia de los trastornos que nos esperan.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
¿Cuáles son los macro impactos para la organización de producto?
Las potenciales repercusiones para las organizaciones y la comunidad de producto son inmensas y la lista que figura a continuación es sólo un primer intento de formalización no exhaustiva que merecería un estudio más profundo. Me encantaría crear un grupo de trabajo sobre este tema, así que no dudes en ponerte en contacto conmigo si a ti también te gustaría.
Aparecerán nuevos perfiles de Product Managers
Estamos viendo las primeras definiciones de puestos específicos con nombres como No-code Maker o Product Builder. Me inclino por el segundo término después de leer el excelente artículo de Milan Boisgard que se refiere a Payfit, una empresa pionera en este campo.
El uso del término Product Manager no-code no me parece apropiado. Es restrictivo y parece limitar el papel del Product Manager a un único tipo de entrega, cuando a corto plazo el no-code es sólo una de las opciones de las que dispone. Me he dado cuenta de que, en muchos casos, este término se utiliza en ofertas de trabajo para empresas de servicios, donde es la principal propuesta de valor, pero no en un contexto clásico de Producto.
Otro tipo de perfil me parece esencial en este nuevo contexto, el del Product Architect (Arquitecto de Producto), que puede verse como la transferencia del papel de Arquitecto de Soluciones en el lado de la Tecnología, y que es aún más esencial en un mundo que se basa en múltiples soluciones no-code/low-code para prestar un servicio.
Se redefinirán las competencias básicas de los Product Managers
Aunque la cultura del producto siga siendo estrictamente la misma en un contexto no-code, las competencias clave de los Product Managers evolucionarán desde el punto de vista de las competencias duras:
- 1. Conocimiento de las herramientas no-code
- 2. Arquitectura de la base de datos
- 3. Arquitectura funcional de rutas de usuario/ Mash Up de servicios basados en API.
Y soft-skills, incluyendo los siguientes aspectos:
- 1. Curiosidad
- 2. Versatilidad/ Versatilidad
- 3. Orientación a la resolución de problemas
- 4. Espíritu emprendedor
En cualquier caso, será esencial una trayectoria profesional específica, como la de Product Builder, para dar perspectivas a este tipo de perfil o permitir que los perfiles existentes se pasen a esta trayectoria.
¿Estamos avanzando hacia una organización «Tech Free»?
En una organización "Tech Free" teórica y extrema, una gran parte del tiempo dedicado a la coordinación con los equipos Tech se liberará para su reutilización inmediata.
¿Qué debemos hacer con todo este tiempo y energía y en qué temas debemos centrarnos? En mi opinión, 5 temas son esenciales:
- 1. Reapropiarse de temas/problemas que a menudo se consideran principalmente tecnológicos (seguridad, escalabilidad, disponibilidad de servicios....).
- 2. Invertir más en las fases de diseño teniendo en cuenta tanto los aspectos funcionales como los de arquitectura de herramientas, arquitectura de datos y escalabilidad de la solución.
- 3. Formalizar, formalizar, formalizar en particular la forma en que se lleva a cabo el servicio a través de herramientas no-code, las APIs utilizadas, los SLAs y los contratos de servicio
- 4. Volver a los fundamentos del negocio de Product Management (discovery, pruebas de usuario, centrado en el usuario, centrado en los datos, etc.).
- 5. Probar las herramientas no-code y mantener una vigilancia activa.
Por supuesto, estas son sólo algunas ideas que hay que adaptar a cada contexto y, por supuesto, el tiempo liberado para un único Product Manager que se convierta en Product Builder no le permitirá sustituir a su equipo de desarrolladores.
Pero la ecuación global en términos de productividad/recursos necesarios debería lógicamente mejorar. Pasamos de una situación en la que hay 1 Product Manager para 5 desarrolladores, incluyendo 1 Tech Lead, a una situación en la que tendríamos, como ilustración puramente teórica, 2 Product Builders y 1 Product Architect.
Otra forma de ver las cosas es considerar que estamos sustituyendo el tiempo dedicado a la sincronización con el equipo técnico por más tiempo dedicado a la sincronización con los equipos de negocio, por lo que el ahorro de tiempo es nulo, pero ganamos en eficiencia y calidad de diseño.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
¿Cómo garantizar la transición del código al no código, o la llegada de modelos híbridos?
Seamos claros, los equipos tecnológicos no van a desaparecer de la noche a la mañana ni van a desaparecer del todo, pero cada vez habrá más modelos híbridos en los que parte de los equipos desarrollarán en no-code.
Esto implica una cierta complejidad en la que los no-codificadores encajan en la organización en múltiples modelos posibles:
- 1. Equipo dedicado al no-código en herramientas internas, en modo "automatización" - Por ejemplo, en GoJob, hay una tribu de no-código con 4 perfiles de creadores dedicados al no-código.
- 2. Equipo no-code dedicado a un producto o característica específica (debido a la falta de recursos o al deseo de ir rápido e iterar) - Por ejemplo, Luko tiene una tribu de New Business que crea productos no-code. La simulación y suscripción del seguro de préstamo se basa en Bubble, Zapier y Airtable principalmente.
- 3. Equipo no-code en una vertical específica.
- 4. Equipo no-code en modo "estudio interno" pero perenne, que se ocupa de los proyectos caso por caso sin estar asignado permanentemente a un dominio o proyecto específico.
- 5. Equipo de no-code en innovación/Desarrollo de negocio/Asociaciones externas.
Todo esto sólo será posible si se trabaja a fondo no sólo en la gobernanza (elección y desarrollo de herramientas, mapeo de las APIs utilizadas y utilizables, etc.) sino que se hace un esfuerzo especial para "gestionar el cambio" junto con los equipos técnicos.
El no-code ya no permite un modelo de organización de productos de referencia, sino que propone la noción de "Company Organisation Fit", que debe buscarse, encontrarse y desarrollarse a lo largo del tiempo en paralelo a la madurez del no-code de la empresa.
Como ya he dicho, en la actualidad, la difusión del no-code a nivel interno suele provenir de dos tipos de equipos:
- Equipos de growth que demuestran con el ejemplo la eficacia de este enfoque para las pruebas de MVP, páginas de aterrizaje dedicadas o victorias rápidas en términos de conversión.
- Los equipos de OPS que, a falta de soluciones propuestas y construidas por los equipos de Producto y Tecnología, están empezando a crear sus propias soluciones en no-code con Google Sheets (o incluso Airtable para los equipos más maduros) y están empezando a hacer alguna automatización con Zapier.
Estas son probablemente las mejores maneras de empezar a promover el no-code internamente, nombrándolo explícitamente para empezar a impulsar el cambio y mostrar los beneficios inmediatos.
¿Cuáles son los próximos pasos para la comunidad de producto?
La primera cuestión es si queremos sufrir esta evolución o contribuir a su aceleración para beneficiarnos de ella lo antes posible. Estoy firmemente en el segundo campo.
Acelerar en un contexto de escasez de recursos tecnológicos
Es evidente que todas las iniciativas para aumentar la capacidad de formación en las profesiones tecnológicas (democratización y multiplicación de los cursos, Code 4 Kids, feminización, reciclaje ) no han resuelto estructuralmente el déficit de perfiles cualificados, que sigue creciendo, ni en Francia ni en Europa.
Esta escasez de talento crea una relación de poder muy desequilibrada entre estos expertos y el resto de la sociedad.
El esfuerzo y los recursos financieros invertidos en la contratación y retención de perfiles tecnológicos son cada vez mayores.
Una vez contratados, las empresas a veces tienen que ofrecerles políticas de teletrabajo o de aumento de sueldo diferentes a las de otros equipos para retenerlos. También he visto casos en los que se opta por una pila técnica de moda como principal razón para retener y atraer a los desarrolladores.
Además, el retraso en el desarrollo de los productos debido a la falta de desarrolladores se traduce en elevados costes de oportunidad perdidos. Se han convertido en algo fundamental para la mayoría de las empresas.
Por lo tanto, es urgente iniciar una transición hacia un modelo diferente de desarrollo de productos, ya sea para todos o parte de los temas gestionados por los equipos de producto.
Paradójicamente, la contratación de No-Coders hoy en día puede ser incluso más difícil que la contratación de desarrolladores, pero con una barrera de entrada más baja, una capacidad de formación más rápida y un mayor potencial de perfiles compatibles, es sólo cuestión de tiempo que este desequilibrio se invierta.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
Apoyar activamente la aparición de promesas en el marco europeo
En países como Francia, tenemos el ejemplo de empresas que prometen destacar en este ámbito. He mencionado a Bubble al principio, que está muy presente en el corazón de la comunidad francesa del no-code, a pesar de haber sido fundada en Nueva York. Pero hay muchos otros actores prometedores en el ecosistema francés, como Ksaar y WeWeb, por nombrar sólo algunos.
Qué decepción si nuestro papel se limita a acompañar la evolución del no-code desde las primeras audiencias hasta un enfoque más generalizado de forma muy, quizás demasiado, gradual.
No, el reto es acelerar la revolución en curso y ayudar activamente a quienes dan el primer paso a penetrar en el corazón de las organizaciones de productos/tecnología y demostrar que las soluciones no-code son ahora una alternativa creíble y relevante a los modelos tradicionales.
Que los estudios de startups estén desarrollando MVPs en no-code es interesante, por supuesto.
Que haya incubadoras, cursos de formación y otras empresas de servicios no-code es también esencial para el desarrollo del ecosistema.
Pero, ¿es esto realmente lo que va a permitir cambiar los principales servicios B2B o B2C a no-code? ¿Tendremos que esperar a que las startups no-code que se están lanzando actualmente se conviertan en scale-ups sin renegar de su modelo inicial y demostrar así que la escalabilidad ya no es un problema?
...
Terminaré este artículo con la importancia de preparar a nuestros equipos y a los talentos del mañana para esta nueva realidad:
- Sensibilizar a nuestros Product Manager y desmitificar las herramientas no-code.
- Promover el no-code internamente y alinearse con los equipos técnicos sobre los beneficios y la gestión del cambio.
- Introducir gradualmente perfiles de Product Builder en los equipos (mediante formación o contratación).
- Permitir una transición fluida a estos nuevos modelos organizativos imaginando y probando en diferentes escalas/contextos.
Para saber más: descarga el libro organizaciones de producto
