Cómo desarrollamos nuestro producto

Qué es un producto?

Tiendanube es una empresa “de producto”. Esto significa que nuestro negocio principal consiste en desarrollar un producto para nuestros clientes. Nuestro equipo se llama Producto. Producto, producto, producto; lo mencionamos 3 veces en 3 oraciones. Pero… qué es un producto? Arranquemos por ahí!

En Tiendanube, nos gusta utilizar esta definición:

Un producto es algo que le soluciona un problema a alguien

Esta definición tiene tres palabras clave:

• Algo: un producto puede ser cualquier cosa.
• Problema: hay una situación que se quiere resolver.
• Alguien: hay una persona (o cosa, se viene Skynet 😱) para la cual es importante resolver ese problema, solemos llamarlo “el cliente” o “el stakeholder” del producto.

Estamos usando productos constantemente porque estamos resolviendo problemas constantemente. Tenés hambre y comés una manzana? Acá vos sos el alguien, el hambre el problema y la manzana el producto.

Si aplicamos esta definición a nosotros mismos:

• Algo → Tiendanube.
• Problema → Nuestro propósito! Queremos potenciar historias de éxito de los emprendedores y empresas de Latinoamérica.
• Alguien → Los emprendedores y empresas de Latinoamérica.

Nota importante: esta es la definición más amplia de Tiendanube como producto. En la práctica, el “alguien” para el que trabajemos va a depender mucho de nuestro equipo. Si trabajamos con el ecosistema, probablemente nuestro “alguien” sean agencias o desarrolladores externos. Si trabajamos en desarrollar herramientas internas para nuestra productividad, nuestro “alguien” van a ser las personas que trabajan en Tiendanube. Lo que no tenemos que independientemente del equipo en el que estamos, todos estamos trabajando para esa definición más amplia, nuestro propósito.

Cómo desarrollamos nuestro producto?

Tenemos nuestro problema y nuestro cliente claro, perfecto! Pero cómo trabajamos para solucionarlo? Nos gusta decir que en Tiendanube el equipo de Producto hace únicamente tres cosas:

1. Priorizar problemas
2. Entender problemas
3. Ejecutar soluciones

Las tres partes son fundamentales. Si falla cualquiera de ellas, se derrumba el castillo:

• Si no priorizaste bien el problema vas a estar trabajando en cosas que no van a mover la aguja.
• Si no entendiste bien el problema lo más probable es que tu solución no lo resuelva.
• Si no ejecutás bien la solución vas a tener un cliente insatisfecho, aunque estés atacando la batalla correcta.

Veamos cada una en detalle

Una vez que entendimos los problemas que nuestros clientes están intentando resolver, los priorizamos para decidir en cuál nos enfocamos. Para esto utilizamos un framework que se llama RICE (gracias Intercom!). Es una priorización super sencilla que se basa en:

• Reach: a cuántos clientes les estamos solucionando el problema.
• Impact: cuál es el impacto de solucionar este problema.
• Confidence: qué tanto confiamos en el resto de las estimaciones (50%: lo mismo que tirar una moneda — 100%: somos las Marta/Messi de la estimación).
• Effort: cuánto tiempo le llevaría a una persona hacerlo (lo medimos en meses).

Para entender el Reach necesitamos data cuantitativa. “Cuántos clientes visualizan la tercer página del listado de ventas?”, “Cuánto GMV tiene un cupón de descuento aplicado?”. Todas estas preguntas son super importantes a la hora de decidir qué priorizar. No es lo mismo una funcionalidad que aplica al 100% de nuestros merchants, que al 3.20%. Para esto recibimos ayuda del equipo de Data.

Para entender el Impact necesitamos data cualitativa. Tenemos que ponernos en los zapatos de nuestros clientes y entender el impacto que tiene para ellos resolver esta problemática. Es difícil medirlo con exactitud, por lo que usamos números del 10 al 0 para cuantificarlo. 10 es un impacto brutal, 5 más o menos, 1 poco, 0.25 mínimo. Para esto recibimos ayuda del equipo de Research.

