Autor: Diego Mariño

Product Briefing

~ Diego Mariño

A menudo recibo «preguntas del millón» para las que no tengo respuesta. «¿Dónde encuentro (cerca de este código postal, a poder ser) product managers con años de experiencia, solvencia técnica y sensibilidad comercial?, suele ser una de las más escuchadas. Otra es: «¿cómo transiciono mi empresa que ha sobrevivido a base de consultoría+licencias a ser una empresa de producto?». Y sobre las respuestas a esta pregunta vamos a hablar hoy.

Lamentablemente, por si alguno quiere ahorrarse minutos de lectura, no hay una respuesta generalmente válida para todas las empresas que quieran pasar por este trance. Cada cultura y organización son un mundo que requieren ser entendidos en detalle en su contexto. No hay balas de plata, más allá de recordar que no hay transición sin fricción, y por tanto daños. Por tanto, think it twice. La hierba verde del vecino, el cementerio lleno de empresas de consultoría rentables que un día empezaron a soñar con la escalabilidad a coste marginal nulo y todo eso.

Así que en estas ocasiones en las que alguien se acerca preguntando :»¿cómo puedo acabar teniendo ‘una empresa de producto'», mi respuesta (gallega, por supuesto) es: «¿por qué no empiezas escribiendo un product briefing?».

Así que aquí viene una aproximación rápida, con el necesario disclaimer de que uno tiene su experiencia en el fascinante mundo del SaaS B2B y para otros sectores/modelos todo probablemente sea muy diferente.

¿Qué es un “product briefing”?

Llamaremos “product briefing” (PB) a un documento que resume la estrategia y planificación detrás de un producto, con un formato y contenido dirigidos a ser consumidos por cualquier empleado o stakeholder.

Su principal objetivo es responder a cualquier pregunta derivada de:

¿Por qué es un buen uso de los recursos de la empresa el trabajar en este producto (o gran funcionalidad) de este modo en este momento?

El PB debiera mantenerse actualizado con mínimos cambios, pero sería muy mala señal necesitar a menudo cambiar el contenido (bien porque el documento se ha compartido mucho antes de tener resueltas incógnitas relevantes, bien porque la dirección de producto es demasiado inestable manteniendo las decisiones acordadas).

Las principales ventajas que se obtienen de escribir un PB son:

  1. Obliga al liderazgo de producto a sintetizar sus ideas estratégicas en un único documento.
  2. El PB nos permite compartir esta estrategia con toda la organización para alinearla hacia los objetivos.
  3. El hecho de sintetizar y compartir esta estrategia reduce en magnitudes los «conflictos políticos internos» a gestionar. Ya tú sabes.

¿Qué *no* es un Product Briefing?

Al ser principalmente un documento que recoge las decisiones estratégicas y ser de lectura transversal, deberíamos evitar sumergirnos demasiado en detalles irrelevantes para el conjunto de la organización.

En general, debiera siempre mantener la mínima información indispensable y útil para toda la organización, y enlazar a documentos más detallados cuando sea necesario.

Un PB está pensado para sintetizar la estrategia a nivel de producto. Como documentos previos a implementar diferentes funcionalidades, en Basecamp, Intercom o Drift tienen buenos ejemplos (que no dejan de tener objetivos similares pero a otra escala más táctica).

Contenido

El contenido varía por empresa/producto, pero debería estar orientado a responder a la pregunta remarcada en el punto anterior: “¿por qué es un buen uso de los recursos de la empresa el trabajar en este producto (o gran funcionalidad) de este modo en este momento?”. O mejor dicho: debería estar orientado a responder y además a convencer.

Changelog

Al principio del documento, presuponiendo que no estará en un formato como Markdown que nos permita seguir los cambios en un repositorio de código, debiéramos tener una tabla que nos muestre tanto la fecha y responsable de la última actualización del documento, así como los estados por los que ha ido pasando.

Por tanto, se recomienda añadir una tabla como la siguiente e ir actualizándola con cada cambio de estado o modificación relevante en el mismo:

FechaEditorComentario
 … … …
 … … …
………

Nota de Prensa

