¿Tiene sentido hacer discovery para el back office de tu producto digital?

El back office es la parte de tu producto en donde se configura lo que verá tus clientes y mucho más. Veremos porque algunos backoffice son frankensteins y cómo poder solucionar esto usando discovery

TL;DR

Cuando entramos en una tienda física, vemos que está todo colocado en su sitio y nosotros lo único que tenemos que hacer es seleccionar un producto, pagarlo e irnos.

En este ejemplo, el “back office” sería la gestión de la tienda, lo que pasa en los cuartos de atrás de la tienda.

El back office de la tienda física permitiría definir los precios con etiquetas, tener inventario de los productos para saber cuantos productos hay de cada tipo, tener claro como colocar los productos en la tienda, cúando y como sacarlos y colocarlos, además de poder acceder a los recibos y facturas de nuestros productos.

En el mundo digital, el back office es lo que permite organizar el negocio para que el cliente final, cuando acceda a tu producto digital, pueda hacer exactamente lo mismo que en una tienda física. Esto es, entrar, comprar (en el caso de e-commerce o marketplaces) e irse.

Si tenemos un “back office” en donde nadie sabe usar tendremos un negocio dificil de configurar y gestionar.

Si por el contrario el “back office” en donde la información que se necesita se encuentra de forma fácil, y el trabajo que hay que hacer es sencillo e intuitivo, la gestión del negocio será más sencilla y ordenada.

En este post hablaré del cómo suelen ser los inicios de un back office y cómo es posible vivir con un back office mal diseñado por tiempo infinito.

También explicaré cuando es importante que un back office evolucione para que personas que lo gestionan puedan manejarlo de forma sencilla e intuitiva.

Por último, contaré mi experiencia creando back offices de marketplaces, que es en donde he visto que se pone más foco, cariño y tiempo al discovery.

El Back Office como copia visual de la base de datos

En mi carrera profesional he visto unos cuantos back office, y en muchas ocasiones me preguntaba porqué se había construido el back office de la manera tan poco intuitiva.

Tuve la respuesta el día que pude meter mis zarpas en la base de datos de algunos de estos productos, y ver que el back office era en realidad un espejo de la base de datos del producto.

Esto es, había una interfaz en donde alguien podía meter datos en la base de datos, sin tener que ir directamente a la base de datos a insertarlo.

¿Qué es una base de datos?

Aunque parezca trivial, puede que no todo el mundo sepa que es una base de datos.

Una base de datos es el sitio donde la información del negocio se guarda de forma permanente.

Los programadores hacen programas que escriben en la base de datos para que los datos de los clientes y el negocio se guarden y se puedan consultar más tarde.

Esto permite que cuando entres en una página web, puedas ver tu nombre, apeliidos, email, las compras que has hecho y una larga lista de características que se guardan asociadas a tu perfil.

Uno de las personas que creó las bases de la ingeniería informática, Alan Turing, definió las bases de lo que ahora conocemos como base de datos.

Alan Turing definió que se necesitan sistemas que guarden información de forma permanente, y que el estado de lo que se guarda se pueda alterar más adelante en el tiempo y que pueda mantenerse alterado en el tiempo.

Esto es lo que se conoce como una “maquina de estados”, y en el caso de las bases de datos, es lo que permite guardar información sobre nuestro negocio y usuarios.

La razón por la que un back office es la copia de una base de datos

Cuando una empresa lanza un producto digital al mercado, lo más importante es el “Time To Market”, que vendría a traducirse en llegar lo antes posible a las manos de tu clientes.

¡Y para eso, en muchas ocasiones, el back office es lo primero que se quita del alcance!

Si el producto funciona, ese backend inexistente se sustituye por peticiones constantes al equipo de desarrollo para que haga cambios en la base de datos que afectan a la parte frontal de la aplicación.

Los desarrolladores, hartos de estos cambios, hacen lo que saben hacer mejor. Esto es, crear soluciones para no tener que hacer tareas repetitivas y de poco valor.

Así que proponen “crear un back office” en donde la gente pueda hacer lo que ellos hacen sin tener que molestarles.

Esto es, una serie de pantallas visuales a las que se accede con credenciales (usuario y contraseña) en donde la gente que opera el back office puede “ver” la base de datos, y a través de una pantalla añadir estos datos sin que un desarrollador tenga que tocar nada.

¿Funciona este tipo de back office?

La respuesta más coherente es “si y no”.

Si funciona porque la alternativa anterior, que es que los programadores añadan los cambios en el código, es mucho peor que este tipo de back office.