Para entender la Confidence necesitamos ser honestos con nosotros mismos. Esto es algo que nos encanta pero no tenemos la data para backupearlo? Tenemos claridad absoluta de nuestras estimaciones? Con la confianza podemos regular estas cosas. 100% es claridad absoluta, 80% es algo medio, 50% es bajo, lo mismo que tirar una moneda; menos ya es una locura.

Para entender el Effort necesitamos entender cuánto tiempo creemos que nos va a llevar el proyecto en términos de producto, diseño e ingeniería. Lo medimos en “persona por mes” o el trabajo que una persona puede hacer en un mes. Sabemos que las estimaciones son hiper difíciles y hay muchas cosas desconocidas.

Cómo calculamos el puntaje entonces? R * I * C / E = score RICE. Como se podrán imaginar, este framework no hace magias. Pero logra algo muy interesante. Rápidamente, uno logra separar sus problemas en tres grandes grupos: alta/media/baja prioridad. Los de baja prioridad, no los querés hacer en el corto plazo. Los de media prioridad, no los querés hacer hacer el corto plazo. Querés enfocarte en los problemas de alta prioridad.

Para esos problemas sí nos ocupamos de bajar más en detalle para mejorar la estimación y asegurarnos que realmente son problemas de alta prioridad.

Si alguna vez sufriste un problema en carne propia, lo más probable es que cuando le hables de lo que necesitás a otra persona hables en el lenguaje “soluciones”. Esto es muy común: “necesito tomarme vacaciones, “quiero tomar un helado” son frases que cualquiera de nosotros dijo alguna vez. Tomarse vacaciones o tomar un helado es una solución. Como toda solución, puede ser la óptima para solucionar el problema, o no.

Si ejecutamos una solución subóptima que no soluciona un problema personal, las consecuencias probablemente nos impacten a nosotros mismos y tal vez en mayor o menor medida a nuestro círculo de relaciones. Ahora si Tiendanube no soluciona un problema que se propone, nuestro radio de acción son los más de 30 mil clientes que tenemos en nuestra plataforma. Les debemos a nuestros clientes el compromiso de solucionar lo que nos proponemos de manera efectiva.

La calidad de la solución que ejecutemos es directamente proporcional a nuestro entendimiento del problema. Muchas veces las soluciones que presentan los clientes no son las mejores. Y eso está bien! Su responsabilidad es manifestarnos sus dolores, la nuestra es solucionarlos. Somos nosotros quienes tenemos que asegurarnos que logramos la traducción del lenguaje “soluciones” al lenguaje “problemas”. Esto es fun-da-men-tal porque la misma solución puede solucionar diferentes problemas en contextos diferentes o no ser la óptima. Todas las personas de Tiendanube tienen que ser fluidos en el lenguaje “problemas”.

Ejemplo: en Brasil muchos de nuestros clientes realizaban envíos con empresas de mensajería. Y en cada estado de Brasil (serían nuestras provincias) los servicios de mensajería eran diferentes unos de otros. Cada vez que nuestros clientes tenían una venta online, tenían también que coordinar por teléfono el retiro con estos servicios de mensajería. Cada uno de nuestros clientes nos daba soluciones diferentes (“Tienen que integrar el servicio de mensajería X”) al mismo problema. Después de mucho preguntar, nos dimos cuenta su problema: la empresa de correos más grande de Brasil demora en entregar los paquetes y ellos querían ofrecer una mejor calidad post-venta ofreciendo entregas en el mismo día. Cada uno de nuestros clientes nos daba soluciones diferentes (“Tienen que integrar el servicio de mensajería X”) al mismo problema. Después de mucho preguntar, nos dimos cuenta su problema: la empresa de correos más grande de Brasil demora en entregar los paquetes y ellos querían ofrecer una mejor calidad post-venta ofreciendo entregas en el mismo día. Una vez que entendimos este problema, decidimos implementar una solución que ninguno de nuestros clientes nos había sugerido. Nos integramos con Loggi, un servicio de mensajería en Brasil, pero que a su vez es una empresa tecnológica. A través de su API, podemos disparar el pedido de la moto ni bien nuestro cliente nos confirma que el paquete está listo, haciendo automáticamente lo que antes se coordinaba por teléfono.

