Una breve pero eficaz introducción a Trello con Javier Cristóbal

'Trello: aprende a gestionar proyectos y equipos de manera visual' es una corta guía de iniciación al uso de Trello, la popular herramienta de gestión de proyectos que, en el fondo, lo que hace es implementar de manera electrónica un tablero Kanban.

El libro es muy breve, y mucho más teniendo en cuenta que a lo largo de sus 67 páginas incluye bastantes imágenes de pantallas. Aún así, creo que logra de una forma efectiva explicar realmente los fundamentos y funcionamiento de esta herramienta aprovechando que, ciertamente, se trata de una aplicación sencilla.

El libro se compone de los siguientes capítulos:

• Principios básicos: cuenta qué es Trello, como conseguir una cuenta y rellenar el perfil
• Organización: es el capítulo nuclear en que muestra cómo trabajar con Tableros, Listas y Tarjetas.
• Colaboración: explica cómo gestionar Miembros y Equipos y trabajar varias personas a un tiempo en un proyecto.
• Bonus: nos cuenta detalles colaterales como el uso de atajos de teclado, potenciadores y las versiones móviles.

Hay que advertir que el autor, que claramente tiene como objetivo secundario el dar a conocer su trabajo, obtener feedback y atraer seguidores, introduce en medio del libro algo de autopropagada. Es ligeramente incómodo pero se perdona dado que es un libro muy baratito así que el marketing resulta comprensible.

En conjunto, debo decir que, a pesar de su notoria brevedad y sencillez, el libro consigue de forma efectiva y sin alharacas su objetivo: simplemente explicar cómo funciona Trello y los conceptos subyacentes.

Javier Cristóbal

(Fuente: Perfil en Canasto)

Javier Cristóbal

Javier Cristóbal es un ingeniero aeronáutico que después de pasar por una gran multinacional, se dio cuenta de la importancia que tiene la productividad no solo en grandes, medianas o pequeñas empresas, sino a nivel personal para llevar un estilo de vida más saludable.

Dispuesto a ayudar a las personas en dicho aspecto decidió crear Limni.net, un blog donde enseña a sacarle el máximo rendimiento a los dispositivos de Apple para que todos aquellos que se mueven en dicho ecosistema, pudiesen mejorar en su vida y su trabajo gracias a los cientos de aplicaciones que se han desarrollado hasta la fecha para esta plataforma.

Con el tiempo se dio cuenta de que muchos de sus lectores buscaban realizar un proyecto similar de manera profesional, y por eso creo el blog Enfoque Nómada, donde enseña a todo aquel que quiera emprender de manera digital a hacerlo de una manera eficiente.

Puedes conocer más del autor visitando su página oficial (Enfoque Nómada) o siguiéndole en Twitter donde se identifica como @crjstobal.

Ficha técnica:

TITULO: Trello: aprende a gestionar proyectos y equipos de manera visual

AUTOR: Javier Cristóbal

EDITORIAL: Enfoque Nómada

AÑO: 2016

ISBN: N/A
PAGINAS: 67

Colaboración "La transformación digital de la relación con el cliente" en el blog de Políticas Públicas de Telefónica

Hace unos días, en concreto el pasado 19 de Marzo, publicaba en el blog de políticas públicas de Telefónica un artículo sobre transformación digital titulado 'La transformación digital de la relación con el cliente: confianza, personalización, cercanía y dedicación'.

En él, de una forma breve, ilustro cómo la transformación digital puede actuar en un aspecto específico como es la relación con el cliente.

A este artículo seguirán otros en que me centraré en otros aspectos de la transformación digital.

Puedes acceder al artículo siguiendo este enlace.

 

Cosas que cambian radicalmente en la producción digital

El mundo digital cambia radicalmente muchas cosas. Cambia la naturaleza de muchos productos y  servicios, cambia procesos de negocio, cambia modelos de negocio, cambia la relación entre personas y organizaciones e, incluso, cambia elementos culturales.

Entre esos aspectos que se transforman con lo digital, también está la 'fabricación', entendida como la forma en que los producimos. La naturaleza incorpórea de los los bienes digitales ligados al software, hace que su producción sea muy diferente y nos permita aprovecharla a favor de los clientes... y de nuestro negocio.