Es una buena idea para sintetizar el contenido del PB el redactar una nota de prensa anunciando el lanzamiento de los objetivos marcados, dado que en un par de párrafos podemos dar respuesta a los principales elementos de un PB (¿qué se anuncia?,¿cuándo está previsto publicarla?,¿a quién interesa?,¿qué ofrece?, ¿por qué es relevante?, etc).

Contenido estratégico

A nivel estratégico el PB debería, como mínimo, responder a las siguientes preguntas:

  • ¿Por qué invertimos en construir este producto? – Recordando la máxima del product management “Only build solutions for problems that are urgent, pervasive and that the market will pay to solve”, el documento debería transmitir (y convencer) a su audiencia que el camino propuesto es el que retorna los mayores beneficios posibles, ya que cumple los principios de urgencia, generalidad y está orientado a clientes con capacidad de compra. Confío en que a vuestra edad ya sepáis que una empresa es lo que puede llegar a ser rentable gracias a producir, y no el envoltorio que necesitamos para poner un producto en el mercado. Que no es lo mismo, ni parecido.
  • ¿Qué necesidades resuelve? – En lugar de orientar el contenido a mostrar las principales funcionalidades, deberíamos orientarlo a detallar los principales problemas que tendría que resolver.
  • ¿Qué no hace este producto? ¿Qué hemos decidido no ofrecer jamás? – En el mundo real, trabajamos con restricciones. La principal ventaja de tenerlas es que evitan revisar continuamente opciones, y ayudan mucho a posicionarnos en un mercado (o contra soluciones alternativas). Ejemplos de restricciones serían “en nuestro SaaS nunca ofreceremos una versión on-premise” o “únicamente ofreceremos una API para interactuar con nuestro servicio”.
  • ¿Cómo se alinea este trabajo con los objetivos de la empresa? – El producto desarrollado, no deja de ser un medio para conseguir los objetivos corporativos. Por tanto, hemos de concretar para qué objetivos, iniciativas o proyectos estamos invirtiendo, y cómo esperamos ayudar a conseguir esos objetivos. Quizá otro día tocará escribir sobre objetivos>iniciativas>proyectos>tareas.
  • ¿Cómo sabremos si tiene éxito? ¿Cómo definimos lo que consideramos éxito a corto/medio/largo plazo? – A la hora de iniciar cualquier actividad, hemos de definir (al menos) una métrica que nos permita visualizar el éxito o no del trabajo que vamos desarrollando, para poder tomar decisiones que cambien el rumbo, o incluso cancelarlo. Además, estas métricas pueden variar a lo largo del tiempo. Por ejemplo: si lanzamos un producto, a corto plazo puede ser un indicativo de éxito el número de clientes conseguidos, a medio plazo llegar a cierto nivel de facturación, y a largo plazo el porcentaje de mercado capturado.
  • ¿Cómo nos posicionamos en el mercado? – En el apartado siguiente se detallará este punto, pero convendría tener concretado el posicionamiento estratégico en el mercado: a cuál nos dirigimos, cómo lo satisfacemos, cómo lo distribuimos, etc.

Contenido práctico

A nivel más práctico el PB debería cubrir (al menos) los siguientes puntos:

KPIs

  • Listado de las métricas más relevantes que se monitorizarán. En cada una de ellas, detallar los segmentos y objetivos actuales acordados (si los hubiera).

Al ser el PB un documento relativamente estático, tiene mucho sentido aquí enlazar a otro documento (como por ejemplo el plan de instrumentación) para acceder a todos los detalles detrás de las mismas.

Marketing

  • Definición del mercado y los segmentos a los que nos dirigimos . Recordad aquí que el que segmenta el mercado por variables demográficas y no por necesidades es un parguela.
  • Entorno competitivo (solo para empresas de un único producto), e idealmente un análisis resumido de las 5 fuerzas de Porter.
  • Comparativa contra competidores
    • Listado de empresas consideradas competencia directa y análisis de los principales puntos que se resaltarán contra ellos.
    • Enlace a un análisis detallado comparando funcionalidad.

