Cuando GrubMarket adquirió Butter, marcó el final de un capítulo y el comienzo de otro. Como fundador, el recorrido fue increíble, lleno de lecciones aprendidas con esfuerzo y, a veces, dolorosas. Ahora, quiero compartir algunas de esas ideas, para que, con suerte, puedas sortear algunos de los obstáculos que encontramos al crear tu próxima startup. Nuestra historia de origen Cuando estalló la pandemia en 2020, mi cofundador y yo lanzamos Butter, reconociendo una oportunidad sin explotar en la industria alimentaria. Los confinamientos estaban impulsando a las empresas a adoptar soluciones digitales (softwares como Toast, DoorDash y Shopify estaban experimentando un crecimiento explosivo) y creíamos que la pila tecnológica de la cadena de suministro de alimentos estaba madura para ser disruptiva con el viento de cola digital de la COVID. Se destacaron dos problemas importantes: Los chefs seguían pidiendo los ingredientes a la antigua usanza: con un portapapeles, guías de pedidos en papel y llamando o enviando mensajes de texto a sus proveedores. Después de todo eso, a menudo no tenían idea de lo que llegaría a sus cocinas hasta la mañana siguiente. ¡Imagínese el estrés diario de preocuparse por si realmente podrá servir ese chuletón o cioppino en su menú! Los mayoristas, los proveedores de los chefs, estaban aún peor sin la tecnología moderna. Utilizaban tecnología sacada directamente de la década de 1990: entrada manual de pedidos a partir de mensajes de texto o mensajes de voz, sistemas ERP DOS obsoletos y seguimiento de recuentos de inventario en hojas de cálculo de Excel. Los pagos todavía se gestionaban principalmente mediante cheques en papel. El simple hecho de introducir los pedidos de los clientes en sus sistemas podía consumir , tiempo que podrían dedicar a hacer crecer sus negocios. seis horas de su día Pasamos unos meses observando los flujos de trabajo de los proveedores a las 3 de la mañana y pensamos que teníamos la respuesta. Nuestro plan consistía básicamente en 3 componentes: Modernice sus sistemas obsoletos con un ERP en la nube todo en uno que pueda capturar los flujos de trabajo centrales y servir como su “ ” – lo que nos proporciona un nivel de adhesión y compromiso extremadamente alto; sistema de registro Integrar servicios financieros como pagos, préstamos, nóminas, etc. para aumentar drásticamente el ACV de un cliente (a16z famosamente sobre la nueva ola de SaaS vertical potenciada por servicios financieros en 2020, por lo que nos sentimos confiados); presentó un artículo Presentar un proceso de comunicación fluido tanto para chefs como para mayoristas, con una aplicación similar a DoorDash para realizar pedidos que atraería a más vendedores a la plataforma, creando un efecto de crecimiento de red de volante (mentiría si dijera que no nos influyó Choco, otra aplicación de pedidos). ); Ascenso meteórico al estatus de unicornio Parecía una obviedad, pero estábamos equivocados, muy equivocados. Error 1: complejidad de ingeniería y personalización Pensamos que construir un ERP moderno sería fácil. Los sistemas antiguos estaban obviamente obsoletos: ¿qué tan difícil podía ser construir algo mejor? Hicimos una demostración del prototipo a algunos clientes locales y recibimos ofertas de prueba, así que decidimos acelerar el proceso de construcción. Sin embargo, la siguiente fase resultó ser una lucha inmensa. Si bien eliminamos algunos de los problemas técnicos de los clientes, como el riesgo de fallas en los servidores locales, las demandas de la industria eran mucho más variadas de lo que habíamos imaginado. Cada posible proveedor tenía requisitos específicos para la implementación: atajos de teclado personalizados para cada acción, diseños de columnas exactos en las pantallas de ingreso de datos, formatos únicos para facturas e impresiones de almacén e incluso los detalles que se deben mostrar en las etiquetas de trazabilidad de mariscos. Cada personalización se convirtió en un agujero negro para los recursos de ingeniería. Lo que pensábamos que sería una solución optimizada se convirtió en un producto altamente personalizado que necesitaba constantes ajustes y ciclos de desarrollo para satisfacer las necesidades de cada cliente y asegurar el próximo acuerdo incremental. Nuestro presupuesto de ingeniería se disparó mientras intentábamos mantener el ritmo. La cuña que esperábamos resultó ser una bestia descomunal. No iba a escalar. (Aparte: Hace poco vi de YC para nuevos software ERP. Por favor: piénsenlo muy bien si quieren meterse en esa madriguera de conejo). el RFS Trampa 2: El largo ciclo de ventas Cambiar un sistema ERP no es como actualizar el software de tu teléfono: es más como una cirugía a corazón abierto, donde hay una operación viva y palpitante en la que influirás en cada una de sus facetas, desde el almacén, las compras, hasta la contabilidad y los departamentos de ventas. Los clientes potenciales dudaban porque sabían lo disruptivo que podía ser el proceso. Muchos pospusieron la decisión todo lo posible, a pesar de que sus sistemas actuales claramente les estaban costando tiempo y dinero. Incluso cuando los propietarios (a menudo el principal comprador económico) querían cambiar, el complejo flujo de trabajo implicaba que necesitaban la comodidad y la aceptación de todos los departamentos, lo que prolongaba enormemente el proceso. Quizás también debido a los flujos de trabajo tradicionales, la mayoría de los distribuidores y mayoristas de alimentos a los que nos dirigimos apenas podían mantenerse a flote, y mucho menos comprar activamente nuevos programas informáticos. Esto es especialmente malo durante las temporadas altas de los restaurantes (sus clientes finales), lo que básicamente limita nuestra ventana de ventas dorada a principios de la primavera y mediados del otoño. Este largo ciclo de ventas y adopción fue un problema para nosotros. Aunque ofrecimos una mejora clara, conseguir que las empresas se lanzaran a la aventura siempre fue una batalla cuesta arriba, especialmente cuando se trataba de sus operaciones principales. Incluso hacia el final, nuestra tasa de cierre de acuerdos fue de 1/5 a 1/3 de nuestro objetivo modelo. Demasiados trabajos en curso, muy pocos acuerdos cerrados. Error 3: Baja disposición a pagar / Largo período de activación de ingresos El mayor impacto se produjo con el precio. Muchas de estas empresas tenían márgenes muy estrechos, a menudo tan bajos como el 5%, como mucho. Para la gran mayoría de ellas, lo único que les importa son , por lo que ofrecerles algo menos que eso suele ser difícil. Estaban acostumbrados a pagar 80 dólares al mes por QuickBooks, y conseguir que pagaran una actualización completa de ERP a un precio que justificara nuestros costes de desarrollo fue un gran desafío. los ingresos Esperábamos que los componentes de la aplicación fintech y de pedidos expandieran enormemente el ACV de cada cliente más allá de la suscripción SaaS tradicional, y lo hicieron... solo en el papel. En realidad, la activación de los ingresos por pago/uso de la aplicación también llevó demasiado tiempo, ya largo ciclo de ventas de ERP detallado anteriormente. Tanto en el frente de pago como en el de la aplicación de comercio electrónico, la adopción terminó dependiendo más de la preferencia de los clientes finales de restaurantes/minoristas, que también es de la vieja escuela. Los proveedores no querían obligar a los clientes a pagar con tarjeta de crédito, y muchos clientes seguían prefiriendo obstinadamente llamar o enviar mensajes de texto para hacer pedidos debido a la (posiblemente falsa) sensación de seguridad de que estarían mejor atendidos de esa manera. además del Resultado final: por lo general, se necesitaron dos o tres meses de esfuerzo intenso para alcanzar el 20 % o 30 % de adopción objetivo y generar ingresos adicionales. Es simplemente demasiado esfuerzo para muy pocos ingresos. Error 4: demasiadas apuestas a la vez Finalmente, nosotros como organización también sufrimos por tener demasiadas apuestas simultáneas a la vez. Omitiré algunos detalles aquí, ya que este artículo tiene como objetivo destacar los problemas clave encontrados y las lecciones aprendidas, no relatar paso a paso todos los experimentos que hemos intentado a lo largo del viaje. Baste decir que no logramos encontrar una verdadera cuña antes de intentar desbloquear también flujos de ingresos adicionales y efectos de red de volante de inercia. Estábamos luchando en una campaña a gran escala en tres frentes, cuando deberíamos habernos quedado en modo de guerra de guerrillas para asegurar una única victoria importante. Este problema de ejecución significó que no podíamos probar rápidamente las hipótesis de manera iterativa y el equipo comenzó a agotarse. Todavía quedaban varias hipótesis por probar cuando llegó la oferta de adquisición, como avanzar en la cadena de suministro de alimentos, donde los mejores márgenes comerciales pueden generar mayores ACV, o escalar el movimiento de salida al mercado para nuestros nuevos productos ligeros en cuña impulsados por IA, pero después de casi 4 años de desarrollo, decidimos llevar nuestros productos y tecnología a alguien con un canal de distribución ya establecido. Lecciones que aprendimos a las malas No me malinterpreten: el equipo y yo hicimos muchas cosas de las que estoy orgulloso: levantarnos a las 2 a. m. y literalmente dormir en almacenes durante semanas para garantizar una incorporación exitosa, desarrollar un software altamente complejo pero a la vez intuitivo que los clientes adoran, desarrollar un manual de implementación riguroso, y la lista continúa. Sin embargo, en el gran esquema de las cosas, no logramos construir una empresa de riesgo que realmente pudiera escalar. Nuestra experiencia nos enseñó una gran lección: no hay que lanzarse a una idea basándonos únicamente en tesis de alto nivel. Hay que escuchar lo que tienen que decir las personas que trabajan en el terreno, en el almacén y en la trastienda: hay que hablar con la gente para buscar la verdad, no para reafirmar ideas preconcebidas. Para crear un producto exitoso, especialmente en las industrias de la vieja escuela, se necesitan estas cosas: **Personas que se preocupan profundamente por el problema.** Si el dolor de seguir igual no supera la fricción del cambio, nadie se molestará en cambiar de sistema, sin importar cuán bueno sea su producto o cuán grandiosa sea su visión. La inercia es poderosa, pero el cambio solo necesita unos pocos catalizadores. **Bolsillos lo suficientemente profundos.** Si sus clientes no pueden costear la solución, todo el valor que usted aporta no compensará sus resultados finales. Cuanto más tradicionales sean sus clientes, más drástica debe ser la mejora. Aborde los problemas más difíciles de su mundo porque hay una razón por la que han permanecido con usted durante tanto tiempo. Una experiencia de producto diez veces mejor que la que ya tienen. Su producto de cuña inicial debe ser extremadamente fácil de adoptar y cubrir una sola unidad básica del cliente. ¿Está vendiendo un elegante bidé japonés o está reemplazando toda la plomería? La simplicidad es fundamental. Algunas notas más matizadas: no digo que su startup fracasará sin todos los criterios anteriores, pero su presencia en conjunto generalmente significa un claro camino ganador. Para explicarlo mejor, para que una startup SaaS tenga éxito, el tamaño de los acuerdos debe ser proporcional al tiempo necesario para cerrarlos. En su artículo “ ”, David Sacks introdujo el cuadrante tamaño de la operación/tiempo de ciclo para ayudar a visualizar claramente la relación. Te recomiendo que lo leas en su totalidad, pero el resumen es que un ACV alto y una velocidad de operación baja o viceversa pueden estar bien, pero que ambos sean bajos significa la muerte de tu empresa. La relación de dificultad Volviendo a los cuatro criterios anteriores, si sus clientes objetivo no tienen los bolsillos lo suficientemente profundos, pero usted tiene un producto innovador con un ciclo de ventas e incorporación breve, entonces puede ganar en la categoría de PYMES con una velocidad de transacción rápida. Si, por otro lado, su producto es complejo pero ofrece propuestas de valor distintivas por las que los clientes están dispuestos a pagar un precio superior, puede conseguir acuerdos importantes en el cuadrante empresarial. En el caso de Butter, sin embargo, desafortunadamente caímos en el cuadrante de muerte de velocidad de negocios lenta + ACV bajo (para ser precisos, el ACV no fue terriblemente bajo considerando los flujos de ingresos adicionales, pero la velocidad de negocios con el cronograma de activación de ingresos completo no solo fue lenta, fue muy lenta). Pensamiento final En retrospectiva, subestimamos la complejidad de desarrollar un SaaS vertical en un espacio que depende de prácticas profundamente arraigadas y tecnología obsoleta. Pensamos que ofrecer una solución digital sería suficiente para impulsar la adopción. En cambio, aprendimos que es necesario demostrar que el producto puede ofrecer mejoras importantes en lo que ya tienen, de la manera que ellos entienden, para satisfacer sus necesidades, porque si no se destaca de inmediato como una buena opción, se quedarán con lo que conocen. Manténgase atento a la Parte 2, donde profundizaré en cómo la IA está abriendo nuevas oportunidades que en estos espacios de la vieja escuela, y cómo la estamos usando para resolver callejones sin salida. funcionan