Uno de los cambios radicales en esa producción digital es la velocidad a la que puede disponerse de los productos. La I+D inicial, el desarollo incial, puede ser costoso y tal vez largo, pero luego las cosas se aceleran. Así lo expresan Jeff Gothelf y Josh Seiden en su libro 'Lean UX: Designing great products with agile teams':

We are no longer limited by a physical manufacturing process, and are able to get our digital products and services into customer's hands at a pace unheard just five years ago.

Pero no es sólo la velocidad, que ya de por sí supondrá un cambo radical, también es que, al ser la producción de bienes digitales tan flexible y comparativamente tan barata, permite una rápida adaptación a la respuesta del mercado y de los clientes y eso posibilita el aprendizaje y adecuación al mercado real casi a la misma velocidad.

Así lo expresan los autores refiriéndose a Amazon y su capacidad para desplegar funcionalidades en su portal casi a la velocidad de la luz

they are discovering their product at the same time they are delivering it. This has many benefits but perhaps the two most important ones are:

• The ability to learn, continuously and quickly, how well their products are meeting customer needs.

• Raising customer expectations in terms of product quality and company response times to their concerns and feedback

Esta velocidad y capacidad de adaptación encajan a la perfección en filosofías como Lean Startup que aconsejan la experimentación rápida, la realización de experimentos para obtener feedback del cliente y la adaptación de nuestros productos y nuestra propuesta de valor a ese feedback.

Es una oportunidad inmensa...pero ¡ojo! como está a disposición también de todos nuestros competidores es también una exigencia, una muy dura exigencia competitiva.

En el mundo digital, se produce y se reacciona a toda velocidad... o, directamente, se está fuera....

Colaboración: "¿Cómo ganar dinero con productos gratuitos?" en 'Con Tu Negocio'

Tras mucho tiempo, reanudo mi colaboración con 'Con Tu Negocio', el blog de Telefónica dedicado al mundo de las PYMEs, y lo hago con el artículo titulado '¿Cómo ganar dinero con productos gratuitos?' dedicado a los modelos de negocio que aprovechan, paradójicamente, la gratuidad, como un método para obtener ingresos.

El plan es que esta colaboración tenga continuidad centrándome sobre todo en aspectos de tecnología digital, procesos y modelos de negocio.

Mientras llega una nueva colaboración puedes ller el artículo aquí.

 

La definición de Design Thinking de Tim Brown

Un muy breve artículo sólo para consignar la definición que de Design Thinking proporciona Tim Brown, CEO de la conocida firma de diseño IDEO.

Nos dice Brown que Design Thinking es:

innovation powered by ... direct observation of what people want and need in their lives and what they like or dislike about the way particular products are made, packaged, marketed, sold, and supported.

a lo que añade:

[it's] a discipline that uses teh designer's sensibility and methods to match people's need with what the is technlogically feasible and what a viable business strategy can convert into customer value and market opportunity.

Lo cierto es que esta definición no permite entender en qué consiste realmente el design thinking, pero sí marca claramente en qué consiste su filosofía, o al menos parte de ella, poniendo foco en dos aspectos: la observación de la realidad y necesidades del cliente (y, por tanto, el contraste con ella) y la viabilidad tecnica y de negocio.

Seguro que volveremos a hablar de design thinking, pero de momento quería registrar esta definición que me he encontrado en el libro 'Lean UX: Designing great products with agile teams' de Jeff Gothelf y Josh Seiden.

El último momento responsable

Hay una tensión inherente entre el análisis y la velocidad cuando hablamos de la toma de decisiones. 

Un exceso de análisis conduce a la decisión tardía con lo que pueden perderse oportunidades de negocio, o bien, convertirse en problemas riesgos que podíamos haber evitado de haber estado algo más ágiles en nuestro proceso decisorio.

Por el contrario, la obsesión por la velocidad en la decisión y una a veces mal entendida 'ejecutividad'.  lleva a tomar decisiones precipitadas sin el más mínimo análisis aunque exista información disponible y método viable para realizar dicho análisis.

En concreto, cada vez observo con más frecuencia el segundo patrón extremo, el de la precipitación.

Por eso me resulta tan pertinente y atractivo el concepto de último momento responsable usado en metodología Lean. Tal y como nos lo explican Carmen Lasa, Alonso Álvarez y Rafael de las Heras, en su libro 'Métodos Ágiles. Scrum, Kanban, Lean':

pretende transmitir [es] que se debe aprender e investigar todo lo posible antes de tomar una decisión que afecte al producto. Pero esa decisión debe tomarse en el momento justo, no más tarde. En definitiva, huir del exceso de análisis que pueda paralizar al equipo [...], pero también de la toma de decisiones de forma precipitada.

Pues eso. 

Hasta siempre Telefónica: banda sonora para un adiós y un futuro

El Jueves 22 de Marzo me despido de Telefónica.

Unas palabras fáciles de pronunciar o escribir... pero no tanto de asimilar, de calibrar en su justa medida, en su alcance profundo.

Se trata del final de un camino que inicié hace ahora algo más de 25 años, un 9 de Diciembre de 1992, cuando me incorporé a Telefónica Investigación y Desarrollo, pleno de ilusión y expectativas. Un caminó que, en su trazado, aparte de 12 años en la filial de I+D, ha incluido también un paso de 8 años por Telefónica Soluciones y de 5 más por Telefónica de España.

Un camino largo en que he hecho cantidad de cosas diferentes, trabajado con numerosas áreas, conocido a muchas personas, coincidido con dosis ingentes de talento. Una senda de esfuerzo y continuo aprendizaje, a lo largo de cuyos claroscuros nunca he dejado de estar satisfecho de mi actividad y orgulloso de mi empresa. Un trayecto que cierro pleno de consciencia sobre mí y mi hasta ahora compañía, y agradecido a ésta por lo que me ha dado.

Y una ruta que conduce ahora, sin solución de continuidad, casi sin paréntesis, a un nuevo viaje, un nuevo proyecto. A partir de este momento me dedicaré en cuerpo y alma a 'Reingeniería Digital', la firma que he creado hace un par de meses y desde la que pienso trabajar en materia de innovación, tecnología digital y reingeniería de procesos y modelos de negocio.

Pero ahora vuelvo mi pensamiento y mi sentir hacia la Telefónica que abandono, hacia los compañeros que dejaré de ver. 

En el momento del adiós se agolpan los recuerdos y las emociones y es difícil encontrar la expresión ajustada al hecho y al sentimiento. Faltan las palabras. En realidad, probablemente, sobran las palabras.

En su lugar, dejo aquí un vídeo, una banda sonora.

No soy capaz de explicar por qué, pero cuando hace unos meses vi este vídeo y escuché esta música por primera vez, supe de inmediato que ésta iba a ser la banda sonora de mi despedida de Telefónica. Quizá por lo que de mirada al pasado tiene que Bruce Springsteen interprete un tema de Chuck Berry. Quizá porque la canción, en el fondo, sugiere que el futuro se construye y nunca puedes decir lo que te va a traer ('it goes to show you never can tell').

Hasta siempre, mi querida Telefónica, mi historia, mi recuerdo. Bienvenida, Reingeniería Digital, mi nuevo proyecto, mi nueva ilusión...

¿Qué me deparará el futuro?

Ya lo explica la canción: You never can tell...

¿Por qué fallan las especificaciones de requisitos?

Uno de los motivos, creo, que impulsaron el nacimiento de 'agile', aunque sin duda no el único, fue la más que imperfecta gestión de los requisitos del software que se produce cuando se aplica el modelo en cascada tradicional.

Cuando se aplica en modelo en cascada puro la especificación de requisitos se produce al inicio del proyecto. En ella se debe definir de forma completa e inequívoca lo que se espera que haga el software. A partir de ahí la especificación debe quedar congelada o actualizarse mediante un riguroso proceso de gestión del alcance. 

Es cierto que los métodos de ingeniería software, incluso métodos en cierto sentido tradicionales como el Método Unificado, admiten la necesidad de unas ciertas iteraciones que pueden convertir a esa especificación en menos monolítica e inamovible.

Sin embargo, llega un punto en que los requisitos se congelan. En realidad, si se piensa, el planteamiento es bastante lógico y racional y parece perfectamente alineado con las buenas prácticas de la dirección de proyectos.

Y, sin embargo, esa especificación de requisitos inicial, tiene a fallar, tiende a funcionar mal. ¿Por qué?

En su libro 'Métodos Ágiles. Scrum, Kanban, Lean', Carmen Lasa, Alonso Álvarez y Rafael de las Heras nos identifican cuatro motivos.

En la siguiente lista, en negrita, el texto con el motivo tal y como lo aportan los autores en el libro. Los comentarios que le siguen son míos.

• Desconexión entre las personas que definen los requisitos y las personas que los llevan a cabo: existe, en efecto, la mala costumbre de alejar al usuario final o al responsable del negocio del desarrollador. No es extraño que al usuario le represente una persona (que no es el propio usuario) quien, a su vez, habla, no con el desarrollador, sino con un analista que es quien suele plasmar formalmente los requisitos que se trasladan luego al desarrollador. No es extraño que se produzca el efecto 'teléfono escacharrado' y que lo que finalmente entienda el desarrollador tenga poco que ver con lo que realmente quiere o necesita el usuario. A ese respecto, no puedo olvidar la sensación (ya que los detalles sí que se me han olvidado) que tuve hace bastantes años cuando, en medio de un desarrollo que estábamos llevando a cabo con la mejor de las voluntades, y que pensábamos estábamos ejecutando de forma excelente, y con el desarrollo avanzado, tuvimos la oportunidad de hablar con usuario final... Y la sorpresa fue mayúscula al comprender que lo que necesitaba ese usuario era algo bastante diferente y muchiiiiiísimo más sencillo que lo que le estábamos preparando con toda nuestra mejor intención. Cuánto tiempo nos habríamos ahorrado y cuánto más habríamos acertado si hubiésemos podio hablar con el usuario desde el principio.


• Interpretación ambigua de los requisitos: En efecto, los requisitos deben ser inequívocos, pero es muy, muy difícil de conseguir. Requiere mucho rigor conceptual e incluso mucha capacidad de escritura, para plasmar en un papel unos requisitos exactos, completos y sin ambigüedad ninguna. Además, muchas veces el esfuerzo de conseguir esa exactitud es exagerado para el alcance de lo que se está especificando.


• Cambio de los requisitos desde que se definen hasta que se implementan: en este caso puede deberse, tanto a una falta de disciplina en la gestión del proyecto (tanto por el equipo de desarrollo como por el usuario o negocio) que no se esfuerzan lo suficiente en cerrar los requisitos, como, y esto es más difícil de salvar, a la falta real de imaginación o análisis para, en abstracto, y sin haber visto nada del software, saber concretar todo lo que se necesita y cómo se necesita.


• Necesidad de incorporar nuevos requisitos durante el ciclo de vida del desarrollo de un producto: creo que, de nuevo, se puede deber a falta de disciplina pero también de previsión, imaginación o abstracción.

Es, entre otras cosas, para salvar todas estas carencias que los métodos 'agile' proponen ciclos de desarrollo muy rápidos y una presencia constante y cercana del usuario/negocio en el equipo de proyecto.

El triángulo de hierro

Este post es sólo un breve apunte, algo así como un acta de un elemento de gestión bastante conocido, aunque quizá no tanto su nombre: el triángulo de hierro.

Cualquiera que tenga entrenamiento formal o experiencia práctica en dirección de proyectos, o casi basta con que haya participado en uno con suficiente cercanía al director de proyecto, sabe de las tres grandes variables que dominan un proyecto: la funcionalidad (alcance), el tiempo (los plazos)y  los costes.

Y en medio de esas tres variables fundamentales, la calidad del resultado.

Por formación o por experiencia todos sabemos que no se puede conseguir la optimización simultánea de los tres factores. Si queremos ahorrar coste normalmente será en detrimento del alcance, puede que de los plazos y, bastante probable, como resultado, de la calidad. Si lo que queremos es disminuir plazos, es fácil que sea a costa, de nuevo, de menor alcance, mayores plazos y/o menor calidad. Y si lo que queremos es aumentar alcance, en general, traerá consigo un aumento de costes y plazos.

Esa tripleta inevitable: alcance, plazos y costes, conforma los vértices del triángulo de hierro.

En su libro 'Métodos Ágiles. Scrum, Kanban, Lean', Carmen Lasa, Alonso Álvarez y Rafael de las Heras, hacen mención a este concepto, como algo a tener en cuenta, cuando explican el Plan maestro ('release plan') y es que no, 'Agile' tiene muchas virtudes, pero tampoco es capaz de escapar del  famoso triángulo de hierro.

Se trata de un 'basic' de dirección de proyectos y la dirección de proyectos no deja de ser una disciplina humana y, como tal, no hace milagros...

Los seis atributos de un buen Scrum Máster

Dentro de los métodos 'Agile' (o, como algún follower me indicó en twitter, de un 'framework' más que de un método) el más popular parece ser, sin duda, Scrum. Scrum define, entre otras cosas, unos roles en los equipos de trabajo y, dentro de éstos, la figura seguramente más representativa sea el Scrum Máster.

El Scrum Master vela por la introducción y correcta aplicación en el equipo de los principios y técnicas agile (en este caso, scrum). Además, actúa como facilitador haciendo que fluya la información, que se produzca la colaboración en el seno del equipo y que éste sea productivo. Y actúa como enlace con 'el mundo exterior' entre el equipo y otros equipos o personas.

Un perfil, creo, ecléctico, difícil, donde se aúnan los conocimientos con, sobre todo, las actitudes y habilidades personales.

Quizá por ello exista cierta literatura al respecto de cómo debe ser un buen Scrum Máster. En su libro 'Métodos ágiles. Scrum, Kanban, Lean', Carmen Lasa, Alonso Álvarez y Rafael de las Heras se detienen también a intentar contestar a esta pregunta y se apoyan, para ello, en el artículo 'Leader of the Band', escrito ya en 2007 por Mike Cohn. éste identificaba en dicho artículo, las siguientes seis características de un buen Scrum Máster:

• Responsable ('Responsible') responsable, entre otras cosas, de la correcta aplicación de scrum y de la productividad del equipo pero con una forma de responsabilidad diferente, ya que carece de autoridad formal, por lo que actúa no por coherción sino a modo, según nos indican los autores, de un director de orquesta, haciendo que los miembros del equipo funcionen en armonía.


• Humilde ('Humble') ya que lo que tiene que hacer es que rinda, que brille, el resto del equipo, no él mismo. Sus armas son el ejemplo y la inspiración.


• Colaborador ('Collaborative') ya que la colaboración es un principio Scrum, el Scrum Máster es el primero que debe exhibir esa capacidad y tener la habilidad de que la colaboración se produzca de forma efectiva en el seno del equipo.


• Comprometido ('Commited') comprometido con el proyecto, con sus fines, y sus resultados.


• Influyente ('Influential') si carece de autoridad formal, pero tiene responsabilidad, parece evidente que debe tener la capacidad de influir en el equipo, debe reunir esas habilidades personales y políticas tan propias de un buen líder para cambiar comportamientos y orientarlos en el sentido adecuado.


• Entendido ('Knowledgeable') ya que una forma de influir es mediante el ejemplo, el Scrum Máster debe ser un buen conocedor, tanto del framework Scrum y sus técnicas, como del dominio de aplicación propio del proyecto

Como se puede ver, un perfil complejo, dotado de autoridad natural y adornado con habilidades y actitudes muy propias del ámbito del liderazgo y, sin embargo, al que no se concede autoridad formal y al que además se pide humildad y que haga brillar a otros.

Un perfil, eso sí, que me parece va en línea con las tendencias modernas en gestión del talento, que apuntan en la dirección de menos jerarquías, mayor colaboración y un funcionamiento más en red.

Un perfil, eso sí, que caso de aparecer en toda su plenitud, quizá podría estar llamado a mayores retos que la dedicación a uno o unos pocos proyectos. Quizá podría asumir posiciones de liderazgo de mayor alcance.

El famoso manual para startups de Steve Blank y Bob Dorf

'The Startup Owner's Manual' es un libro imprescindible, aunque algo exigente, en materia de innovación y sobre todo, de emprendimiento. En él se describe, minuciosamente, el llamado modelo de desarrollo de clientes ('Customer Development Model') que, aunque el nombre pueda hacer pensar en otra cosa quizá más enfocada al mundo comercial o CRM, en realidad es un método para la puesta en marcha de una startup, desde su concepción inicial hasta que se convierte en una empresa madura y de éxito.

El método propuesto por Blank y Dorf, tiene cuatro pasos, los dos primeros más orientados a la búsqueda y definición del modelo de negocio y los dos segundos enfocados a la ejecución y puesta en marcha y escalado de un modelo de negocio ya testado.

• Customer Discovery: Recoge la visión de los fundadores y la convierte en una serie de hipótesis de modelo de negocio y desarrolla un plan para probar las recciones de los clientes a esas hipótesis de forma que se puedan convertir en hechos.
• Customer Validation: Comprueba si el modelo de negocio resultante es repetible y escalable.
• Customer Creation: Es el inicio de la ejecución. Construye demanda de clientes y la conduce a los canales de ventas para escalar el negocio.
• Company Building: Transición desde lo que era una startup a una compañía enfocada ala ejecución con un modelo denegocio validado.

A su vez, cada paso se subdivide en una serie de fases y éstas en tareas. Las ideas generales, y la estructura del método, se explica en los dos primeros capítulos, que son interesantísimos y muy brillantes:

• Chapter 1: The Path to Disaster: a startup is not a small version of a big company
• Chapter 2: The Path to the Epiphany: The Customer Development Model

El resto del libro, describe minuciosamente, fase a fase, y tarea a tarea, el método en sí. Eso sí, sólo describe los dos primeros pasos, los orientados a la búsqueda de un modelo de negocio y que son más diferenciales del caso de las startups. Cuando entra en el detalle, además, suele distinguir un doble camino, el de las empresas tradicionales, más ligadas al mundo físico, y el de las más digitales, ligadas a la web y al móvil.

Al PASO UNO, 'Customer Discovery' dedica los siguientes capítulos:

• Chapter 3: An Introduction to Customer Discovery
• Chapter 4: Customer Discovery, Phase One: State Your Business Model Hypothesis
• Chapter 5: Customer Discovery, Phase Two: "Get Out of the Building" to Test de Problem "Do People Care?"
• Chapter 6: Customer Discovery, Phase Three: "Get Out of the Building" and Test de Producto Solution
• Chapter 7: Customer Discovery Phase Four: Verify The Business Modelo and Pivot or Proceed

Y al PASO DOS: 'Customer Validation' dedica los siguientes:

• Chapter 8: Introduction to Customer Validation
• Chapter 9: Customer Validation Phase One: "Get Ready to Sell"
• Chapter 10: Customer Valition Phase Two: "Get Out of the Building and Sell"
• Chapter 11: Customer Validation Phase Three: Develop Product and Company Positioning
• Chapter 12: Customer Validation Phase Four: The Toughest Question of All: Pivot or Proceed?

El libro se completa con interesantes apéndices donde, en el primero aportan varias decenas de checklists para comprobar que se han realizado correctamente las fases, en el segundo un glosario muy riguroso y en el un ejercicio para el desarrollo de una startup basada en la web.

Estamos ante un grandísimo libro, por su originalidad y sobre todo rigor, y que ha sido el antecesor claro y reconocido del famoso 'Lean Startup' al tiempo que enlaza con otros movimientos y metodologías famosas como el 'Business Model Canvas' o 'Agile'. En su lectura, sin embargo, se diferencian claramente las sensaciones de los dos primeros capítulos, que son absorbentes, a las de los capítulos posteriores que son, como los propios autores reconocen y advierten, un manual de referencia, no hecho tanto para una lectura de principio a fin como para una consulta frecuente y lectura en pequeños sorbos.

Sin duda, un gran libro, imprescindible en la biblioteca de cualquiera interesado en la innovación y el emprendimiento.

Steve Blank

(Fuente: Wikipedia)

Steve Blank

Steve Blank (nacido en 1953) es un emprendedor en serie y profesor de Silicon Valley que vive en Pescadero, California.​

Blank es conocido por desarrollar la metodología del Desarrollo de Clientes (Customer Development), que inició el movimiento Lean Startup, una metodología que pone de manifiesto que los nuevos negocios y startups no son versiones reducidas de las grandes empresas, y que necesitan sus propios procesos y herramientas para tener éxito. Su artículo de la portada del número de Mayo de 2013 de la Harvard Business Review (Why the Lean Startup Changes Everything) definió el movimiento Lean Startup. Su programa formativo Lean Launchpad (que se enseña en el Innovation Corps de la National Science Foundation) se ha convertido en el estándar para la comercialización de los resultados de las investigación científica federal.

Blank ha trabajado más de 30 años en el sector de las tecnologías de la información. Ha creado o trabajado en 8 nuevas empresas o startups, cuatro de las cuales salieron a bolsa. Blank también es el co-fundador de E.piphany.​

Blank se jubiló en 1999, y desde entonces enseña y escribe sobre Desarrollo de Clientes y el método Lean Startup. Es catedrático adjunto de creación de negocios en Stanford; da clase en la Haas School of Business, y es profesor en la Universidad de Columbia​ y en la Universidad de Nueva York. Es un blogger y conferenciante muy prolífico y ha escrito 4 libros: 'The Four Steps to the Epiphany' (Los cuatro pasos para Epifanía), 'Not All Those Who Wander Are Lost' (No todos los que vagan están perdidos), 'The Startup Owner's Manual' (El manual del emprendedor) y 'Holding a Cat by the Tail' (Agarrando a un gato por la cola).

Puedes conocer más del autor visitando su página oficial o siguiéndole en Twitter donde se identifica como @sgblank.

Bob Dorf

(Fuente: Traducción y ligera elaboración propia de la biografía en su Página Oficial)

Bob Dorf

Emprendedor en serie retirado y co-autor de 'The Startup Owners Manual'.

Bob Dorf es, probablemente, y en sus propias palabras, el segundo mayor experto mundial en 'Customer Development', sólo por detrás de su creador, Steve Blank. Juntos dedicaron casi dos años a concebir, delinear, plasmar, reescribir y revisar el bestseller global 'The Startup Owner's Manual', actualmente un bestseller en los Estados Unidos y muchos otros países alrededor del mundo.

Emprendedor en serie, Bob abandonó un lucrativo trabajo a los 22 años porque tenía la pasión de crear su propia compañía. lo cual hizo siete veces a lo largo de tres décadas.

Bob invirtió, ayudó o aconsejó a más de dos docenas de startups a lo largo de más de una década. Siete de ellas salieron a bolsa, mientras que seis "se fueron directamente por el retrete". Fueron, según él, 42 años de formación en emprendimiento.

En Marzo de 2012, Bob publicó 'The Startup Owner’s Manual: A Step–By–Step Guide to Building a Great Company', junto con Steve Blank. Dos años de investigación y desarrollo a tiempo completo dieron lugar a su magna obra: 608 páginas con un aguía detallada que es la vía más completa y rigurosa y que está guiando a fundadores de startups a todo lo largo y ancho del mundo. Ofrece dos caminos paralelos para compañías en los canales web y móvil y aquellas con bienes físicos o software empresarial. También incluye tutoriales sobre marketing web.

Bob viaja por el mundo ayudado a startups, incubadoras, gobiernos y corporaciones ya establecidas a aprender cómo desplegar de forma efectiva el proceso 'Customer Development' y lo hace a través de conferencias, talleres y consultoría práctica.

Enseña 'Customer Development' y Modelado de Negocio en un curso de smestre completo en la Columbia Business School, donde es profesor adjunto de emprendimiento y ha impartido sesiones de formación en Tech de Monterrey, Mexico, Skolkovo Business School en Moscú y muchos otros lugares alrededor del mundo. Ha asesorado también a docenas de organizaciones sin ánimo de lucro, incluyendo a la legendaria Acumen Fund, un fondo capital-riesgo sostenible.

Puedes conocer más del autor visitando su página oficial o siguiéndole en Twitter donde se identifica como @bobdorf.

Ficha técnica:

TITULO: The startup owner's manual

AUTOR: Steve Blank y Bob Dorf

EDITORIAL: K & S Ranch

AÑO: 2012

ISBN: 978-0984999309
PAGINAS: 571

Artículos de este blog relacionados

• Tipos de clientes
• Tres cifras para dimensionar un mercado
• La dificultad de escuchar a los clientes
• Para enmarcar: las catorce reglas del 'Customer Development Manifesto'
• La visión del fundador de una startup
• Los nueve pecados del lanzamiento de un producto... y cómo redimirlos
• La involuntaria explicación de Steve Blank a la exponencialidad digital
• Riesgo de mercado versus riesgo de invención
• Lo que es y lo que no es una startup

Tipos de clientes

Somos consientes de que la decisión de compra no se adopta en general por una sola persona sino que existen, especialmente en el ámbito corporativo y el B2B, una serie compleja de interacciones e influencias que desembocan en esa decisión de comprar o no comprar. No hay, por eso, un sólo tipo de cliente sino varios tipos de clientes, varios tipos a los que debemos atraer y convencer.

En su libro 'The startups owner's manual' Steve Blank y Bob Dorf nos proponen una clasificación que, gráficamente se refleja en la siguiente pirámide:

¿Qué tipos de clientes podemos ver ahí?

• 'Usuarios finales:': son los que realmente van a emplear el producto, a usarlo, verlo, tocarlo. A pesar de ello, pueden ser los menos influyentes en la decisión de compra en entornos complejos.


• ''Influencers': personas que marcan tendencias y crean opinión, en muchas ocasiones pioneros, en otras simplemente populares. En cualquier caso, con capacidad para generar un estado de opinión sobre los productos y que influyen en las decisiones de compra de otros.


• 'Recomendadores': También ejercen influencia de una forma parecida a los 'influencers', pero en este caso la influencia es más directa y es capaz de provocar directamente el cierre o ruptura de una venta concreta.


• 'Comprador económico': controlan y aprueban o desaprueban las compras.


• 'Decisor': El nivel más alto de la jerarquía, la última autoridad a la que recurrir.


• 'Saboteadores': No aparecen en la figura...pero existen. Pueden estar presentes en partes diversas de la empresa o la familia y abortan o ralentizan la compra.

Esta compleja realidad, este cliente polifacético, hace que el marketing y la venta sea más complejos, puesto que son diversos los actores a los que debemos convencer y sus percepciones e intereses pueden ser también muy diferentes e incluso contrapuestos.

Fácil no es, desde luego.

La naturaleza de una proposición de valor

Uno de los elementos fundamentales de un modelo de negocio es la proposición de valor.

De alguna forma todos nos hacemos a la idea de lo que es: se trata de aquello que le aportamos a los clientes, aquello que tiene que hacer que nuestro producto o servicio le resulte atractivo.

Siendo esto cierto, es importante poner más foco en el cliente y darse cuenta de que lo que cliente quiere es que le satisfagamos alguna necesidad.

Volveremos en unas fechas a hablar abundantemente de proposición de valor cuando comentemos el libro 'Diseñando la propuesta de valor' de Alex Osterwalder e Yves Pigneur. Sin embargo, antes de llegar allí, me encuentro una frase muy asertiva de Steve Blank y Bob Dorf en su libro 'The startup owner's manual'. Dice así:

Think of a value proposition as a contract between the customer and your company where the customer "hires" your startup to solve a problem.

No es que, en el fondo, nos aporte un concepto diferente, pero esa forma de expresarlo, es como si el cliente contratarse a tu startup para resolverle un problema, expresa muy claramente lo que debemos conseguir y para qué queremos una proposición de valor.

Es una forma de llevar la orientación al cliente a su máxima expresión.

Tres cifras para dimensionar un mercado

Tres cifras, tres conceptos definen habitualmente cómo dimensionar un mercado.

Steve Blank y Bob Dorf nos lo recuerdan en su libro 'The startup owner's manual' pensando evidentemente en startups, pero el concepto es mucho más general y válido para todo tipo de empresas.

Los tres conceptos son:

Total Addresable Market (TAM)

Que recoge el universo total de posibles candidatos. Es un valor máximo, una cota superior.

Served Available Market (SAM)

Es el subconjunto del mercado total a los que puedo alcanzar con los canales de que dispongo.

Target Market (TM)

Es el subconjunto del mercado que me marco como objetivo, qué clientes están realmente a nuestro alcance. En el caso de una startup estaría constituido por el subconjunto de clientes más probables.

*****

Como se puede entender, y como se aprecia especialmente bien en la figura, cada concepto es subconjunto del anterior y, por tanto, en número, es menor.

No es que por sí mismos estos conceptos nos resuelvan la vida, pero ayudan a poner orden y disponer de un lenguaje común.