Personas y casos de uso:

  • Listado de personas que vayan a usar el producto unido a lo que esperan conseguir/satisfacer con el mismo. Para cada una de estas personas, debiéramos responder: ¿qué usaba hasta ahora?, ¿cómo se le manifestaba el dolor?, ¿cuál es nuestra competencia directa?.
  • Listado de personas que no vayan a usar el producto, pero cuyos requisitos hemos de incorporar al mismo.
    • Por ejemplo, es posible que un producto digital no lo vaya a usar el CISO de una organización, pero su aprobación en base a ciertas funcionalidades del producto es crítica para poder ser usado.

Listado de principales necesidades que solventará el producto

  • Intencionadamente, no es una lista de funcionalidades, sino de necesidades (dado que la funcionalidad será detallada más adelante por los diferentes equipos que trabajen en la misma).

Por ejemplo, una necesidad por solventar podría ser “el poder exportar datos” del producto porque el cliente tiene la necesidad de importarlos a otra solución. Si hoy decidiésemos que la funcionalidad es “Exportar a CSV” estaríamos obviando otras quizá también necesarias como “Actualizar Google Sheets”.

Roadmap sugerido

  • Principales necesidades que solventará, en un escenario temporal estimado.
  • Enlace al roadmap detallado que se comparte internamente con la organización.

Principales dependencias del proyecto

  • Tanto internas como externas (si fuese necesario).

Aquí hablaríamos de coordinar el trabajo de diferentes equipos internos, si alguna parte del trabajo podría llegar a ser un bloqueo (y a priori que alternativas se plantean), etc.

Resumen y enlace a los diferentes planes:

  • Plan de desarrollo
  • Plan de lanzamiento
  • Plan comercial
  • …

Concluyendo

Como he dicho arriba, cada empresa es un mundo y manteniendo el objetivo de sintetizar y compartir las ideas del liderazgo de producto utilizando un documento que permita convencer a la organización de que se están tomando decisiones meditadas (y ojalá acertadas).

Para mí, la mejor prueba de que se tiene una cultura de producto sana y alineada (o de que un Product Manager está haciendo correctamente su trabajo) es cuando no hay reparos en decir «no» a una petición. Si un lead o cliente importante, (o hasta un equipo de desarrollo), solicita incluir algo en el roadmap y no hay reparos en negarse porque todos tenemos claro que «no sería un buen uso de los recursos el trabajar en eso ahora», señal de que vamos por el buen camino. Y ojalá lo veamos.

Tres negocios para un proyecto

~ Diego Mariño ~ 1 comentario

Una de mis taras mentales más grandes es que creo que para cada producto hay un mercado. Estará escondido, o será reducido. Igual es complejo de encontrar o está en nuestras antípodas geográficas y culturales (“It’s hugely popular in Indonesia!”), pero algo me dice que hagas lo que hagas siempre tendrás la oportunidad de encontrar un puchero rebosante de oro al final del arco iris.

– «¿A qué no encuentras la forma de vender bolsas de hielo en el polo norte?».
– «Sujétame el cubata».

Y te pones a pensar en casos de uso, dolores y necesidades, si realmente aunque creamos que el hielo allá arriba es omnipresente en algunos casos no lo es, etc. Ya avisé al principio de que era una tara. Y bastante entretenida, por cierto.

Pensar así es un problema, porque te has de recordar a menudo que encontrar resultados no está en absoluto relacionado con la rentabilidad de la iniciativa. Hay una gran diferencia entre tener éxito y tener razón… más o menos la misma que hay entre darse cabezazos machacando el mismo sector con la misma estrategia y enfoque durante años, o ajustar las velas hasta que te sangren los dedos de contar billetes. Porque, otra de las cosas en las que también creo es que si te vas a dejar la salud, las pestañas y las relaciones tras una iniciativa empresarial, al menos asegúrate de que tenga un gran potencial de retorno. De esas en las que hasta el último becario acaba gestionando su patrimonio desde Luxemburgo. De las que molan.

¿Y toda esta introducción a qué viene? A que a menudo ves startups con tecnologías impresionantes arrastrándose por sobrevivir. Y no dejas de pensar, benditas taras, en que quizá con algún pequeño cambio que nos acerque a la principal máxima de la gestión de producto («Only build solutions for problems that are urgent, pervasive and that the market will pay to solve«), podrían cambiar la tradición cultural de los viernes del «friday casual» a «los viernes al acabar tenemos sobredosis de percebes y raro es el día en que no vienen tres ambulancias».