Para entender los problemas a fondo, trabajamos en conjunto con el equipo de Data (para análisis cuantitativos) y con el equipo Research (para análisis cualitativos).

Agile como dinámica de trabajo

Históricamente, los proyectos de software se trabajaban en modo “Waterfall”, es decir que hasta que el producto no esté desarrollado por completo, no se mostraba a los clientes. Es como si Spotify que se fundó en el 2006 recién lance su producto al mercado hoy 2019, 13 años después y vea si alguien quiere usarlo.

Waterfall

Uno de los grandes problemas de esta metodología es que, al hablar con el cliente únicamente al principio y al final de un proyecto, se asume que (1) el cliente sabe y nos comunicó de manera excelente lo que necesita (2) el equipo lo entendió a la perfección (3) no hay cambios desde que arranca hasta que termina el proyecto.

Eso hace que Waterfall se sienta como disparar una bala de cañón, una vez que se ajustó la trayectoria no hay manera de corregirla.

Prerdictive process = Cannon ball

Después de muchos años (y mucho tiempo/dinero perdido) empezaron a surgir metodologías de trabajo que priorizaban la satisfacción del cliente a través de entregas de valor incrementales de un producto. Ya no se esperaban años para lanzar un producto, sino que se lanzaba en poquitas semanas y luego se va mejorando constantemente.

Agile

La diferencia de Agile es que al estar en contacto permanente con el cliente podemos descubrir (1) lo que el cliente necesita (2) si realmente lo entendimos (3) si surgen cambios. Así nuestro proyecto deja de ser una bala de cañón y se convierte más en un misil guiado que va ajustando su trayectoria a medida que se acerca al objetivo.

Estamos convencidos que si queremos ser el mejor equipo de LATAM, necesitamos trabajar de manera Agile.

Adaptive process = homing missile

Pero qué significa ser Agile?

La mejor forma de explicarlo es el Agile Manifesto:

• Individuals and Interactions over processes and tools
• Working Software over comprehensive documentation
• Customer Collaboration over contract negotiation
• Responding to Change over following a plan

Si bien hay valor en los ítems de la derecha, preferimos los de la izquierda.

El Manifesto está basado en 12 principios:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Qué es lo que hacemos nosotros? Scrum? XP? Kanban?

Hay muchos flavors (formas) diferentes de Agile. Tal vez el más conocido de todos es Scrum. Cuál usamos en Tiendanube? Ninguno “de libro”. Tomamos prácticas de Scrum, de XP, Kanban … y las aplicamos de acuerdo a nuestro contexto. Lo que es importante de entender es que los principios si aplican de manera amplia a cualquier ámbito.

Agile Graph

Cómo están conformados los equipos?

Trabajamos en Squads! Pueden encontrar los detalles en nuestros lineamientos de construcción de equipos.

Autonomía alineada

Estos squads ejecutan con autonomía, pero cómo nos aseguramos que estemos todos tirando para el mismo lado?

Autonomía: sentirse libre para actuar al máximo de tus capacidades para contribuir a un resultado colectivo.

Pero cómo fomentamos la autonomía? Necesitamos alineación y competencia.

Autonomía: Alineación + Competencia. Alineación: Racional (Por qué?) + Intención (Qué?) + Límites (restricciones en el cómo).

Tomando el ejemplo de la imagen:

• Intención: Necesitamos cruzar el río.
• Racional: Porque hay tierras más fértiles del otro lado.
• Límites: No queremos matar a ningún animal.

Alignment enables Autonomy

Competencia: creencias de trabajo compartidas + excelencia técnica.

Esencialmente es confianza en que:

• Vas a decidir las cosas de una manera similar a la mía.
• Tenés más habilidades (o similares) para realizar la tarea.

Ciclos de seis semanas

