De un experimento en WhatsApp a una red local escalable
Pujobaixo comenzó con un experimento de campo: creamos un grupo de WhatsApp con personas que realizaban habitualmente el trayecto entre el Berguedà y Barcelona para observar cómo aparecían la oferta, la demanda y las coincidencias en un contexto real.
El reto era transformar estos aprendizajes en una red capaz de gestionar más trayectos sin perder la sencillez y la flexibilidad de la coordinación original.
01 Contexto y oportunidad
El hábito de compartir trayectos ya existía dentro de la comunidad. Algunas personas aprovechaban sus desplazamientos habituales entre el Berguedà y Barcelona para compartir plazas disponibles y repartir los gastos del viaje.
Sin embargo, no disponíamos de información estructurada sobre la recurrencia de estos trayectos, cómo se relacionaban la oferta y la demanda o qué condiciones facilitaban una coincidencia.
Antes de construir una plataforma, necesitábamos observar cómo funcionaba realmente esta dinámica.
Creamos un grupo de WhatsApp con personas que realizaban el trayecto con frecuencia. El grupo permitía ofrecer o solicitar viajes indicando información básica como el día, el origen y la dirección del recorrido. Las personas interesadas terminaban de coordinarse directamente.
El objetivo no era introducir una nueva conducta, sino comprender una práctica existente y estudiar cómo podía convertirse en una red local más útil y escalable.
02 Decisión que debíamos tomar
Debíamos decidir si una coordinación informal mediante WhatsApp podía evolucionar hacia un producto digital capaz de gestionar una comunidad más amplia.
Para ello necesitábamos comprender:
- Qué información era imprescindible para encontrar una coincidencia.
- Cómo aparecían la oferta y la demanda.
- Qué partes de la coordinación generaban más esfuerzo.
- Qué dinámicas debíamos conservar.
- Qué elementos necesitaban una estructura específica.
- Si existía suficiente recurrencia para justificar una red local.
La decisión no consistía únicamente en diseñar una interfaz. Antes debíamos entender qué sistema ya estaba emergiendo dentro de la comunidad.
03 Pregunta de investigación
¿Cómo podemos transformar una coordinación informal de trayectos compartidos en una red escalable, manteniendo su sencillez y reduciendo el esfuerzo necesario para encontrar una coincidencia?
Como preguntas secundarias, analizamos:
- ¿Qué información comparten espontáneamente conductores y pasajeros?
- ¿Qué dificulta saber si un viaje sigue disponible?
- ¿Cómo fluctúan la oferta y la demanda?
- ¿Qué debe resolver el producto y qué puede mantenerse en la conversación directa?
- ¿Qué condiciones favorecen que aparezca una coincidencia?
04 Hipótesis iniciales
Partimos de cinco hipótesis:
- Existía suficiente recurrencia de trayectos para construir una red local.
- Centralizar los viajes activos facilitaría encontrar coincidencias.
- Estructurar la información reduciría el esfuerzo de coordinación.
- La comunicación final debía mantenerse en un canal familiar y flexible.
- Compartir los gastos podía reforzar la propuesta de valor, aunque no era la única motivación para compartir vehículo.
El grupo de WhatsApp nos permitió contrastar estas hipótesis mediante comportamiento real, no únicamente mediante opiniones declaradas.
05 Experimento y metodología
Utilizamos el grupo de WhatsApp como un experimento de campo y un prototipo de servicio de baja fidelidad.
En lugar de preguntar únicamente si las personas utilizarían una plataforma de movilidad compartida, creamos un entorno donde la coordinación pudiera ocurrir y observamos cómo se comportaban sus integrantes.
Analizamos:
- Con qué frecuencia se ofrecían o solicitaban trayectos.
- Qué información publicaban espontáneamente.
- Cómo expresaban el origen, el destino y el día del viaje.
- Cómo aparecían las coincidencias.
- Qué información faltaba para tomar una decisión.
- En qué momento la coordinación pasaba a mensajes privados.
- Qué dificultades surgían al aumentar la actividad.
- Cómo variaban la oferta y la demanda según el día y la dirección.
El experimento nos permitió estudiar la dinámica antes de invertir en un producto más complejo.
06 Evidencia observada
El grupo confirmó que existían personas dispuestas a compartir sus trayectos y repartir los gastos cuando encontraban una coincidencia adecuada.
También reveló los límites de utilizar una conversación cronológica como sistema de coordinación:
- Costaba saber qué viajes seguían disponibles.
- La información aparecía de forma desigual.
- Algunas publicaciones no incluían todos los datos necesarios.
- Los trayectos anteriores quedaban ocultos por nuevos mensajes.
- Encontrar una coincidencia exigía revisar manualmente la conversación.
- No existía una visión conjunta de la oferta y la demanda.
- A medida que aumentaba la actividad, la coordinación perdía claridad.
WhatsApp facilitaba el contacto entre personas, pero no permitía organizar una red más amplia.
07 Patrones e insights
1. El hábito existía, pero la red todavía no
Las personas ya estaban dispuestas a compartir trayectos cuando encontraban una coincidencia adecuada.
La oportunidad no consistía en crear ese comportamiento, sino en conectarlo dentro de un sistema más visible, recurrente y escalable.
2. La principal fricción era encontrar la coincidencia
El problema no era únicamente la falta de oferta o demanda.
La dificultad estaba en localizar un trayecto compatible, comprobar si seguía activo y completar la información necesaria para coordinarlo.
3. WhatsApp validaba la dinámica, pero no podía escalarla
El grupo funcionó como primer prototipo del servicio y permitió observar el comportamiento real.
Sin embargo, la estructura cronológica de la conversación no era adecuada para gestionar más usuarios, viajes y coincidencias simultáneas.
4. Escalar requería estructurar, no complicar
El producto debía organizar la información y reducir el esfuerzo de búsqueda sin transformar una práctica flexible en un proceso rígido.
5. La visibilidad de la red condicionaba su utilidad
Una red de movilidad compartida necesita que conductores y pasajeros puedan identificar rápidamente qué oferta y demanda existen en cada dirección y momento.
08 Implicaciones para producto
La investigación mostró que Pujobaixo no debía sustituir por completo la dinámica existente, sino estructurar las partes que generaban más esfuerzo.
La principal oportunidad consistía en centralizar los viajes activos, normalizar la información necesaria y diferenciar claramente entre quienes ofrecían plazas y quienes buscaban desplazamiento.
La plataforma debía facilitar el descubrimiento de coincidencias, pero las personas debían conservar el control sobre con quién viajaban y cómo terminaban de coordinarse.
También necesitábamos mantener un modelo ligero. No era necesario construir desde el inicio un sistema cerrado de reservas, pagos o asignación automática.
Pujobaixo debía actuar como una capa de organización sobre un comportamiento que ya funcionaba:
- Ordenar la oferta y la demanda.
- Hacer visibles los viajes activos.
- Reducir la búsqueda manual.
- Facilitar el contacto.
- Preparar la red para incorporar más usuarios y trayectos.
El ahorro se incorporó como un beneficio tangible de aprovechar las plazas vacías, sin reducir la propuesta de valor a una transacción económica.
09 Decisiones tomadas
Separar oferta y demanda
Organizamos los trayectos en dos categorías:
- Ofrezco, para conductores con plazas disponibles.
- Necesito, para personas que buscaban un desplazamiento.
Esta separación permitía identificar rápidamente qué tipo de publicación estaba consultando el usuario.
Estructurar la información del viaje
Cada publicación agrupaba los datos necesarios para evaluar una posible coincidencia:
- Origen.
- Destino.
- Fecha.
- Hora.
- Dirección del trayecto.
- Número de plazas.
- Información adicional relevante.
Esto reducía la necesidad de completar datos mediante varias conversaciones.
Centralizar los viajes activos
Los trayectos dejaron de depender del orden cronológico de un grupo y pasaron a mostrarse como publicaciones consultables.
La red podía ofrecer una visión más clara de qué viajes estaban disponibles en cada momento.
Mantener WhatsApp para la coordinación final
Una vez encontrada una coincidencia, las personas podían contactar directamente mediante WhatsApp.
Esto permitió reducir el alcance inicial del producto y conservar un canal que la comunidad ya conocía.
Dar control sobre la disponibilidad
Los usuarios podían gestionar y cancelar sus propios viajes.
Esta decisión ayudaba a mantener la información actualizada y reducía la incertidumbre sobre qué publicaciones seguían activas.
Preparar la solución para escalar
La plataforma transformó un experimento gestionado manualmente en una red digital capaz de incorporar más conductores, pasajeros y trayectos.
El flujo principal quedó reducido a una secuencia sencilla: publicar una oferta o necesidad → encontrar una coincidencia activa → coordinar el viaje directamente.
10 Resultado, limitaciones y próximos pasos
Pujobaixo convirtió un experimento de coordinación mediante WhatsApp en un producto funcional capaz de centralizar la oferta y la demanda de trayectos entre el Berguedà y Barcelona.
La principal aportación de la investigación fue demostrar que el valor no estaba en inventar una nueva conducta, sino en reducir el coste de coordinación de una práctica que ya existía.
El producto permitió:
- Estructurar la información mínima de cada trayecto.
- Diferenciar oferta y demanda.
- Hacer visibles los viajes activos.
- Facilitar la búsqueda de coincidencias.
- Mantener una coordinación final directa.
- Preparar la dinámica para abarcar una comunidad más amplia.
Limitaciones: el experimento se realizó dentro de una comunidad concreta y con personas que ya mostraban cierta predisposición a compartir vehículo. Por tanto, esta fase permitió comprender a usuarios activos, pero todavía no explicaba completamente:
- Las barreras de quienes nunca han compartido coche.
- Las necesidades de confianza entre personas desconocidas.
- El comportamiento de la red con un volumen mayor de usuarios.
- El equilibrio mínimo entre oferta y demanda.
- Cuántas coincidencias terminaban convirtiéndose en viajes realizados.
Próximos pasos: la siguiente fase debería evaluar el comportamiento real de la red mediante:
- Número de viajes ofrecidos y solicitados.
- Coincidencias generadas por dirección y franja horaria.
- Porcentaje de publicaciones que reciben una respuesta.
- Tiempo hasta el primer contacto.
- Viajes cancelados o que dejan de estar disponibles.
- Usuarios que vuelven a publicar.
- Relación entre conductores y pasajeros activos.
- Trayectos que terminan realizándose.
- Ahorro estimado por vehículo y por usuario.
Evidencia → Insight → Decisión
El experimento confirmó que existían trayectos recurrentes y disposición para compartirlos, pero encontrar viajes disponibles dentro de una conversación requería demasiado esfuerzo.
El hábito de compartir coche ya existía. Lo que faltaba era una estructura capaz de conectar y hacer visible una mayor oferta y demanda.
Transformar el experimento en una red digital que centralizara los viajes activos, facilitara las coincidencias y mantuviera WhatsApp para la coordinación final.
Aprendizaje principal: escalar una práctica comunitaria no siempre significa reemplazarla. En este caso, significó observar qué ya funcionaba, estructurar las fricciones y convertir una coordinación informal en una red preparada para gestionar más oferta y demanda sin perder su flexibilidad.
¿Tu producto necesita escalar un comportamiento que ya existe en una comunidad?
Hablemos de cómo estructurar solo las fricciones, sin perder la flexibilidad que lo hace funcionar.
Hablemos