Imagen motivacional absurda y obtenida de los internecs, puesta expresamente para reducir el bounce-rate entre el público millenial. Que llevábamos ya demasiados párrafos seguidos.

Hace años que en algunas de las presentaciones que hago pongo como ejemplo el mercado de informar sobre qué tecnologías se están usando en una web. Y la base tecnológica para servir el mercado es sencillo:

  1. Visitamos un dominio
  2. Descargamos y parseamos el contenido de sus HTMLs (y cabeceras!) para ver qué librerías se están cargando o qué tecnologías se están usando
  3. Comparamos esos resultados contra un diccionario. Por ejemplo, si en una web se está cargando «https://www.google-analytics.com/analytics.js» podemos asegurar que utiliza «Google Analytics».

Sobre esta base tecnológica podemos analizar el cómo la están llevando al mercado 3 empresas diferentes. O mejor, cómo la llevaban al mercado hace unos años (que no he seguido sus trayectorías actualizando la presentación, pero como ejemplos nos valen). Estos screenshots que os pongo ya han envejecido. </disclaimer>

En primer lugar, tenemos a Wappalyzer. Que curiosamente en estos años no ha cambiado su claim: «Identify technology on websites». 🤔

Es un servicio tremendamente útil si por ejemplo, estás leyendo este blog y te preguntas: «¿Qué tecnologías tendrá detrás?». Así que te instalas una extensión para el navegador, y ya puedes dormir tranquilo.

¿Cómo se podría monetizar algo así? ¿Suscripción para tener un número de checks al mes? ¿Micropagos? ¿Cómo de grande es el mercado de geeks con impulsos para comprobar las tecnologías detrás de una web (y necesitar un servicio para ello)? Hace unos años en su web pedían donaciones, aunque acabo de comprobar que ahora tienen planes en su web para recibir informes de sitios enviados por API o CSV (aunque los precios para este mercado global los tienen en dólares australianos 🤦🏽‍♀️).

El siguiente en la lista es un clásico: Builtwith. El claim tampoco ha cambiado en estos años, pero en su portada ya salía un concepto interesante: «lead generation».

Nosotros en la patoaventura, allá por el 2013, lo usábamos de vez en cuando para hacer outbound. «Dame un listado de webs que se gasten el dinero en estas 3 tecnologías, que así afinamos el tiro para ir a vender paneles para consolidar datos de esos servicios». Si mal no recuerdo, cada informe nos costaba $300 y los planes con esos servicios tenían un LTV cercano a los $3.000… así que hacíamos negocio todos. En 2015 salió la noticia de que el fundador, él solo, sin empleados ni perro que le ladre, se facturaba más de $1M al mes. Supongo que cuando te has aburrido de contar billetes, dejas saltar esa cifra para que se te embarre el mercado y poder dedicarte a otra cosa. Bendito aburrimiento.

Y finalmente, el tercer ejemplo es el de Datanyze. Salieron al mercado en 2014 definiéndose como el «Google of sales and marketing» (puaj!), y levantaron una ronda seed de $2M que les sirvió para, IMHO, hacer una cosa mala y una muy buena:

La mala: intentar crearte un segmento de mercado en el que estás tu sólo… «Somos unos visionarios liderando el vertical de technographics!!! Hooray!!!
La buena: sintentizar la propuesta de valor en algo tan apetecible como «te voy a avisar en cuanto uno de tus clientes empiece a probar la herramienta de un competidor». ¿Qué «vipí of seils» de cualquier tecnológica se negaría a contratar un producto así? Le pones un envoltorio «corporate» a esta propuesta y a contar billetes. O mejor aún: que te los cuenten, que te lo puedes permitir.

Recapitulemos, que esto se acaba. Tenemos una base tecnológica común: parsear el contenido de webs para conocer que tecnologías usan. Y tenemos 3 formas de paquetizar esa tecnología para tres casos de uso:

  1. Necesito ir comprobando a demanda las tecnologías de las webs que visitas. Con un mercado menos claro que el modelo de ingresos.
  2. Necesito leads, razonablemente cualificados, para nutrir a mis equipos de venta en acciones outbound.
  3. Necesito que se me avise cuando uno de mis cliente empiece a utilizar la tecnología de un competidor.