Para cualquier equipo de producto, mientras más a futuro se planea, menos confianza hay que tener en el plan. Y planear muy hacia adelante tiene varios problemas. La complejidad del planning aumenta exponencialmente con la longitud del ciclo. Van a surgir cosas y vamos a tener que reacomodar, pero por otro lado vamos a sentir que le estamos faltando a promesas que hicimos en el pasado. El resto de la empresa se da cuenta rápidamente que los planes del equipo de producto no sirven y dejan de confiar en nosotros.

Por eso creemos que seis semanas es el tiempo ideal. Lo suficientemente corto para tener un grado de confianza alto y lo suficientemente largo para poder hacer algo relevante.

Separamos nuestra ejecución en dos semanas de planning y seis de ejecución. Al final de cada ciclo tenemos una demo para todo el equipo.

Planning

Ejecución de cada proyecto durante las seis semanas

Una vez que elegimos un problema para trabajar, separamos nuestra ejecución en diferentes fases:

1. Kick-off
2. Design
3. Build
4. Rollout
5. Learn

Todas estas fases las ejecutamos con sprints bi-semanales haciendo Scrum con algunas variantes.

Kick-off

Lo primero que hacemos es tener un Kick-off del proyecto con el equipo que va trabajar en la solución. Acá definimos dos cosas:

1. Qué problema queremos resolver y por qué?
2. Cómo vamos a medir si la solución resuelve el problema?

Esto lo hacemos porque creemos en que las mejores soluciones nacen cuando te enamorás del problema. La gran mayoría de las veces no solucionamos el problema de una, sino que tenemos que ir descartando soluciones hasta llegar a la mejor. Si estás enamorado de lo que creás (la solución) y hay que tirarla, te va a costar más que si estás enamorado de lo que querés resolver (el problema).

Design

Después del Kick-off, viene nuestra fase de diseño, donde nos gusta decir que es el lugar donde tiene que suceder toda la magia. Si, toda la magia. En lápiz y papel, sin siquiera tirar una línea de código o cortar una imagen. La gran mayoría de los desafíos técnicos de un proyecto se pueden resolver en lápiz y papel. Esto permite ahorrar mucho mucho mucho tiempo en la ejecución: no es lo mismo corregir un error de diseño con una goma de borrar, que teniendo que re-escribir parte de una aplicación. Esta fase incluye diseño tanto de UI/UX como de código.

También arrancamos diseñando siempre para un celular. Siempre. Hoy en Tienda Nube hay más ventas desde celulares que computadoras. Si arrancamos haciendo un diseño en computadora, ya estamos arrancando con el pie izquierdo: diseñando para la minoría de nuestros clientes. No pasamos feedback de un diseño hasta que no esté hecho en mobile. Una vez que tenemos una primera versión del diseño listo, pedimos feedback tanto internamente como a los clientes interesados en esa funcionalidad.

Build

Una vez que terminamos el diseño, nos concentramos en que los diseñadores y programadores puedan ponerlo en producción lo más rápido posible. Para eso, como en líneas generales la programación demora más que la UI, los diseñadores y programadores se ponen de acuerdo en un contrato que se va a respetar entre ambos (nombres de variables, tipo de variable, … ) para que los diseñadores puedan hacer un mock con el HTML/CSS final pero con datos “de mentira”. Esto nos permite levantar un entorno de staging donde cualquier persona de Tienda Nube y cualquier cliente nos puede pasar feedback.

Una vez que está todo finalizado, creamos el pull request en Github. No mergeamos hasta que no haya sido revisado por otra persona que no participó de la codificación y todos los tests estén en verde 💚.

Rollout

Terminada la codificación, comenzamos con el deploy en etapas. Por lo general definimos las etapas de la siguiente manera:

• Tiendas de miembros del equipo
• Beta testers
• Tiendas de clientes con pocas ventas
• Tiendas de clientes con muchas ventas

Para poder realizar esto, hacemos feature flagging donde básicamente deployamos la funcionalidad apagada para todos y la vamos liberando de a poco. Esto nos permite desactivarla rápidamente sin necesidad de deployar nada si sucede algún problema grave en producción.