“Funciona”, porque libera a programadores de hacer actualizaciones manuales para poder manatener el negocio, y permite que se centren en tareas de más valor.

Pero por otro lado, no funciona porque las personas que operan este back office “Frankenstein” tienen que ser guiados y tienen que adaptarse a una nomenclatura y forma de trabajar técnica, cuando ellos mismos no son técnicos.

Lo que suele pasar es que el departamento de turno suele seleccionar a uno o varios “voluntarios” para que entiendan como funciona el engendro que se ha creado, y estas personas serán las responsables de actualizar el back office para el area de negocio que necesite hacer updates en la base de datos.

Y aunque parezca mentira, se puede vivir mucho tiempo asi.

El único inconveniente que se pueda tener es que la persona que gestiona el back office decida dejar la empresa y haya que formar a otra persona para que gestione el día a día del back office.

El impacto de los marketplaces en el diseño y desarrollo de los back office

Uno de los mayores impactos en el diseño y desarrollo de back offices ha sido la profileración de marketplaces.

Un marketplace permite a un productor vender sus productos a través de un marketplace a un consumidor, y esto lo que hace es que alguien tenga que “subir” sus productos a la plataforma usando un back office.

Los marketplaces pueden empezar y seguir trabajando en el modelo de “interfaz de base de datos” y suelen ser empleados de la empresa los que hacen esta labor de subida.

El problema viene cuando el marketplace tiene éxito, y cada vez vienen más y más productores a la plataforma.

Es en ese momento en donde se tiene que tener a un equipo de “bots” (perdón, personas) que “pican” en el back office “Frankenstein” los datos de los proveedores.

Este trabajo es tedioso para las personas que lo tienen que hacer, y si el marketplace empieza a tener éxito y entran más productores se tendrá que contratar a más gente para poder añadir los datos de los proveedores.

El problema que esto genera es, por un lado, es que tienes un trabajo de baja cualificación en donde la gente se quema, y por otro lado los productores no tienen control ni tampoco saben cuando su contenido se publicará.

A los productores se les pide una serie de textos, imágenes y ficheros con sus productos, que luego “alguien meterá en algún sitio” y se creará su pagina y los productos que el productor puede ofrecer en el marketplace.

Y si al productor no le gusta, tendrá que solicitar modificaciones, que se verán una vez el “bot” de turno las actualice.

Y lo mismo pasa con la monitorización del inventario.

Alguien pasará un informe al productor, y ellos tendrán que creer que los datos que se pasan son verdaderos.

La alternativa a tener “bots” subiendo contenido sería dar acceso a los productores para que gestionen su cuenta con el “Frankenstein” de back office.

El problema en este caso es que si ya a un empleado le cuesta usar esta interfaz, no imaginemos cómo sería la experiencia para una persona que no tiene relación ni con los desarrolladores ni tampoco con cómo funciona la tecnología en general.

Lo que seguramente pase es que el productor llamará una y otra vez al comercial o atención a cliente, les quemará la cabeza, y el comercial o la persona de atención a cliente generarán ruido para volver al modelo de “bots” anterior.

La visión de back office de un marketplace

La visión para un marketplace se va creando en la mente de fundadores y líderes de producto con esta simple pregunta:

¿Y porqué no creamos un back office que sea intuitivo y que hasta el productor menos “techy” pueda manejar? Aquí es donde entra la visión de hacer discovery en la parte de back office.

Hacer discovery de back office es poder crear un back office al que los usuarios del back office puedan acceder y “auto gestionarse” de forma sencilla e intuitiva.

Sería un back office en donde los usuarios sean guiados por la creación de su página de promoción y sus productos de una forma intuitiva y natural.

Además de la creación del su sitio y sus productos, se necesitarían pensar y descubrir formas naturales e intuitivas para que el productor pueda gestionar su negocio en el back office, tenga la información más importante al alcance en todo momento, y también pueda comunicarse con el negocio en caso de necesitar apoyo.

Por último, también hay que pensar en la forma en que un productor que no quiera seguir haciendo negocio con nosotros lo pueda comunicar y que este proceso de baja sea fácil e intuitivo.

¿Cómo hacer discovery de back office?

El discovery de back office se hace como cualquier otro proceso de discovery.

Empezamos por plantear hipótesis y luego vamos creando entrevistas de usuarios para poder evaluar nuestras hipótesis.

Dicho esto, también hay que dar un paso más allá y pensar en los procesos.