Y 2 consejos:

  1. Nunca seáis el primer ejemplo.
  2. Piensa bien en los recursos qué tienes antes de escoger el camino. Recursos de todo tipo: conocimientos, contactos, equipo y capacidades, inversión necesaria… Hay muchos caminos buenos y rentables, pero empezar uno que no puedes recorrer es tan malo como invertir horas en hacer un trabajo valioso para acabar pidiendo donaciones.

Y poco más. Si estás en una situación de esas en las que crees que tienes «un buen producto»* pero las ventas no acaban de arrancar, revisa las necesidades que estás satisfaciendo (si hay alguna) y empieza a observar casos de uso cercanos (aunque sea en otros mercados). O cualquier otra cosa menos seguir persistiendo en el error. Volviendo a la imagen original, la experiencia me dice que los que acaban encontrando diamantes tras años y años de picar son la excepción: normalmente, cuando se hacen las cosas bien, los diamantes se encuentran a los pocos metros. Y si crees que no tengo razón, revisa tu sesgo de supervivencia 🙂

[*] Un buen producto, por definición, resuelve una necesidad en un mercado. Si un producto no lo hace, no es bueno… por mucho framework de JS sobredimensionado que le pongas encima.

Asesoría gratis

~ Diego Mariño

Igual el título del post es demasiado clickbaity, pero prometo que no era esa la intención 🙂

Hace unos días, manteniendo esa constante en mi vida de no dejar sin pisar cualquier charco que se me ponga por delante, le recomendé a un fundador el no dar «condiciones especiales» a advisors. Pero antes de seguir, viene el obligatorio…

DISCLAIMER: Este artículo es una crítica al modelo, y en ningún caso a las personas con las que habrá establecido o no esa relación, ni a las personas con las que yo he tenido este tipo de acuerdos en el pasado. Todas las personas que tengo en mi cabeza a la hora de escribir este artículo tienen más track-record (a.k.a. patrimonio obtenido en el sector) que yo.

Sigamos.