Para ir avanzando entre fases, no solo miramos que el deploy haya salido bien, sino que, para los grupos que la están probando, se haya resuelto realmente el problema. Si obtenemos buen feedback, seguimos avanzando.

Learn

Pero la cosa no termina cuando salís a producción, recién arranca! Ahora todos nuestros clientes tienen una solución que nosotros pensamos que es la mejor para su problema. Pueden suceder diferentes cosas: a veces la solución es la correcta, pero la adopción es lenta; otras veces se adopta rápido pero recibimos feedback de que no solucionamos el problema. No nos movemos a otra cosa hasta que no nos aseguremos que la funcionalidad realmente solucione el problema.

Algunas veces incluso tenemos que volver al lápiz y papel y comenzar de nuevo. Y está todo bien, siempre y cuando hayamos aprendido algo. Traduciendo las palabras de Julie Zhuo: una buena ejecución es llegar a buenas conclusiones en la mínima cantidad de tiempo posible.

Nuestra estrategia de producto consiste en decir “No”

Hoy tenemos 30K clientes. Si cada uno tiene un problema (algunos no tendrán, otros tendrån más de uno, otros tendrán problemas compartidos) entonces tenemos 30K problemas que resolver. En los 6WC, es decir cada 2 meses, resolveremos 25 problemas. Es decir, resolvemos menos del 0.1% de los problemas de nuestros clientes.

Esto hace que Tiendanube a lo largo de su vida va a tener que priorizar. Por qué? Porque no tenemos un equipo que nos permita trabajar en 30k problemas. Tenemos que alinearnos en que esto va a ser así y en cuáles van a ser los criterios de priorización. Priorizamos por # de clientes? Por GMV? Por brands? Por clientes de parceiros top? Por revenue (no necesariamente es GMV, depende del rebate de GWs)? Cuál es la mejor definición customer-centric?

La respuesta es dificilísima. Tenemos que todo estar de acuerdo en que no vamos a poder hacer todo e ir construyendo juntos una definición. Mismo si tenemos equipos dedicados a cada área, vamos a tener que priorizar.

Cuáles son los problemas en los que queremos enfocarnos?

Si agarramos una lupa y examinamos las problemáticas que tienen diferentes Merchants vamos a ver dos grandes familias: problemáticas comunes (el 80% de lo que todos necesitan) y otras problemáticas particulares de cada uno.

Para que Tienda Nube pueda escalar de manera saludable decidimos enfocar toda nuestra energía en ese 80% que todos los Merchants necesitan (no el 80% de lo que las total transactions necesitan). Por ejemplo, tener una infraestructura que pueda procesar miles de pedidos por segundo es algo que todos los Merchants necesitan, entonces la construímos y se la ofrecimos a todo el mundo.

Eso significa que vamos a hacer todo Shipping en el core? No, vamos a hacer el 80% que todos necesitan.

Para ofrecer a nuestros Merchants ese último 20% de funcionalidades, construímos una API pública que permite a nuestros Partners ofrecer soluciones de altísima calidad a nuestros Merchants en forma de Apps. Para lograr implementar el 100% de las funcionalidades nos apoyamos en nuestro ecosistema!

Cuáles son entonces las áreas de trabajo y hasta dónde vamos a ir en cada una?

• Orders
• Catalog
• Payments
• Shipping
• Lending
• Checkout
• Sales Channels
• Storefront
• Themes
• Analytics
• Marketing
• Customers
• Billing
• Communication
  • Merchants team members
  • Merchants ← → Customers
  • Merchants ← → Partners
  • Merchants ← → Tiendanube
• Infrastructure

Es fundamental que estemos alineados en esto. Por qué? Imaginemos que le decimos que sí a todo o le decimos que sí a clientes que nos dicen que si no hacemos el feature:

• No migro a Tiendanube.
• Me voy de Tiendanube.
• Los prendo fuego en redes sociales.

