Connections and differences between Customer Development and Design Thinking: where does one start and the other end?

At the end of last July Steve Blank published an article in his blog where he analyzed the differences between his Customer Development methodology and the Design Thinking proposal. It seems clear that those two approaches share a strong connection, as both are essentially based on out-of-the-building observation and direct interaction with potential customers to co-create a solution according to their problems and needs and the feedback gathered from the experimentation by those customer with successive prototypes or MVPs that are refined iteratively. These similarities in their foundations makes the border or distinction between those methodologies a bit vague, and when we plan some experiments or interactions with customers one doesn't really worry (at least in my experience) about whether what one is doing is considered Design Thinking, Customer Development or both of them at the same time (what might suggest that in the end the "label" is the least of our worries).

¿Dónde acaba el Desarrollo de Clientes (“Customer Development”) y empieza el “Design Thinking” -o viceversa-? Conexiones y diferencias entre ambas metodologías

A finales del pasado mes de julio Steve Blank publicó un artículo en su blog en el que analizaba las diferencias de enfoque entre su metodología de Desarrollo de Clientes y la propuesta del Design Thinking. Parece claro que ambos enfoques tienen una fuerte conexión debido a que en esencia están basados en la observación “out of the building” y en la interacción directa con potenciales clientes para “co-crear” una solución basada en sus problemas y necesidades y en el feedback recabado a través de la experimentación por parte de dichos clientes con sucesivos prototipos o MVPs que son refinados iterativamente. Esta similitud en sus fundamentos básicos hace que la frontera entre ambas metodologías quede ciertamente difusa, hasta el punto de que (al menos por mi experiencia) cuando planteamos ciertos experimentos o interacciones con clientes uno deja de preocuparse de si lo que está practicando se considera Design Thinking, Desarrollo de Clientes o ambas a la vez (lo que vendría a sugerir que quizá al final la etiqueta sea lo de menos).

"Design Thinking" explicado por Tim Brown (IDEO)

De la misma manera en que Steve Blank, a través de su artículo publicado en 2013 en Harvard Business Review, nos explica la evolución de los últimos años en torno a los métodos y herramientas de apoyo a la creación de startups para poner en contexto el surgimiento de la metodología Lean Startup, otro artículo de 2008 en la misma publicación a cargo de Tim Brown, CEO de la compañía IDEO, nos pone sobre la pista de las claves principales en torno a Design Thinking, otra de las claves metodológicas que también son manejadas intensivamente en proyectos innovadores y de lanzamiento de startups.

Profundizando en el concepto de "historias de usuario"

En la anterior entrada del blog revisábamos un tutorial elaborado por Alex Cowan en el que se analizaban varios aspectos clave de la práctica de metodologías ágiles, y donde entre otros se destacaba la herramienta de las "historias de usuario". El tutorial enlazaba a otro artículo del mismo autor en el que se profundiza en dicha herramienta a través de los elementos que la componen y de cómo construir cada uno de ellos. Además proporciona una buena batería de ejemplos detallados que nos pueden servir de inspiración para elaborar las historias de usuario del problema que estemos explorando.

Métodos ágiles, historias de usuario y storyboards: artículo-tutorial de Alex Cowan

En este completo artículo-tutorial, Alex Cowan utiliza las metodologías ágiles como hilo conductor para, ademas de detallar ciertos conceptos y técnicas básicas al respecto y destacar posibles fuentes de problemas a las que hay que prestar especial atención, integrar en su visión conceptos como design thinking, lean startup o la utilización de guiones con formato de viñetas (storyboards) que faciliten la comprensión de los requisitos de solución por parte de todos los implicados.