Generalizando, más o menos el tema viene así: un fundador con escasa experiencia, quizá de forma sugerida por un inversor, se plantea que para reforzar un aspecto de la empresa en el que le falta conocimiento podría tener cerca a un experto para que le asesore. Normalmente la retribución suele ser propiamente en acciones/opciones o en un descuento a la hora de invertir, y dado que alguna condición habrá que poner por escrito, se fija algo tan abstracto como «mantener una reunión telefónica al mes». Y una vez firmado todo, es dónde las expectativas empiezan a flaquear. Principalmente, porque el modelo no aporta valor tangible, y creo que no lo aporta porque directamente no lo tiene. Así que vamos a echar un ojo a esta y otras formas en las que un accionista puede interactuar con una startup, y bajo mi opinión en cómo se deberían retribuir:

  • Advisoring pactado: como he dicho, creo que este modelo no aporta valor real, porque no hay periodicidad ni compromiso suficiente como para que pueda aportar valor. Los consejos que se puedan recibir bajo este modelo los podemos englobar en una categoría llamada «campeonatos de obviedades». En una llamada al mes (o cualquier fórmula parecida) se desconoce el día a día (cuando precisamente es el actuar sobre la realidad lo que distingue la obviedad del valor). Y una llamada (o reunión) no dura horas sobre las que poder extenderse. Así que el valor recibido es limitado. Y por tanto, creo que escuchar obviedades siempre debiera salir al módico precio de gratis.
  • Advisoring en profundidad: Esto suele ser bajo demanda o una vez al año (para cerrarlo y preparar el siguiente). Piensa en un offsite de pocos días, pero suficientes como para tratar los temas en profundidad. La empresa tiene a mano socios con conocimientos específicos que puede usar. Y a cambio, la empresa corre con todos los gastos asociados al offsite, y lo plantea de la fórmoda más cómoda posible para ellos. Y ya.
  • Trabajo profesional: esto es una zona llena de minas porque, aunque se tenga la mejor intención, pueden pasar 2 escenarios: (1) que alguien crea que la inversión condiciona el trabajo (por ej, «está invirtiendo por ahí para luego recuperarlo vendiendo su consultoría de producto»), o (2) que, por decirlo suavemente, que al finalizar el trabajo haya una clara divergencia entre la materialización de las expectativas de ambas partes. Por tanto, mi recomendación sería no pisar este charco, y si se decide, mejor tratarse con una relación normal de proveedor/cliente pagando a nivel de mercado. Las «rebajitas» en estos escenarios los carga el diablo.
  • Mentoring diario: Pongo mentoring por no poner «cuando sabes que puedes llamar a cualquier hora a un inversor porque el valle del sufrimiento se te hace demasiado largo». Yo en estos casos lo que he hecho ha sido evitarles la dilución en la siguiente ronda, pagando entre los fundadores. Estas relaciones salen con el tiempo, así que no se pueden plasmar en un contrato a priori. Tampoco nada garantiza que alguno de los inversores pueda ser un apoyo en el día a día. Así que cojámoslo con pinzas también, recordando que hay que ser generoso con los que ayudan más allá de lo requerido, y que las expectativas las carga el diablo.
  • Puesto en el consejo: un consejo de administración es un órgano legal en el que se está sujeto a diferentes regulaciones y hay que cumplir con obligaciones. Lo que se tiene en una empresa en fases iniciales es otra cosa (muy parecida al primer punto de la lista). Así que si has tenido que crear puestos en tu consejo para personas que no han invertido, no leas consejos de desconocidos de internet y retribuye a nivel de mercado. Y si lo que tienes es una estructura para simplificar que los inversores te puedan bloquear ciertas materias en fases iniciales, corre con los gastos de asistencia y gracias.
  • Comisionistas de Madrid: (y digo Madrid porque parece ser una profesión más habitual allí que en otros sitios). Mis principios me hacen repudiar este tipo de situaciones, pero alguien más cínico (lo que viene a ser con más experiencia) puede hacer el cálculo del retorno y tirar para adelante. No tengo opinión, pero en general no lo haría.

Resumiendo: que en los años que llevo en el sector, ni he visto que tenga sentido pagar por consejos esporádicos sin profundidad, ni creo que haya argumento a favor de retribuir con acciones en vez de con dinero. Doy fe.

Pero…

Alguien se estará preguntando: ¿y no crees que haces el gilipollas ayudando gratis mientras otros inversores se ponen de perfil? Pues es una pregunta interesante que merece ser respondida.

Honestamente, a veces sí. Hay algún caso en el que la implicación ha sido larga, y lo menos habré pensado «ya verás la caja de Lego más maja que me envían entre todos para Navidad». Y para entonces, ya ni te acuerdas. En todo caso, 2 reflexiones:

  • Echar una mano es puro egoísmo. Colaboro porque quiero que vaya bien, dado que como inversor voy a ser el primer beneficiado. El gen español de «me niego si a otros también les favorece» no lo tengo activado. Si es tu caso, busca ayuda.
  • Me sale el dealflow por las orejas. El hecho de no tocar una participación que no haya pagado e intentar ayudar en lo posible, genera que me lleguen más ofertas de las que puedo valorar. Honestidad y trabajo… como en la bandera de Brasil pero en versión inversor tecnológico.

Así que ni tan mal lo de ayudar gratis.

Y ya que estamos, aprovecho este último párrafo para decir que esto no es un publirreportaje. Que salvo follow-ons y «amigos que esta vez sí lo van a petar» no estoy buscando oportunidades. Lo único que tengo de verdad es la mala costumbre de meterme en problemas pisando charcos 🙂

Charla en el ProductHackers Day

~ Diego Mariño

El pasado 4 de Julio pude (al fin!) ir a contar batallitas al ProductHackers Day (que me parece es de lejos el evento más grande para product managers de España).

30 minutos no dan para mucho, pero creo que pude transmitir lo diferente que es ser product manager en tu startup (donde la única limitación son tus recursos) a serlo en una gran empresa (donde la principal limitación es tu capacidad de generar consensos de trabajo). Por si no quedó claro en mi charla, creo que es mejor ser decisor final con pocos recursos que no serlo con recursos y magnitudes ilimitadas.

