Las claves para que tu startup supere obstáculos desde su inicio (a partir de la visión de un ingeniero)
Durante los últimos dos años, hemos charlado con centenares de CEOs, CTOs, CPOs, etc. de startups. Esto nos ha permitido realizar un análisis exhaustivo de empresas y trabajar de la mano de varios fundadores.
Gracias a estas interacciones, hemos descubierto patrones subyacentes que los unen. Por ejemplo, hay algunos detalles minúsculos en los que deben fijarse inicialmente o, de lo contrario, enfrentarán costos elevados más adelante.
Vamos a explorar en qué puntos es ventajoso fijarse desde un principio, sobre todo en lo que se refiera a las interacciones con los equipos de producción e ingeniería, y ofreceremos algunos conocimientos sobre por qué creemos que son importantes y nuestras recomendaciones para afrontarlos exitosamente.
Parte 1: vamos a hablar de aspectos relacionados con el gerenciamiento de la startup en su etapa inicial, cubriendo desde los roles y procesos hasta la contratación de colaboradores.
Parte 2: profundizaremos en temas como el manejo de roadmap, por qué tener procesos, definición de objetivos y cómo empezar a tomar decisiones de arquitectura de alto nivel.
Parte 3: finalmente, nos adentramos a temas más orientados a las buenas prácticas por parte de equipos de desarrollo y de cómo construir productos q sean amigables con la analítica desde el inicio.
PARTE 1
Aunque no tengas al personal y no te gusten las posiciones jerárquicas, tienes que establecer los roles
Las empresas de todos los tamaños se enfrentan a dificultades cuando piensan en las posiciones clave necesarias para crear un nuevo producto o servicio. CEO, COO, CFO, CIO, CTO, CSO, CRO, etc. son todas aquellas funciones importantes en las distintas etapas de los ciclos de vida de una empresa. Pero cuando estás creando una nueva startup, originalmente estás creando un nuevo producto. Es así, y por eso, para poder crear los pilares del producto y la empresa, los roles que necesitarás desde el principio son los de gestor de producto, director de ingeniería y director de crecimiento.
Normalmente, me gusta explicar sus interacciones usando un restaurante como analogía. ¿Por qué? Porque es una idea con la que todo el mundo puede puede relacionarse, sin importar de dónde vengan. Así que hacia allá vamos.
Producto: la zona de comedor
El producto es donde los usuarios interaccionan con tu oferta. Es donde se sientan, comen, hablan y se lo pasan bien, donde se celebran las bodas, cumpleaños, interactúan con el personal, pagan, dejan propinas y se van.
El gestor de producto (Product Manager) controla todo para asegurarse de esto sea posible y que sucede de la mejor forma viable, de modo que los clientes se sientan satisfechos usando el servicio y pagándolo. Toda la experiencia, desde la iluminación y música hasta cómo son recibidos los clientes, cómo se les cobra y cómo se les trata es la responsabilidad del gestor de producto.
Ingeniería: la cocina
Aquí es donde se prepara la comida. La comida tiene que estar lista para presentarse a la temperatura correcta, en el tiempo indicado y con la presentación más favorable.
Para conseguir esto, el personal de cocina tiene que saber cuántos clientes pueden sentarse en el restaurante, los ítems del menú para que puedan comprar el inventario y almacenarlo adecuadamente, qué días hay más tráfico en el restaurante para que haya más personal disponible, entre muchos otros aspectos.
Growth: la dirección
Esta analogía puede ser un poco más arriesgada pero déjenme explicarla. El director de crecimiento dentro de esta analogía con la restauración será el encargado de decidir qué tipo de restaurante es el idóneo para el barrio, cuánto debería costar la cena, qué otros restaurantes son la competencia, cuál es el mejor método para promocionar el sitio y cómo enganchar al cliente.
Los tres roles trabajan conjuntamente
La presentación del comedor del restaurante no importa si la cocina no hace bien su trabajo y los clientes no estarán satisfechos. Además, ni la cocina ni el menú tendrán la oportunidad de ofrecer y servir la comida que no tenga una buena valoración calidad-precio, o si no tienen los clientes adecuados.
No importa que la empresa no sea lo suficientemente grande, o si no te gusta desarrollar distintas tareas. Intenta encontrar maneras de desarrollar los tres roles principales y defender cada uno de sus intereses en cada decisión que tomes.
Al principio, contrata a personal multifuncional
Hemos visto en distintas ocasiones que las startups intentan tomar una de estas dos opciones, ninguna de ellas acertadas:
Startups que no tienen ingenieros o ningún miembro del equipo con conocimientos de ingeniería y contratan a servicios de desarrollo externos durante lapsos extendidos de tiempo
Está bien realizar una prueba de concepto con la ayuda de desarrolladores de empresas de terceros. Sin embargo, siempre deberías intentar tener un co-fundador con un perfil técnico que no sólo pueda coordinar con terceros y asegurarse de que las cosas se creen correctamente, sino que también sea alguien que esté completamente en línea y comprometido con la visión de la empresa.
No importa la confianza que te aporte la empresa de software, ya que su voluntad de trabajo puede cambiar cuando tu primer equipo de desarrolladores y/o CTO se una a la empresa, así que es mejor minimizar el impacto contando con gente en el equipo que tomen las decisiones principales desde un principio.
Startups que desean tener un equipo de especialistas cuando el producto aún no es lo suficientemente maduro
Por otro lado, están los fundadores o empresas que contratan a un equipo de especialistas. Contratan a arquitectos de sistemas, especialistas en front-end y back-end, expertos en UI (user interface), científicos de datos y expertos en ML (machine learning)…todo esto antes de crear el producto. A no ser que estés creando un producto analítico o basado en ML, o creando un producto basado en datos con datos de otra fuente, ¿para qué necesitas un científico de datos si aún no hay ningún producto que esté generando datos para analizar? Esto solo generará incomodidad, desgaste y el desperdicio de dinero sin retorno.
En lugar de esto, al principio, intenta contratar a ingenieros que sean flexibles y con recursos que puedan entender e identificarse con tu misión. Busca ingenieros full-stack que sean versátiles e intenta que puedan ser intercambiables. Cuando el negocio evolucione podrás centrarte más en habilidades más específicas, si es necesario. Pero intenta contratar a expertos especialistas cuando tengas lo que necesitan para llevar a cabo su trabajo.
PARTE 2
Sé pragmático en tus decisiones tecnológicas
Otro de los errores comunes en los equipos de ingenieros de empresas en su fase inicial es intentar seguir y adoptar las últimas tendencias tecnológicas del mercado. Aquí tienes algunos puntos a considerar cuando tomes esta decisión:
· Elige una tecnología que sea lo suficientemente madura para que puedas centrarte en construir tu producto y no en mejorar el de otros. Los nuevos marcos tecnológicos aún tienen muchos errores, funciones a medio desarrollar, cambios constantes y refractores que te fuerzan a cambiar constantemente y actualizar tu código para adaptarte. No tienes tiempo para esto. En esta fase tienes que moverte rápidamente y confiar en la tecnología que hay detrás.
· Para valorar la madurez de tu marco tecnológico, busca en sitios como GitHub (si el código está abierto) para comprobar la estabilidad de los distintos lanzamientos y la participación de la comunidad. Aléjate de los pre-lanzamientos, Alpha, Beta, etc. Tu Producto Viable Mínimo (MVP, en inglés) será lo suficientemente “Beta” para que tu equipo pueda trabajar con él.
· Asegúrate de que la tecnología que elijas sea lo suficientemente compatible y su uso esté extendido. Piensa que tienes que encontrar respuestas a tus preguntas y una buena base de desarrolladores (preferiblemente de una organización grande) la apoyen durante bastante tiempo. No quieres quedarte estancado con un marco tecnológico que ya no se use. Stackoverflow es un buen sitio para valorar qué tan activa es la comunidad, qué tan rápido se solucionan los problemas y la calidad del servicio de atención al cliente.
· Recuerda que vas a tener que contratar a personal para hacer crecer tu equipo, y muchas veces en un lugar geográfico específico. Asegúrate de que podrás encontrar buenos desarrolladores a precios razonables.
Stackoverflow, Angelist y otras plataformas de ofertas de trabajo son buenos sitios para valorar la disponibilidad de talento. También consulta con empresas de creación de software que ofrezcan servicios en esa tecnología: pide presupuestos y disponibilidad local.
· Elige una herramienta que encaje con tus necesidades a corto y medio plazo. No elijas una herramienta sólo porque sea nueva y atractiva, o porque sea la más efectiva (y compleja) a no ser que la eficiencia sea clave para tu negocio.
Es muy importante usar las herramientas con las que tu equipo tenga mayor experiencia al principio, pero también intenta determinar si éstas son las mejores herramientas que te permitirán navegar tu espacio rápidamente. Puedes mirar sitios como Stackshare y ver qué están usando otras empresas o si algunas empresas usan cualquier otra herramienta.
No odies el proceso
Muchas veces, vemos a CEOs y CTOs respondiendo preguntas sobre los procesos relacionados con priorización del plan de acción, resolución de problemas, fin de uso de herramientas, resolución de errores (bug fixing), etc. con respuestas del tipo “no lo necesitamos/no lo tenemos aún” o “cuando tengamos un equipo más grande, nos ocuparemos de eso”.
Estas respuestas contradicen un malentendido común acerca del proceso. Está claro que quieres evitar sobrecargar o realizar demasiada ingeniería en cosas. Muchos procesos están puestos en marcha para la microgestión, para dar a los directivos una sensación de control y tener datos sin hacer que las tareas sean más fáciles para nadie. Estos son procesos a evitar. Pero hay otros procesos que harán que facilitarán tu vida, ofreciendo una dirección sobre cómo reaccionar en ciertas situaciones y delegar tareas entre los miembros del equipo.
Procesos críticos como la priorización de funciones, servicio de atención al cliente, resolución de errores, integración y despliegue continuo, soporte, recuperación en caso de desastres, etc. no tienen que ser más complicados. Además, si empiezas pronto y piensas en términos de los roles involucrados y no necesariamente en gente específica, será más fácil mantenerlas vivas y sanas en el largo plazo. La implementación de procesos sencillos desde un principio crea la base para una organización ágil y escalable. Si intentas esperar hasta que tengas un equipo grande para esto, será 10 veces más difícil.
Asegúrate de realmente entender qué es el Producto Viable Mínimo (MVP, en inglés)
El “Producto Viable Mínimo” es un concepto omnipresente y aun así muchas veces malinterpretado. Vamos a explorar el concepto para que quede claro.
Siguiendo el libro de Eric Ries, The Lean Startup y MVP se refiere al “mínimo esfuerzo necesario para conseguir que un cliente use un producto para que puedas aprender sobre un objetivo específico.”
Podemos desarrollar este concepto un poco más, las 3 partes de este concepto que deberían estar presentes para que valga la pena son:
- Mínimo: el mínimo esfuerzo y/o dinero necesario para conseguir la función deseada. Esto incluye al menos una instrumentación rudimentaria para poder medir el uso del producto.
- Viable: capacidad de funcionar adecuadamente, y también tener una posibilidad razonable de éxito. Tiene que satisfacer las necesidades básicas de la persona que lo use.
- Producto: ¡TIENE QUE SER UN PRODUCTO! Puede que no corresponda con lo que te imaginaste o soñaste, pero tiene que solucionar algo para el cliente: una necesidad, un deseo, algo que les de satisfacción.
Incluso si seguimos los consejos de Reid Hoffman y aceptamos sentirnos avergonzados por nuestro PMV, tiene que ser útil o satisfacer a nuestros clientes. Quizá se aguante por los pelos desde nuestro punto de vista, pero los clientes no deberían notarlo.
No reinventes la rueda
Un aspecto importante del trabajo que hacemos con startups es analizar el roadmap del producto. Cuando hacemos esto, a menudo nos encontramos con los siguientes aspectos:
· “Crea herramientas avanzadas de analítica y dashboarding”
· “Itera en nuestra gestión interna de lanzamiento de software”
· “Crea un modelo de trabajo de pruebas A/B”
· “Crea una plataforma de gestión de tareas”
Todas estas características, por importantes que sean, probablemente no van a crear tu oferta de producto principal, así que no pierdas tus recursos de desarrolladores en estos puntos. La mayoría de empresas que ofrecen estos servicios tienen un plan de inicio con fondos que te ayudará a lanzarte y empezar a operar. Piensa en “comprar” en vez de “crear”.
Esto no significa que deberías olvidarte completamente del coste total de propiedad. Aunque parezcan muy generosos, algunos de los modelos de precios no serán adecuados ni para ti ni para tu modelo de negocio. Haz un poco de cálculos y pregúntate “¿Qué pasaría si consiguiera 10 veces más usuarios (o tráfico o transacciones)?” y eval’ua nuevamente si aún tiene sentido. Esto también es aplicable a encontrar versiones de código abierto de la herramienta A o B y probarlas tú mismo (o, en el peor de los casos, copiar un proyecto de código abierto). Recuerda que deberás almacenar y gestionar este servicio. La mayor parte del tiempo, llegarás a la conclusión de que es mejor usar el servicio (SaaS) de otro en vez de crear el tuyo propio.
Asegúrate de establecer objetivos comunes
Puedes hacer uso de OKR (objetivos y resultados clave), WIG o el marco de trabajo que prefieras, pero, asegúrate de que tus objetivos sean claros, fáciles de comunicar, sencillos de realizar un seguimiento y control y que puedan ser identificables y aplicables a todos los equipos de la empresa.
Sin objetivos claros, verás cómo los equipos no siempre trabajan hacia una misma dirección, las distintas áreas parecen contradecirse y hay una desconexión entre las prioridades y los pasos a seguir para alcanzar dichos objetivos.
Todas las metas y objetivos deben estar basados en los objetivos finales de tu empresa, y los objetivos o metas de cada empleado deben ser fácilmente rastreados hasta uno de sus objetivos principales.
Asegúrate de mantenerlos actualizados cuando las circunstancias cambien, ya sean descubrimientos o cambios en el mercado. A medida que los actualices, asegúrate de hacer públicas las razones para cambiarlos, a fin de que todos puedan participar.
PARTE 3
Recuerda que la autenticación no es lo mismo que la gestión de identidades.
Muchos de nosotros confundimos la autenticación (asegurarse de que un usuario tenga las claves correctas para iniciar sesión) con la gestión de identidades (identificar a usuarios únicos, de dónde vienen, y sus preferencias y relaciones).
He visto muchas veces como las startups adoptan el inicio de sesión de Facebook o de Google para obtener el token, y luego se quedan ahí sin rastrear activamente ni tratar de entender quiénes son los usuarios.
Los inicios de sesión externos pueden ayudarte a comenzar rápidamente, pero dificultarán segmentar y crear perfiles en el largo plazo. Si utilizas estas herramientas, asegúrate de pedir los permisos adecuados para obtener los datos que necesitas sobre tus clientes. Después, podrás desplegar herramientas para comprender quiénes son y cómo llegar a ellos.
Cada acción que un usuario ejecute en tu servicio debe ser rastreable a un único perfil de usuario en su repositorio de datos. Esto incluye no sólo los datos transaccionales en su back end, sino toda la interacción del usuario en su plataforma: clics, conversiones, notificaciones push, correos electrónicos salientes, solicitudes al servicio de atención al cliente, etc.
No aisles tus datos
La mayoría de emprendedores probablemente ya estén entusiasmados con todas las posibilidades que ofrece la recopilación de datos, pero lamentablemente no es tan simple.
Como mencionamos anteriormente, en este nuevo mundo digital los datos están siendo generados a todos los niveles por diferentes subsistemas: identidad, rendimiento de la API, atribución, flujos de navegación, análisis de aplicaciones, tasas de clics, círculos sociales, etc.
Todas estas suceden en relación unas con otras en el mundo real, pero en el digital los diferentes sistemas están recogiendo y almacenando los datos en sus propios repositorios cerrados. ¿Por qué separarlos si su objetivo es analizarlos? Bueno, la mayoría de estas herramientas quieren bloquear a los clientes mediante el bloqueo de los datos y proporcionar sus propios análisis y recomendaciones.
En la mayoría de los casos eso no es bueno. El beneficio de correlacionar todo esto es que te ayudará a entender por qué suceden las cosas y cómo influir en ellas. Busca herramientas o soluciones que te permitan exportar e integrar datos de múltiples fuentes de diferentes maneras.
Concéntrate en crear flujos de eventos a nivel de cliente porque son la base para aprender la historia completa. Más allá de los meros datos demográficos y agregados, los datos a nivel de cliente te ayudarán más cuando trates de entender y replicar -o evitar- ciertos comportamientos de los usuarios. Centraliza, correlaciona tus datos y sigue el flujo.
Piensa en la recopilación de datos desde un principio
Tus usuarios interactúan con tu producto de distintas formas:
· Se enteran de la existencia de tu sitio/app
· Navegan hacia tu producto de algún modo
· Hacen cosas dentro del producto
· Reciben e interactúan a través de correos electrónicos, SMS o notificaciones push
· Experimentan caídas o problemas con el servicio
· Se ponen en contacto con el servicio de atención al cliente
· …y generan tus acciones clave
Todas estas interacciones generan datos valiosos. Asegúrate de que todo está siendo registrado y trazado correctamente a un usuario. Esto te ayudará a entender mejor a tus usuarios y a satisfacer sus necesidades de forma proactiva.
Imagina los siguientes escenarios:
· Un usuario se pone en contacto con tu servicio de atención al cliente por tercera vez en relación con un mal funcionamiento de tu aplicación. Ves las solicitudes, pero no entiendes la causa de fondo. Después de un tiempo, cuando finalmente descubres lo que pasó y tratas de contactar al cliente y explicarle que todo está resuelto, el cliente ya no está contento con la experiencia. ¿Qué crees que se podría haber hecho mejor? Imagina todas las oportunidades que tuviste para ofrecer un mejor servicio. Ahora vamos a trabajar con un escenario mejor:
o Cuando el usuario crea su cuenta, puedes atribuirla a una campaña o canal en particular, de modo que obtengas alguna información sobre su perfil y saber cuánto pagaste para adquirirla.
o Tu usuario genera una gran cantidad de datos por su uso frecuente del servicio y queda registrado en el sistema como un usuario valioso. Puedes ver cuánto valor ha generado hasta ahora y cuál es su potencial.
o Estás usando una herramienta APM (como NewRelic) o una herramienta de gestión de errores (como Sentry). Todas estas herramientas están generando datos relacionados con el rendimiento o las caídas y vinculándolos a un único ID de usuario.
o Cuando el usuario se pone en contacto con tu servicio de atención al cliente, el sistema comprueba sus últimas transacciones y problemas. Así que en vez de perder el tiempo tratando de averiguar qué pasó, le preguntan si está llamando en relación a su último “incidente” y le hacen saber que ya se ha creado una solicitud al respecto, y que te pondrás en contacto con él cuando haya una resolución.
o Tan pronto como el problema se resuelva o se entienda, se actualiza el estado de la solicitud, que genera un mensaje automático al usuario con una explicación y un cupón de descuento gratuito en compensación por los problemas causados.
o El sistema agrega al usuario a un grupo específico de clientes que tenían problemas y recibieron dicho tratamiento para ver cuánto más o menos leales son en comparación con otros usuarios que experimentaron problemas similares, pero nunca contactaron al servicio de atención al cliente.
o Todo esto te permitirá entender si todo este esfuerzo se amortiza en términos de LTV, NPS, viralidad, etc. para que puedas reducirlo o tratar de automatizarlo todo y para que los usuarios no tengan que contactar al centro de atención al cliente.
· Estás pensando en construir una versión web para móvil de tu aplicación, ya que has tenido algunos comentarios de que tu aplicación nativa es un poco grande (en tamaño) y estás obteniendo muchas desinstalaciones en algunos mercados.
o Tus aplicaciones están correctamente instrumentadas para que puedas seguir cada interacción de tus clientes con tu aplicación añadiendo muchos metadatos en el proceso. Estos metadatos incluyen el modelo de teléfono, la versión del sistema operativo, el tamaño de la pantalla, etc.
o También puedes hacer un seguimiento de la disponibilidad de la red. ¿Tus clientes utilizan tu servicio principalmente en redes wifi o móviles?
o Tu herramienta de notificaciones push te permite saber quién de tus clientes puede haber desinstalado tu aplicación.
o Tu análisis de contabilidad de crecimiento muestra que muchos usuarios reactivados hacen un par de transacciones y luego vuelven a dejar de usar la aplicación por un tiempo hasta que algunos de ellos la vuelven a usar.
o Con todo esto llegas a las siguientes conclusiones:
1) En algunos mercados emergentes, el tamaño de tu aplicación es un problema. La mayoría de los dispositivos son Android de gama baja con poco espacio de almacenamiento, y los usuarios prefieren las imágenes a tu aplicación. Pero como todavía lo disfrutan, lo descargan de vez en cuando. Además, te das cuenta de que tu aplicación nativa actual no está realmente optimizada para dispositivos con pantalla pequeña.
2) La mayor parte del uso es con wifi, esto significa que los clientes son probablemente de prepago, y utilizan sus datos con cuidado.
3) Su aplicación no funciona en absoluto cuando no hay conexión de datos, a pesar de que cierta información no depende totalmente de la disponibilidad de los datos.
4) El mejor escenario sería una aplicación PWA centrada en Android que ocupe poco espacio. Tendría alguna funcionalidad fuera de línea disponible y capacidad de detección de datos, para obtener información más intensiva de datos cuando está en wifi.
La mayoría de estos análisis no serían posibles sin un enfoque centrado en la recopilación de datos y una gestión adecuada de la identidad.
Piensa que algún día necesitarás escalar eficientemente.
No es raro que cuando las cosas empiecen a escalar, los equipos altamente centrados en los datos empiecen a tener grandes problemas con la ingeniería. Su deseo de más análisis, más predicción, más recomendaciones en tiempo real hace daño a las capacidades transaccionales del sistema. Si esto te suena, significa que tu capa analítica está estrechamente acoplada a la capa transaccional, lo cual es realmente malo.
Intenta trabajar desde un principio separando por capas, para crear copias de lectura o bases de datos de lectura replicadas en tiempo real, así evitarás reducir el rendimiento cuando realices una extracción de datos pesada. Además, puedes incluso separar las transacciones RFI (solicitud de información) de las operaciones RFC (solicitud de cambio) para que puedan crecer y escalar fácilmente los aspectos de tu arquitectura que están sufriendo.
No sobrecargues tu aplicación con funciones de terceros (si es posible)
Un momento, ¿no acabo de decir que necesitamos reunir el máximo de información posible? ¿Y que deberíamos usar lo que ya está ahí fuera? ¿Cómo es que ahora me dices que no sobrecargue mi aplicación?
Es cierto que la mayoría de estas herramientas de recopilación de datos requieren la instrumentación de tu aplicación. Todos ellos proporcionan algunos SDKs que son la única manera de recopilar datos en tus plataformas (aparentemente). Esto conduce a algunos inconvenientes desafortunados:
· Tu aplicación se hace cada vez más pesada. A veces he visto aplicaciones que tienen más código de terceros que el suyo propio.
· Cada SDK envía una copia de todos los eventos a su nube: no es muy eficiente para los usuarios que quieren guardar datos e incluso puede hacer que su aplicación sea más lenta.
· Cada vez que cambias un SDK, necesitas ejecutar y actualizar tu aplicación (volver a enviarlo al mercado).
· Si cambias un evento o añades otros nuevos, debes actualizar varios SDK y asegurarte de que lo has hecho bien.
Afortunadamente, existen herramientas que se encargan de estos problemas y que te permiten instrumentar la aplicación una sola vez y luego utilizarla para enviar los datos a una única ubicación (o proxy) que se asegurará de que se replique a todos los diferentes servicios que te gustaría utilizar. Esto resuelve muchos de los problemas que mencionamos anteriormente:
· El tamaño de la aplicación se minimiza, ya que sólo necesita incluir un SDK e instrumentarlo siguiendo las mejores prácticas. Lo más probable es que puedas utilizarlo para la mayoría de las soluciones que existen.
· Todos los eventos van a una ubicación centralizada y desde allí se distribuyen a múltiples puntos finales.
· Si un endpoint cambia, no tienes que preocuparte, en la mayoría de los casos el proveedor se encargará de ello en la nube, no en tu aplicación.
· Si se modifica un evento o movimiento, sólo se actualiza una vez.
· Y como bono, puedes crear una copia local de todos los eventos de todas las fuentes en tu propio repositorio, para resolver el problema del aislamiento de datos que discutimos anteriormente.
Hay varias opciones aquí como Segment, M-Particle […] etc. Sólo ten cuidado porque el precio (tu costo) aumentará con el número de usuarios. Si esto es un problema, siempre se puede bifurcar el proyecto de código abierto de Segment y hacer todo el trabajo pesado por ti mismo 😉 .
Facilita la disponibilidad interna de los datos
Recuerdo mucho tiempo atrás, durante mi vida empresarial anterior, que el acceso a los datos estaba restringido a un grupo muy selecto de personas. Era un privilegio que había que ganarse y tenía capas… muchas capas.
¿Cómo esperas alinear a tu equipo? ¿Cómo confiarás en que están haciendo el mejor uso de su tiempo? ¿O construyendo las funciones correctas? Si no confías en alguien de tu equipo con los datos necesarios para entender tu negocio, no deberían ser parte de tu equipo desde un principio.
La etapa inicial es el momento clave para construir tu equipo principal, tus valores, tu cultura. Todo esto debe basarse en la confianza.
Si compartes tus datos, tus percepciones y tus conocimientos, tu equipo podrá concentrarse mejor y asignar su tiempo, y por qué no, tal vez incluso desafiar algunas de esas percepciones.
Para construir una cultura con base en data, todo el mundo necesita estar basado en data. Debes usar tus propios datos para tus operaciones internas, en inglés “eat your own dog food”.
Una empresa basada en datos no debería tomar decisiones por pura intuición. Siempre trata de usar los datos, explica cómo los lees y a qué conclusiones llegas.
Si tienes una reunión para discutir un cambio en el producto, empieza explicando tu hipótesis, qué datos podrían utilizarse para probarlo y por qué. Lidera con el ejemplo; si no sigues estas reglas y disparas en cualquier dirección en la que sopla el viento, tu equipo intentará hacer lo mismo o dejará de escucharte.
Si no usas los datos, pasarás todo el tiempo buscando respuestas en lugar de usar los datos que tienes disponibles para encontrarlas.
Este post ha sido largo mas largo de lo que esperaba. Sin embargo, he omitido muchas ideas sobre priorización, visión del ecosistema, prácticas de total honestidad, etc. Así que, si te gustó este post, házmelo saber para que podamos seguir indagando.