Siguiendo con el ejemplo de un marketplace, habría que pensar y definir los pasos de gestión de tu marketplace.

Pensemos, por poner un ejemplo, en una plataforma de eventos. ¿Qué necesitaría esta plataforma por la parte del creador?

• Alta: Aquí tendremos que definir si damos acceso “a cualquiera” o restringimos la entrada. Esto depende del modelo de marketplace, claro. No es lo mismo eventos que productos fisicos enviados desde el productor directamente al consumidor.

  • Restringir acceso: Al principio, mientras se aprende, sería mejor restringuir el acceso y aprender de los primeros usuarios

  • No restringir acceso: Aquí el reto es ver qué puede y que no puede hacer el usuario que accede a tu plataforma desde el backoffice. Un ejemplo es si podría publicar (o no) sus eventos.

• Publicación: En este paso lo que hay que permitir es dar de alta los eventos y publicarlos. De nuevo, otra decisión de diseño y negocio. ¿Dejamos que los productores publiquen o paramos la publicación para revisar

  • Permitir publicación: Si no has restringido el acceso, y te fias de tus proveedores, podrías permitirles publicar. El riesgo está en que si alguien hackea la cuenta de un proveedor, puede que tengas problemas con lo que pueda llegar a publicar este hacker.

  • No permitir publicación: Aquí una vez que el productor “solicite” publicar, se comunicaría a un equipo “revisor” que revisarían lo que los productores publican y confirmarían la publicación del contenido. Aquí el reto principal es la comunicación de “solicitud de publicación” y luego la comunicación de “Confirmación de publicación” así como los tiempos de revisión.

• Gestión: En este paso lo que hay que permitir a los productores es poder gestionar sus eventos de la forma más sencilla y optima para el productor, y poniendo la información que más útil en la primera pantalla a la que acceda.

• Cobro: Es importante también dar claridad y visibilidad a un productor para que pueda ver el dinero que está ganando. Al fin y al cabo, el dinero es lo que le ha traído y es lo que le permitirá seguir enganchado y usando tu plataforma.

Análisis de la competencia

Siguiendo con el ejemplo de los marketplaces de eventos.

Se puede ir a la competencia y entender cómo lo hacen ellos todos los procesos arriba descritos, y de esta forma comparar mejores prácticas.

Después del análisis, se pueden ver qué cosas encajan en el modelo de marketplace y sobre todo de back office que queremos construir.

La realidad es que muchos marketplaces más avanzados permiten acceso gratuito al back office y uso mínimo hasta empezar operaciones.

Definiendo flujos y puntos de control

Una vez hayamos hecho el análisis de todo el ciclo de vida de gestión del producto de back office para alguien que está creando contenido en el lado de productor, lo que toca es definir bien todos los puntos de control y cómo funcionarán, para así tener un diseño coherente del flujo del marketplace.

Eligiendo que parte del Frankenstein atacamos primero

Al final del análisis, se tiene que entender mediante entrevistas con los productores que parte del “Frankenstein” atacamos primero y hacer un prototipo para mostrar a los productores.

Esto quiere decir que la mayoría del back office seguirá gestionada a modo “frankenstein”, mientras que una parte se permitirá gestión más evolucionada.

Esta parte será la que, a través de entrevistas de usuarios productores, descubramos que es el “pain” (dolor) más grande que tengan estos productores, y ataquemos ese problema primero.

Esto se puede hacer para cualquier back office

He puesto el ejemplo de los back office de market place, porque en mi experiencia es a los que más cariño y esfuerzo de discovery y diseño se les ha dedicado.

Pero este tipo de discovery no sólo debería hacerse con los marketplaces.

Cualquier back office que use un equipo puede tener un proceso de discovery y definir los problemas más importantes a los que se enfrenta el usuario que usa el back office para luego rediseñar dicho back office para que sea lo más fácil para el dia a día de dicho usuario.

Conclusiones

El común de los back offices nace como una “interfaz” de la base de datos para que los desarrolladores no tengan que añadir código a mano de forma repetitiva.

Esto está bien por un tiempo, pero cuando el negocio crece, vale la pena dedicar tiempo para hacer discovery de las necesidades reales de la gente que maneja este back office.

Los marketplaces, por su naturaleza de productor y consumidor, son un sitio perfecto para dar mimo al back office en forma de discovery. Esto no quiere decir que cualquier back office no pueda tener el mismo discovery, pero quizás es más difícil justificar la inversión.

En tí está evaluar el estado del arte de tu back office, y actuar en consecuencia de lo que necesite tu negocio.