Al final recomiendo 3 libros que, sin ser propiamente de gestión de producto, son en conjunto el mejor compendio que he encontrado para encontrar respuestas en esta profesión. Y curiosamente, todos siguen vigentes más de 30 años después de haberse escrito:

Pipedrive: mi CRM favorito

~ Diego Mariño

Allá por Marzo de 2013, buscando un CRM que pudiésemos integrar en el proceso de «product qualification» de Ducksboard, descubrí Pipedrive (afiliado). Y decir que me enamoré, es poco para todo lo que vino después. Así que cuando en MasQueStartups me invitaron a hablar sobre productos útiles para empresas que están arrancando, Pipedrive tenía que ser el primero a recomendar.

En aquel momento, en Ducksboard necesitábamos un CRM que tuviese una API completa para integrarnos, y así satisfacer 3 necesidades:

  • Enviar desde el listado de usuarios de nuestro «duckoffice» usuarios con nombres de dominio interesantes que seleccionábamos manualmente.
  • Enviar automáticamente usuarios enriquecidos por FullContact que cumpliesen ciertas reglas.
  • Enviar automáticamente usuarios todavía en trial que estuviesen haciendo mucho uso del producto (para hacerles seguimiento personal).

No sólo fue trivial la integración, sino que además tenía una UX sencilla y un precio razonable. Así que desde entonces lo recomiendo a todo el mundo.

Para haceros una idea rápida si no lo conocéis, echadle un ojo a este video de menos de un minuto:

Antes de revisar sus principales funcionalidades, puede ser que alguno se esté haciendo la pregunta del millón en este momento: ¿para qué sirve un CRM? O la del billón: ¿necesito uno en mi empresa?

Afortunadamente, la segunda pregunta es fácil de responder: salvo que seas un autónomo sin empleados (ni planes de tenerlos) y muy organizado… necesitas un CRM.

Y la utilidad, más allá de como «tarjetero digital» en el que apuntar datos de contacto, es enorme:

  • Tendrás una única vista del estado y de las interacciones de cada cliente. Además, podrás almacenar todos los documentos (propuestas, contratos, facturas…) en un único sitio y tenerlos a mano.
  • Podrás controlar que los procesos de venta que hayas definido se cumplen para todos los clientes, y en vista de los resultados que vayas teniendo, modificarlos.
  • Generarás manual o automáticamente tareas de seguimiento para todas las oportunidades y clientes.
  • Podrás obtener informes cuantitativos con el máximo detalle.

Una vez tengas definido cómo quieres que sea tu proceso de venta, introducirlo en Pipedrive es cuestión de minutos.

Funcionalidades Destacadas

API Completa y automatizaciones

En Pipedrive se toman en serio a los clientes de su API por lo que ofrecen:

Además, buscando entre la documentación, podréis ver que anuncian los cierres de endpoints con *meses de antelación*. Algo que tendría que ser normal, pero pocas empresas hacen.

Por otro lado, podemos integrarnos con otros servicios para automatizar procesos mediante webhooks. Cualquier creación o cambio en cualquiera de los objetos puede generarlo y lanzarlo al momento.

Enteramente parametrizable

Puedes crear todo tipo de campos personalizados (tanto por UI como por API), para los principales objetos. Pipedrive se adapta a tus datos y tus flujos de trabajo, y no al revés.

(Ejemplo sobre cómo crear un nuevo campo para almacenar el cumpleaños de un contacto)

Buena UX

Esto es bastante subjetivo, pero habituados a CRMs saturados de campos de texto se agradece el cambio que trajo Pipedrive poniendo el pipeline en el centro de la interfaz. De un vistazo se puede comprobar el estado general, qué oportunidades no tienen tareas asociadas, cuáles llevan demasiado tiempo en el mismo estado, moverlas entre columnas «a lo Trello» y cambiar cualquier valor editable simplemente pulsando encima.

Seguimientos en detalle

Además de almacenar todos los cambios de estado dentro del CRM, Pipedrive nos permite generar diferentes tipos de actividades.