Imaginemos que un cliente nos pide un feature, le decimos que lo hacemos y arrancamos. Otro cliente nos pide un feature, le decimos que lo hacemos y arrancamos. A los 10 clientes, no vamos a tener cómo cumplir la promesa sin faltar a las promesas anteriores. Unos años después y Tiendanube se va a ver así:

Es una relación basada en amenazas. Algún día uno de estos clientes se va a ir (porque no le vamos a dar algo) pero las funcionalidades que nos pidió para el producto se van a quedar. “Pero hagámoslo sólo por esta vez, es clave!”. Puede haber excepciones? Sí, claro. El problema es cuando escuchás esa frase 50 veces.

No hay soluciones sencillas

El tamaño del trabajo no debería ser motivo para incluir una funcionalidad en el producto. Si puede ser para subirla en el roadmap, pero es una decisión de roadmap, no de producto.

No hay cambios chicos o fáciles. Tomemos el ejemplo de “Agregar días de producción a un pedido” donde un cliente puede indicar que un producto demora X días en elaborarse para sumarle los días al envío y notificarlo al Consumer.

“Es solo agregar un campo en el formulario del producto y sumar los días al envío”. Correcto? Incorrecto.

1. Estamos agregando días, entonces no puede ser negativo, eso hay que validarlo en el formulario, así que tenemos que codear el backend y agregar tests de unidad para asegurarnos que no rompemos nada.
2. El campo es inherente al producto? O los días dependen de cada variante? Hay que hablar con merchants para entender mejor? Si ya habíamos arrancado a desarrollarlo por producto y nos damos cuenta que es por variante, perdemos días de ejecución.
3. Ya tenemos un mensaje de error cuando la cantidad de días es incorrecta? Hay que pasarlo por copy? Hay que diseñar el estilo del mensaje de error?
4. Hay que traducir todos los nuevos textos que agreguemos a la plataforma.
5. La validación la hicimos en el back end, pero también tenemos que hacerla en el front end. Vamos a mostrar el mensaje igual que al de backend? Son el mismo mensaje? El diseño es igual?
6. Los días que sumamos son días hábiles o días corridos? Depende del Merchant? Si depende, qué hacemos? Agregamos un campo adicional que nos digan si son hábiles o no?
7. El campo es un input o agregamos un select? Si es un select, qué días mostramos? Por qué?
8. Se tiene que ver bien en mobile y en desktop
9. Hay que destacar que el pedido está en producción en el detalle del pedido en el admin
10. Tenemos que agregar una columna en la base de datos

Y eso es solo el admin…

1. En la tienda tenemos que sumar los días de producción solo si el producto tiene esos días al cálculo de costo de envío
2. Si hay dos productos en el carrito uno con 5 días y el otro con 10 días, sumamos 10 o sumamos 15? Si justo son el mismo producto? Se hacen al mismo tiempo?
3. Si el medio de envío no devuelve fecha estimada, cómo lo mostramos?
4. Como dejamos claro cuál es el producto que tiene plazo de producción? Tal vez el consumer no quiere esperar ese tiempo y prefiere sólo sacar del carrito ese producto y no comprarlo
5. Si un pedido tiene producción y el otro no, el Merchant podría hacer dos envíos. Pero Tienda Nube no tiene modelado múltiples envíos por pedido. Tenemos que agregar el feature…

Imaginemos que hacemos todo y lanzamos, la rompimos! Correcto? Incorrecto.

1. Nos damos cuenta que el desarrollo está incompleto - No puedo configurar días desde la app mobile - No puedo actualizar los días de producción desde la carga masiva - La API no devuelve los días de producción del producto
2. Empiezan a llegar “bugs” - Mi envío se llama “Same day delivery” pero ahora dice “a veces” que llega en 5 días (porque el carrito tiene un producto que llega en 5 días de producción)
3. Rompemos apps - La app de “Avise me quando chegar” no maneja esta condición nueva y muestra el cartel para productos sin stock que se pueden comprar

Y estoy dejando de lado todo el costo de entrenar a CS en la nueva funcionalidad, acciones de comunicación del feature, trabajar en boostear el adoption de las personas que lo pidieron, …

Legenda de la imagene