Asimismo, permite integrarnos con terceros para enriquecer el seguimiento que hacemos de los clientes -es muy útil conectarlo con tu centralita para almacenar las llamadas entrantes y salientes así como las grabaciones- o crear nuestras propias actividades.

Recomiendo crear una actividad llamada «ALERTA» que se asigne cuando un usuario necesita ayuda urgente. Por ejemplo, si ha tenido un error a la hora de pagar.

Multi idioma

Yo estoy acostumbrado a tenerlo en inglés, pero está disponible en español (entre otros muchos idiomas). Además, el idioma está asociado al usuario, no al equipo, por lo que cada uno puede trabajar en el idioma en que se sienta más cómodo.

Flujos automatizados

Pipedrive nos permite generar fácilmente flujos de tareas con formato «if-this-then-that». Os pongo un par de ejemplos útiles:

En este caso, cuando ganamos una oportunidad la trasladamos a un pipeline diferente para que el equipo encargado de expandir el uso se encargue de ella.
Para evitar duplicidades en la centralita hemos de almacenar los números siempre con el mismo formato. En este caso, si sólo tenemos clientes en España podemos comprobar si algún número de teléfono introducido no empieza por +34, y en ese caso asignar una tarea al dueño de la oportunidad para revisarlo.

Almacenamiento ilimitado

Pipedrive no tiene limitaciones en cuanto a almacenar ficheros u otros datos, por lo que lo puedes convertir en el *single* source of truth de tus datos de negocio. Sube documentos y actualiza cualquier parámetro necesario en Pipedrive para que nadie de tu equipo tenga que consultar otras herramientas si quiere conocer el estado y actividad de un cliente.

App Móvil

La aplicación móvil no es únicamente una vista en pantalla pequeña, sino que tiene 2 features interesantes:

  • Permite almacenar como actividades las llamadas realizadas desde el móvil (en el caso de que se use en vez de una centralita).
  • Permite guardar notas de voz. Es realmente útil para compartir impresiones en caliente tras una visita, contando los detalles que probablemente se olviden al escribir sobre la misma varias horas después.

Informes

Quizá esta sea la parte más floja. No por los informes en sí, que están a la medida de cualquier otro competidor, sino porque recientemente han quitado el acceso a los mismos por API. Y eso está muy feo.

Y tras todo lo bueno, dos cosas que echo de menos:

  1. No tiene sistema de scoring. No hay forma automatizada para que, a medida que vas actualizando una oportunidad con datos sepas cuáles tienen más posibilidad de convertir para priorizarlos. Se pueden usar condiciones en un flujo automatizado para actualizar un campo en base a datos, pero si te sales de cuatro parámetros básicos se vuelve complicado.
  2. No es una herramienta pensada para garantizar compliance de acceso a datos. Si en tu negocio los silos de acceso a información son importantes, probablemente encuentres soluciones mejores.

Posiblemente muchos de vosotros al leerlo os habrá surgido una duda que tiene mucha gente: ¿En qué se diferencia de Salesforce? ¿Cuál recomiendas?Sin conocer tan en detalle Salesforce como Pipedrive, podría decir que la decisión viene dada si en tu empresa tiene «necesidades corporate»:

  • ¿Tienes un equipo de ventas con varios niveles de reporting?
  • ¿Con asignaciones (tanto de clientes como de ventas) complejas?
  • ¿Necesitas establecer murallas chinas entre equipos?
  • ¿Es crítico en tus procesos el uso de una herramienta integrada con Salesforce que no lo esté con Pipedrive?
  • ¿Necesitas auditar en todo momento la actividad de tus comerciales?

Si has respondido que sí a alguna de las preguntas, probablemente sea Salesforce lo que necesitas. Si no, te recomendaría empezar con Pipedrive, y cambiar únicamente cuando tengas necesidades que no te pueda solventar (si llega el día).

Finalmente, como prometí en MasQueStartups, os dejo una plantilla para comparar CRMs contra Pipedrive.

En Productízame podemos ayudarte a definir tus procesos de venta y a automatizar tus procesos del CRM aportando más conocimiento sobre tus leads y el uso que hacen de tu producto. Si quieres no se te escapen más oportunidades de hacer crecer tus ingresos, envíanos un mail y lo hablamos.