Crecimiento de productos tecnológicos

No vendas tu software, publica tu API (2)

por en 9 julio 2011

Las APIs son la nueva estrategia y plataforma de marketing para muchas nuevas tecnologías que se pueden empaquetar como software. La posibilidad de que sean otros partners los que desarrollen y vendan soluciones finales basadas en nuestra tecnología, en un modelo escalable y de aparente baja inversión y riesgo, abre enormes posibilidades comerciales. Tanto es así que algunos lo han bautizado como Desarrollo de Negocio 2.0.

En un post anterior hablamos de cómo publicar las APIs (Interfaces de Programación de Aplicaciones) abre un nuevo modelo de negocio a muchas empresas que ofrecen software en áreas tan diversas como la inteligencia artificial, el tratamiento estadístico, la información cartográfica o las conexiones sociales. Publicar APIs no solo es negocio para los grandes de la Web 2.0. Muchas empresas innovadoras se pueden beneficiar de este modelo para comercializar datos o lógica de aplicación (aunque, por supuesto, la estrategia a emplear dependerá mucho de cuál sea esa “materia prima”).

Por dar un ejemplo, pensemos en una empresa que desea comercializar una nueva tecnología software de Inteligencia Artificial (IA) en principio aplicable en diversos campos, sectores y clientes (un caso que ya utilizamos en un post sobre segmentación). Nuestra empresa debería tener en cuenta estas consideraciones:

  • Posiblemente nuestra empresa ya estaba vendiendo productos completos basados en su tecnología en uno o varios mercados finales (siguiendo una estrategia de segmentación o la toma de una “cabeza de playa” para “cruzar el abismo”). Por ejemplo, puede haberse enfocado en el mercado de asistentes virtuales para telcos. La pregunta ahora es si una estrategia basada en APIs no “canibalizaría” ese negocio, permitiendo que otros agentes entraran en él. Y la respuesta en general es que efectivamente ese riesgo existe (aunque se puede minimizar) pero siempre es mejor canibalizarnos nosotros y no que nos canibalicen otros.
  • Ciertamente, aunque nuestra empresa lleve tiempo enfocándose -e invirtiendo- en un mercado específico, con sus necesidades, clientes y soluciones concretos, podemos abrir nuestras APIs para fomentar que otros partners aborden nuevos mercados no relacionados: no son estrategias necesariamente incompatibles. Ello nos permite beneficiarnos de acceder a nuevos clientes, sectores, geografías, aplicaciones, etc. que de otro modo nos resultarían inaccesibles. Nuestra empresa de IA puede entrar, por ejemplo, en áreas de aplicación relacionadas con la planificación y la percepción automáticas. Incluso, como veremos, un negocio basado en el foco y la comercialización directa puede ser un complemento que contribuya al éxito de otro modelo basado en APIs más generales.
  • Esta nueva cadena de valor con partners desarrolladores y comercializadores nos evita tener que entrar en mercados donde no tenemos encaje, competencias ni recursos adecuados, nos evita distracciones y nos permite concentrarnos en nuestro negocio y tecnologías core.
  • El modelo impulsa la innovación abierta y el desarrollo de relaciones con partners: ¿quién puede desarrollar y comercializar las mejores soluciones para nuevos clientes, sino los fabricantes / integradores que están en un contacto cercano –geográfico, sectorial– con  ellos? Además esta colaboración fomenta la aparición de aplicaciones de nuestra tecnología para la long tail de clientes y escenarios infrecuentes e inesperados.
  • Resulta imprescindible aprovechar y gestionar las dinámicas propias de los productos plataforma y los ecosistemas de productos complementarios, fomentar los efectos de red y la estandarización alrededor de nuestra API. Aspectos como la anticipación, la generación de incentivos y el reclutamiento de aliados de todo tipo, la penetración rápida en el mercado y la creación de una base de usuarios, la gestión de las expectativas de todos los intervinientes … son determinantes.
  • Un modo de despliegue de APIs flexible, ubicuo y escalable basado en la nube nos permite entrar en el negocio a bajo coste y reduciendo riesgos y posteriormente crecer si hay demanda. Además, la posibilidad de monitorizar la utilización que los usuarios hacen de la API nos aporta información muy valiosa para mejorarla y desarrollar nuevos productos.
  • Mediante modelos fremium y SaaS podemos favorecer la prueba y la adopción de nuestra tecnología por parte de los partners desarrolladores de aplicaciones.

A cambio de estos beneficios, el modelo basado en APIs adolece de algunas desventajas (características de los enfoques fremium y SaaS):

  • Ingresos más lentos, al estar basados en la conversión de clientes gratuitos y en cuotas mensuales
  • Bajos costes de cambio para nuestros usuarios, que pueden abandonarnos por la competencia en cualquier momento o, en el mejor de los casos, al final del presente período de pago

Todas estas desventajas lo son, naturalmente, si comparamos con los enfoques más tradicionales de venta de licencias perpetuas (si es que este modelo va a seguir siendo sostenible durante mucho tiempo).

Adicionalmente, el de las APIs es un negocio tecnológico más donde la famosa frase de “en cuanto consiga que esto funcione me lo van a quitar de las manos” TAMPOCO funciona. Los ingenieros tenemos la tendencia a pensar que si publicamos nuestra API miles de colegas la van a empezar a usar al día siguiente, pero esto no suele ocurrir. No basta con desarrollar un conjunto de servicios web y publicarlos:

  • Es necesario que la API solucione problemas reales y urgentes de los partners desarrolladores … y que el producto final de los partners solucione problemas reales y urgentes de los usuarios.
  • Hay que hacer un marketing y una venta explícitos de la API a un público tan particular como los desarrolladores: es necesario trabajar con sus influenciadores, desarrollar comunidad …
  • Para fomentar el uso por una mayor cantidad y variedad de partners puede resultar útil publicar versiones diferentes de la API para diversos escenarios, sectores o necesidades. Por ejemplo, nuestra empresa de IA puede publicar una versión de la API para aplicaciones de planificación y otra para análisis de redes sociales. La naturaleza del software nos permite hacer esto más fácilmente que si se tratara de un componente hardware.
  • Especialmente si la tecnología es realmente nueva, siempre resulta difícil que una nueva plataforma arranque. Por eso, como decíamos en otro post, puede resultar inevitable que nosotros mismos tengamos que empezar a desarrollar y a comercializar aplicaciones de nuestras propias APIs en nichos seleccionados. Desde un punto de vista táctico, esto se puede llevar a cabo con una marca o desde otra empresa diferente. Así conseguiremos clientes, referencias, visibilidad, credibilidad…  (e ingresos, que nunca vienen mal)  para alcanzar una mínima masa crítica que dispare la difusión y adopción de la API.

Finalmente, para que la API tenga aceptación (y nuestro negocio tenga éxito) hay que envolverla dentro de un “producto completo” para organizaciones desarrolladoras, que incorpore elementos como: funcionalidad suficiente y probada, gestionabilidad (escalabilidad, seguridad, gestión de usuarios, gestión de tráfico), documentación, ejemplos de código, programas de partners, partners de referencia, soporte al desarrollo, recursos de marketing conjunto… y sobre el que se pueda definir una estrategia de monetización rentable.

4 comentarios

No vendas tu software, publica tu API (1)

por en 26 junio 2011

Las APIs (Interfaces de Programación de Aplicaciones) no son sólo un concepto software, sino que permiten abrir nuestra tecnología -datos, funcionalidad- para que sea utilizada por terceros en el desarrollo de nuevos productos que lleguen a clientes finales. Este tipo de «innovación abierta»  nos permite entrar en mercados a los que por limitaciones de conocimiento, recursos o presencia nunca podríamos acceder directamente.

Lo bueno que tiene esto del high-tech marketing es que cambia a tal velocidad que siempre tienes algo interesante sobre lo que escribir. No hace muchos años hablábamos de cómo Internet había revolucionado el marketing de productos software y ya es tiempo de ampliar estas ideas con algunos conceptos realmente rompedores. Y sin duda uno de ellos es el de las APIs (Application Programming Interface, Interfaz de Programación de Aplicaciones) como plataforma de marketing.

Para los lectores no tecnólogos, en el mundo del software una API es la interfaz técnica mediante la cual un programa pide cosas (datos, operaciones) a otro. Del mismo modo que las personas disponemos de Interfaces de Usuario para manejar las aplicaciones, un software puede usar APIs para solicitar los servicios que proporcionan otros programas. Existen APIs que permiten consultar y entregar datos, procesar/elaborar información, ejecutar lógica de negocio, etc. y con una gran variedad en cuanto a lenguajes de programación, formatos, protocolos, etc. Últimamente, la Web 2.0 ha popularizado una nueva arquitectura de aplicaciones con APIs ligeras (tipo REST) que han fomentado la proliferación de nuevas aplicaciones -conocidas como mashups– que se construyen combinando diversos servicios web.

Para una empresa que desea desarrollar nuevas soluciones y aplicaciones para el mercado final, tener acceso a APIs que proporcionan valiosos servicios de datos, funcionalidad, etc. es primordial a la hora de no “reinventar la rueda”, de alcanzar una alta productividad de desarrollo y de concentrarse en aquellos aspectos que realmente añaden valor adicional (aunque todo esto no sea gratis, como veremos).

Imagino que los lectores con un bagaje de Marketing puro estaréis empezando a pensar: “Todo esto está muy bien. Las APIs son muy útiles para sus usuarios (desarrolladores de aplicaciones) pero ¿de qué me sirven a mí como marketer?”. Pues la realidad es que las APIs no son solo un habilitador tecnológico, son también un habilitador comercial de primer orden. Como veremos, las APIs son la nueva plataforma de marketing de productos y tecnologías software (y de algunos otros relacionados). Voy a intentar explicarlo sin resultar aburrido ni a la gente de Marketing ni a la de Tecnología.

Antes que nada, para hacernos una idea de la magnitud e importancia de este fenómeno, el sitio ProgrammableWeb registra más de 3.400 APIs en categorías que van desde la publicidad a la información meteorológica. Y todas las grandes empresas de la Web publican -y comercializan- sus APIs: desde Google (cuya API Google Maps fue una de las primeras en popularizarse) hasta Twitter (que ya obtiene más tráfico –e ingresos– desde su API que desde su sitio web).

Esencialmente -si disponemos de una cierta tecnología, funcionalidad, datos … que puedan ser publicados como software- comercializar nuestras APIs implica un modelo de negocio diferente en el que, en lugar (o además) de desarrollar aplicaciones finales para resolver las necesidades de un cierto segmento de usuarios, facilitamos y fomentamos que terceras personas (otras empresas de producto software, integradores, etc.) sean quienes identifiquen dichos problemas del mercado, los resuelvan aplicando nuestras APIs y comercialicen esas soluciones integradas.

Es decir, estamos pasando de vender productos completos para usuarios finales a vender componentes software que serán utilizados por “desarrolladores” para proporcionar una serie de soluciones.  En definitiva, estamos dedicándonos a otras necesidades de mercado, otros clientes, otras propuestas de valor, otros productos, otras actividades y recursos clave necesarios, otros ámbitos y escalas, otra fórmula de beneficio… otro modelo de negocio.

Todo esto tiene mucho que ver con otro post en el que veíamos cómo una nueva tecnología -entendida como conocimiento o know-how– posee en sí misma un valor susceptible de comercializarse y cómo una empresa que se enfrenta a la decisión de “qué vender” tiene ante sí un continuo de opciones de comercialización, que van desde licenciar el know-how hasta vender soluciones completas. Y para elegir entre estas opciones (no necesariamente excluyentes) debe tenerse en cuenta diversos factores estratégicos: encaje tecnología / empresa / mercado, ventajas de primer entrante, recursos necesarios, etc.

El éxito de un modelo de negocio basado en API depende por tanto de fomentar el desarrollo de un ecosistema de partners que -aplicando nuestra plataforma tecnológica- creen valor para sus clientes finales. A cambio de integrarnos en la nueva cadena de valor este modelo ofrece la promesa de llegar a más mercados, aplicaciones, clientes, geografías… a través de estos partners, todo ello sin necesidad de conocer en detalle ni invertir específicamente en ninguno de ellos.  ¿Suena bien, verdad?

La esencia de las APIs como estrategia de marketing de software se basa en algunos ejes habitualmente tratados en este blog: dinámicas de productos plataforma y complementarios, efectos de red, estandarización, innovación abierta y un modo de despliegue flexible, ubicuo y escalable basado en la nube que nos permite entrar a bajo coste y crear modelos fremium y SaaS que favorezcan la prueba y la adopción de nuestra plataforma.

Trataremos de detallarlos (junto con algunas desventajas de este modelo) en un próximo post. Mientras tanto, ¿tenéis alguna experiencia en marketing basado en APIs?

6 comentarios

¿Análisis 2.0 de Medios 2.0?

por en 21 mayo 2011

(Este post se ha publicado previamente en el Blog de Daedalus. Podéis verlo completo aquí.)

Ahora que todas las empresas se han persuadido (por las buenas o por las malas) de la importancia de los nuevos medios sociales en la relación con su mercado y entienden que su participación debe empezar necesariamente por “escuchar”, asistimos a un momento de sobreoferta (casi diríamos sobredosis) de soluciones para monitorizar y analizar medios sociales.

Estas soluciones y servicios, donde es inevitable y deseable un componente manual “experto”, suelen basarse en herramientas software que automatizan los procesos de recopilación, filtrado, clasificación, reporting… sobre la ingente cantidad de datos proveniente de blogs, microblogs, redes, foros, etc.  Las herramientas más conocidas incluyen tanto productos gratuitos (Social Mention, SamePoint) como herramientas corporativas (Alterian, Radian6) … pero lo más llamativo es que actualmente existen más de 200 de esos productos –como atestigua la famosa  wiki mantenida por Ken Burbary – la inmensa mayoría centrada en el mercado anglófono, lo que nos da idea de la peculiaridad y el momento que atraviesa este negocio.

No obstante, parece que este mercado está pasando a una segunda fase de su ciclo de vida, tal como indican una explosión del interés y la demanda por parte de sus potenciales usuarios, la aparición de nuevos perfiles profesionales dedicados al manejo de estas herramientas y la adquisición de algunos de sus participantes por grandes empresas centradas en otras áreas como el business intelligence, el CRM o la publicidad. (La penúltima y hasta la fecha más importante de estas operaciones ha sido la compra de Radian6 por parte de Salesforce.com.)

¿Cuál puede ser la evolución de este mercado? Pues sin duda vendrá marcada por algunos condicionantes y objetivos muy particulares.

Big Data, Real-Time. El volumen de datos a procesar es ingente… y creciendo exponencialmente día a día. Por otra parte, las conversaciones en microblogs, redes, etc. son instantáneas y resulta imprescindible procesarlas en tiempo real. Cuanto antes gestionemos una queja o comentario negativo, mejor: no podemos “anticiparnos” a las consecuencias negativas de  un tweet si lo detectamos a los dos días de su emisión. En este contexto, unos procesos de monitorización a análisis intensivos en mano de obra no van a dar en general una respuesta suficiente ni en volúmenes ni en latencia.

Multimedia, multilenguaje y multifuente. Cámaras digitales, teléfonos móviles y la penetración de la Internet de banda ancha en todo el mundo permiten que los contenidos en todo tipo de formatos (imagen, vídeo) y lenguajes se multipliquen a través de una variedad infinita de plataformas. Y si incorporar el idioma y los medios de un nuevo país puede significar para cualquier proveedor de estas herramientas  un esfuerzo nada trivial, incorporar fotografías, voz o vídeo puede estar absolutamente fuera de su alcance.

¿Qué información queremos obtener? Inicialmente, muchas de estas herramientas empezaron respondiendo a preguntas influidas por un enfoque de marketing muy tradicional y outbound ¿Cuántas menciones tengo? ¿En qué medios? ¿Cuál es mi SOV? Actualmente el concepto más en boga es el análisis de sentimientos: ¿Lo que se dice sobre mí expresa una opinión/emoción/idea esencialmente positiva, negativa o neutra? Sin duda ésta es una información muy valiosa, pero queda muy lejos de la esencia de la comunicación social y del tipo de insights que estos medios pueden ofrecer (En realidad, estas respuestas son las que pueden proporcionar las tecnologías básicas de recuperación de información –crawling, indexación, búsqueda por palabra clave, taxonomías aplicadas en este contexto … hablaremos de ello a continuación.)

Muchas preguntas, pocas respuestas. La Web Social es una inmensa fuente de información sobre nuestros productos, empresa, competidores y sector. Enterradas entre miles de millones de posts, tweets y comentarios  están las respuestas a preguntas como éstas: ¿Qué opinan/sienten mis clientes sobre mis productos? ¿Cómo los usan? ¿Cómo los comparan con sus competidores? ¿En qué mejoras o nuevas ofertas están interesados? ¿Qué intenciones de compra/abandono manifiestan? ¿Quiénes son los influenciadores de mi mercado? ¿Qué eventos son relevantes en él? ¿Qué relaciones existen entre los agentes principales? ¿Cómo obtener una visión unificada de unas conversaciones que tienen lugar en canales diversos e inconexos? Dar respuesta a estas preguntas exige incorporar tecnologías que permitan “entender” automáticamente esos contenidos multimedia, tales como el Procesamiento de Lenguaje Natural o la Web Semántica.

Seguir leyendo en el Blog de Daedalus.

2 comentarios

Los planes de negocio son ABSOLUTAMENTE (im)prescindibles

por en 30 abril 2011

De planificar e intentar preverlo todo -incluso el desarrollo de un mercado totalmente nuevo- hemos pasado al extremo contrario: planificar es inútil, hay que lanzar el producto y “fallar deprisa”. Como en muchas otras cosas, la virtud está en el justo medio.

Durante las últimas semanas he tenido algunas conversaciones muy interesantes tanto con emprendedores como con inversores sobre la utilidad de los planes de negocio cuando se trata de productos/mercados realmente nuevos. Me han venido a la cabeza historias de hace algunos años, cuando trabajaba en una agencia pública de financiación de la I+D (el CDTI) y era política de la casa exigir a las empresas innovadoras unas previsiones financieras detalladas a cinco años de cualquier nuevo producto (desconozco si esto sigue siendo así)… unos números que se introducían en unos modelos de evaluación financiera para producir finalmente unas cifras de ROI totalmente inverosímiles.

En este blog hemos hablado muchas veces de cómo prever la demanda de un nuevo producto de manera mínimamente fiable es tanto más difícil cuanto mayor es su grado de innovación y de por qué en ese escenario de alta volatilidad y riesgo cualquier estrategia y planificación inicial van a ser papel mojado. Parafraseando a un famoso general prusiano, “Ningún plan de batalla (negocio) sobrevive al contacto con el enemigo (mercado)”.  Y mi experiencia en alguna startup me dice que la única cosa más estúpida que un plan de negocio irreal e ilusorio es perseverar en intentar cumplirlo … y repartir premios y castigos en función de ello.

Sin embargo, últimamente el péndulo de la planificación ha pasado al extremo contrario gracias a uno de los mantras de moda en la innovación y en emprendimiento, el famoso “Falla deprisa, falla barato”. Tal como hemos dicho en otras ocasiones, este concepto se ha sobresimplificado y malinterpretado y el problema es que se está tomando casi como un fin, en lugar de como un medio. Y es que, tal como parece desprenderse de este enfoque ¿quién necesita un plan de negocio? Mejor lancemos el producto y veamos qué pasa.

Para aquellos emprendedores que queráis explorar una visión contracorriente sobre el “fallar deprisa” os recomiendo “Why The ‘Fail Fast’ Mantra Needs to Fail, Fast” de Mark Suster, un empresario de éxito metido a inversor. En este post Mark critica la pereza intelectual, la incompetencia profesional y la irresponsabilidad y falta de ética con clientes, empleados e inversores de esta filosofía mal entendida.

Porque -como también hemos dicho por aquí- descubrir nuevos mercados y desarrollar nuevos productos no puede basarse en una «estrategia de palos de ciego”, sino en un proceso iterativo en el que resulta clave formular nuestras hipótesis, identificar y priorizar nuestros riesgos e incertidumbres y despejarlos mediante la experimentación en el mercado.  (Por cierto, para que no quepan dudas Mark Suster es un convencido de los enfoques tipo Customer Development, Lean Startup … y yo también pienso que son los más indicados en algunos casos.)

Y entonces, volviendo a la pregunta inicial ¿tenemos que hacer planes de negocio o no? ¿Valen realmente para algo o sólo para presentárselos a algún inversor con tendencia a la credulidad?

El propio Mark Suster nos propone una excelente reflexión en “Are Business Plans Still Necessary?” Para él, el Plan de Negocio no es un documento prolijo e irreal, sino un modelo financiero que sustancia nuestras hipótesis de negocio: quiénes (y cuántos) son nuestros clientes, qué precio están dispuestos a pagar, cuáles son los costes de proporcionarles nuestro producto/servicio y los de ganarlos como clientes,  qué cuota van a conseguir los productos competidores/alternativos,… y cuánto vamos a ganar. Como dice Mark, si no somos capaces de presentar una estimación mínimamente verosímil de estos números es porque probablemente no hemos hecho bien nuestros deberes.

¿Quiere esto decir que este plan inicial tiene que ser totalmente fiable? Por supuesto que no, ya sabemos que eso es imposible. Pero si el plan nos dice que no vamos a ganar dinero ni siquiera en el escenario más favorable es mejor que busquemos otra idea. No dejamos de pontificar sobre el Producto Mínimo Viable… ¿por qué no hablar antes del Plan Máximo Inviable? (tengo que conseguir el copyright del término antes de que se me adelante Eric ;- ). Imaginemos la situación: planteamos un escenario optimista y resulta que ni siquiera nos salen los números… ¡eso sí que es “fallar deprisa”, antes de haber gastado ni un solo euro en el desarrollo del producto!

Después de haber analizado/escrito personalmente unos cuantos planes de negocio, puedo decir que lo más importante de ellos no son las cifras sino

  • las asunciones o hipótesis en las que se basan dichas cifras (p.ej., tamaño del mercado potencial, cuota a alcanzar…)
  • la sensibilidad de las cifras respecto a las hipótesis (p.ej., si mi volumen de ingresos no es el previsto ¿puedo reducir costes de modo que los resultados no se resientan en exceso?)

Y por supuesto, el plan debe ser un documento vivo: a medida que vamos confirmando (o rechazando) hipótesis y validando (o pivotando) el modelo de negocio tenemos que ir rehaciéndolo, actualizando sus parámetros y recalculando sus previsiones. La planificación de negocio debe ser (igual que el descubrimiento del mercado o el desarrollo del producto) un proceso iterativo que puede empezar con un esfuerzo muy medido.

Para terminar, probablemente la frase que mejor describe la utilidad de los planes en escenarios de alta incertidumbre y competitividad es una de Dwight D. Eisenhower (otro general, esta vez más moderno): “Como preparación para la batalla siempre he descubierto que los planes son inútiles pero la planificación es indispensable.”

8 comentarios

¿Hacia dónde va el Marketing Inbound?

por en 27 marzo 2011

El mensaje del Marketing Inbound está calando. Pero este enfoque no siempre es aplicable y mal entendido puede degenerar en un marketing pasivo de mucho esfuerzo y pocos resultados. Probablemente su futuro está en un enfoque activo, de desarrollo de relaciones y de gestión de medios sociales.

El marketing inbound está despertando interés y ganando tracción. Su idea central de abandonar el tradicional “marketing de interrupción” y apostar por ganar la atención de nuestra audiencia y “conseguir que nos encuentren” en la Web ha ganado muchos adeptos (entre los que me cuento). Con dos millones de resultados sobre el tema en Google, son frecuentes los anuncios de proveedores de productos de automatización de marketing que añaden funcionalidad inbound a sus ofertas (LoopFuse, Genius, …). La empresa que acuñó el término, HubSpot, ha cruzado el umbral de los 4.000 clientes -casi todos en USA- lo que la convierte en uno de los proveedores de SaaS para empresas con crecimiento inicial más rápido. La última gran noticia es la reciente y millonaria inversión conjunta de Sequoia Capital, Google Ventures y Salesforce.com en la propia HubSpot.

Personalmente me ha tocado seguir bastante de cerca la evolución de HubSpot: hace años evalué el producto para usarlo tanto en mi empresa como en las de algunos de nuestros clientes (… aunque sin llegar a dar el paso, pero ésa es otra historia), contamos con personal certificado por la Inbound Marketing University, utilizo el caso HubSpot en los cursos y talleres sobre high-tech marketing que imparto y he tenido la oportunidad de cambiar impresiones en persona con los fundadores y el equipo directivo de HubSpot sobre algunos de los temas que vamos a tocar en este post (en la foto me tenéis con el mismísimo Dharmesh Shah).

Por eso me parece oportuno discutir algunos conceptos sobre qué es (y qué no es) el marketing inbound y sobre la evolución pasada y futura de HubSpot.

En primer lugar, no hay que confundir el marketing inbound con un marketing pasivo. Ciertamente, el marketing inbound más básico incide en técnicas como el SEO, la generación de contenidos y su publicación en blogs y otros medios sociales (que le dan a este enfoque un sesgo pasivo, consistente en esperar a que nuestros clientes busquen y facilitar que nos encuentren). Pero eso es sólo una cara de la moneda. Tan importantes como las técnicas mencionadas son la monitorización de medios sociales para descubrir dónde y cómo participan nuestros clientes y a quién siguen, la publicación en esos medios a través de comentarios en blogs, posts invitados, preguntas y respuestas en foros y redes sociales… que dirijan tráfico cualificado a nuestro sitio web y la construcción de una relación con clientes potenciales, influenciadores y fuentes de referencias. Y esta parte activa del marketing inbound, centrada en el desarrollo de relaciones, es realmente la más importante y según mi experiencia la que marca la diferencia entre el éxito y el fracaso. Por usar un símil del mundo cinegético, el marketing inbound se asemeja más a una caza con señuelo que a una al acecho.

Otro aspecto a tener en cuenta es que el marketing inbound (incluso en su versión más activa) en muchas ocasiones no es suficiente. A veces no basta con conseguir que sea muy fácil que nos encuentren, por muy bien que lo hagamos. Hay varias circunstancias que pueden obligarnos a sustituir o a complementar el marketing inbound con otros enfoques más directos, tanto online como offline. Alguna de estas circunstancias son:

  • Necesitamos resultados rápidos: el marketing inbound tarda meses en producir resultados, aunque un uso táctico de la publicidad en buscadores puede mejorarlos al principio.
  • Los potenciales clientes no buscan activamente o no participan en la conversación online sobre nuestros productos o soluciones… a veces ni siquiera sobre los problemas que resolvemos. Esto es habitual en el caso de productos innovadores, que satisfacen nuevas necesidades. También en el de aquellos usuarios que, teniendo un problema, están satisfechos con el status quo.
  • Necesitamos llegar a un target muy concreto, reducido e identificable: esperar a que ellos nos encuentren puede no ser lo más eficaz.
  • No basta con que los potenciales clientes nos encuentren y se registren (“conviertan”) en nuestra web, sino que es necesario cultivar la relación con ellos hasta que estén preparados para comprar. Ésta es una circunstancia inevitable en los productos de compra compleja.

Ni siquiera la propia HubSpot ha podido sustraerse a estas circunstancias. Aunque desde el principio “tomaban su propia medicina”, usando su producto para generar demanda, pronto percibieron la necesidad de complementar las técnicas inbound básicas con otras más directas y de cultivo de la relación. (Puedo atestiguar que los vendedores de HubSpot usan tácticas bastante convencionales, por no decir ciertamente insistentes.) Tanto es así que HubSpot ha incorporado recientemente funcionalidad de email marketing y lead nurturing a su producto. Lo que es más curioso, en este post de su CEO comentando la última entrada de inversores aparece un gráfico sobre sus fuentes de leads… y a menos que yo lo esté interpretando mal, la mayoría proviene del (¿obsoleto e intrusivo?) email, mientras que la búsqueda orgánica y los medios sociales son prácticamente testimoniales.

En cuanto al futuro del marketing inbound tal como lo concibe HubSpot, sin duda va a centrarse más en la gestión de las relaciones sociales y probablemente recogerá componentes de CRM Social. Una de las últimas iniciativas de la empresa es SocialInbox, una herramienta que nos permite usar eficazmente los sitios sociales para encontrar y cultivar oportunidades comerciales, agregando nuestra actividad en dichos medios en un “buzón” unificado. (SocialInbox se encuentra actualmente en beta privada.)

¿Qué opináis? ¿Cuál es vuestra experiencia con el marketing inbound? ¿Qué funciona y qué no?

12 comentarios

Los orígenes de Agile (2)

por en 13 marzo 2011

En la primera parte de este post anterior hablamos de cómo las características particulares de la tecnología software y el tipo de problemas que resuelve fueron abonando el terreno para la aparición de metodologías de desarrollo ligeras e iterativas, en un intento de mejorar las metodologías pesadas y por fases -influidas por las técnicas del desarrollo de proyectos en otros campos- que habían predominado hasta entonces.

En febrero de 2001 diecisiete expertos en desarrollo de software publicaron el “Manifesto for Agile Software Development”, que dio un nombre, una carta de naturaleza y una “marca” a todos esos métodos. Básicamente el Manifiesto consta de cuatro puntos en los que se da prioridad a los individuos y las interacciones, al software que funciona, a la colaboración con el cliente y a la respuesta ante el cambio frente a aspectos como los procesos, la documentación y los planes, que son prioritarios en otros enfoques. Como complemento incluye los doce principios básicos de Agile, entre los que se cuentan la satisfacción del cliente, la entrega temprana y continua de software que funciona, la cooperación y la autoorganización.

Es importante señalar que cuando se habla de Agile se suele hablar en realidad de alguna de las metodologías precursoras que mencionábamos en nuestro post anterior, y en particular de dos que son las más aceptadas (y que son anteriores al Manifiesto):

  • Scrum (1995), un marco iterativo e incremental para la gestión de proyectos, inicialmente propuesto para proyectos de desarrollo de productos y cuyo uso se ha centrado en proyectos de desarrollo de software.
  • XP (Extreme Programming, 1996) una metodología iterativa de desarrollo de software que aboga por entregas frecuentes de software en ciclos de desarrollo cortos y que recibe ese nombre por su énfasis en llevar al extremo esas buenas prácticas.

En realidad muchos de los principios de Agile (como por ejemplo incrementar la flexibilidad o la comunicación) son ideas de sentido común pensadas para enmendar el mal funcionamiento de las metodologías tradicionales en ciertos escenarios y para arreglar equipos de proyecto disfuncionales. Pero adicionalmente las metodologías Agile incorporan una serie de prácticas, roles y “valores” (daily scrums, war rooms, programación en parejas, retrospectivas, Scrum Masters, Product Owners…) y un énfasis en el funcionamiento del equipo de desarrollo que crean una “liturgia” y contribuyen a fomentar la identificación y la involucración, a veces casi religiosa, de sus practicantes. Lamentablemente, algunas organizaciones encuentran difícil implantar Agile en toda su extensión -con el cambio de cultura que requiere- y se quedan en sus prácticas superficiales, lo que no deja de ser un caso más de “cerdo con lápiz de labios”.

Los beneficios en cuanto a flexibilidad, adaptación, comunicación y coordinación que Agile aporta en escenarios inciertos y volátiles son evidentes. Sin embargo, en estos años se han alzado voces críticas con esta filosofía debido a posibles limitaciones como las siguientes:

  • Está muy enfocada en la captura de requisitos y el desarrollo, pero pone un foco escaso en el diseño y en la experiencia global del usuario de la solución
  • Falta de estructura y documentación
  • Puede aumentar el riesgo de una expansión incontrolada del alcance del proyecto
  • Solo funciona bien con desarrolladores experimentados
  • Requiere reuniones muy frecuentes con los clientes, con el consiguiente coste
  • Dificultad para escalar a proyectos grandes y con personal distribuido geográficamente

Por eso algunos dicen que, si bien Agile tiene cosas buenas y originales, “las cosas buenas no son tan originales y las cosas originales no son tan buenas”… Ese es también el motivo por el que las prácticas de Agile llevan años evolucionando para solucionar sus carencias y ser aplicables en escenarios más generales. En cualquier caso, es evidente que la flexibilidad que aporta Agile no es gratis y a veces sus costes pueden superar a sus beneficios.

Hasta aquí esta introducción a Agile. En próximos posts iremos abriendo el debate sobre preguntas como las siguientes:

Este post en Marketing & Innovación.

7 comentarios

¿Cuál es tu incertidumbre más importante? Elimínala rápidamente

por en 27 febrero 2011

En muchas ocasiones, el “ingrediente secreto” de una innovación de éxito está en identificar riesgos, priorizarlos y encontrar maneras creativas de eliminarlos.

Muchos directivos tienen (¿tenemos?) cableada en la cabeza la típica relación entre rentabilidad y riesgo de los activos financieros –a mayor riesgo, mayor rentabilidad– y la utilizan para medir nuevos negocios, productos y empresas. Desde ese punto de vista, que liga de manera estática ambas variables, el mayor riesgo es el precio a pagar por una mayor rentabilidad. Y, tal como prescriben las herramientas de análisis financiero al uso, aquellos nuevos proyectos cuya rentabilidad es inferior a la de otros proyectos con un nivel de riesgo equivalente sencillamente se quedan sin recursos para acometerlos.

Pero en realidad, como hemos dicho otras veces en este blog, la innovación se caracteriza por una serie de riesgos (tecnológicos, de mercado,  etc.) y las técnicas de reducción de la incertidumbre y de aprendizaje organizacional son imprescindibles en su eliminación y/o gestión. Por eso se agradecen artículos como “Beating the Odds When You Launch a New Venture”, de C. Gilbert y M. Eyring, que explican cómo la innovación de éxito no se basa en buscar la alta rentabilidad asociada a un riesgo elevado, sino en identificar rápidamente y eliminar sistemáticamente riesgos en el orden correcto y usando el nivel de recursos y los métodos más adecuados.

En el razonamiento de los autores resulta central la idea de que el valor y el riesgo de un nuevo producto o empresa están relacionados inversamente. Cuando reducimos el riesgo estamos aumentando el valor de la empresa. Pero es vital el orden en que abordamos estos riesgos, porque no todos son iguales. Por ejemplo, alguien interesado en lanzar un nuevo sitio web de comercio electrónico puede ir gestionando los riesgos a medida que se le van presentando -y probablemente el primero sería el diseño del sitio web. Sin embargo, a menos que primero confirme la demanda de los clientes éstos no van a comprar (por muy interactivo que sea el sitio) y si no responde a la pregunta del mix de producto es posible que se abastezca de productos que no va a poder vender.

Resolver rápidamente los riesgos más importantes acelera la curva de valor de la iniciativa o proyecto de que se trate. Gilbert y Eyring distinguen entre tres tipos de riesgos:

  • Riesgos fatales (deal-killer) son aquellos que si no se resuelven pueden dar al traste con toda la operación y habitualmente toman la forma de asunciones no justificadas o no contrastadas sobre las que se basa el negocio. Por ejemplo, ¿existe demanda para mi producto?
  • Riesgos que dependen de las decisiones tomadas (path-dependent) son aquellos que aparecen cuando el tomar la decisión o el camino equivocado (p.ej., la tecnología a aplicar, el mercado a abordar) podría significar la pérdida de grandes cantidades de tiempo y/o dinero.
  • Riesgos operativos que pueden resolverse sin gastar mucho tiempo ni dinero. Puesto que probablemente no vamos a tener dinero para resolverlos todos, aquí la clave está en cuáles y en qué orden se resuelven. La respuesta está en seleccionar aquéllos en los que el ratio de riesgo eliminado (o el consecuente aumento de valor) frente al coste del experimento necesario para eliminarlo –una especie de ROI del experimento– es más favorable.

Para hacer más predecible y eficiente la creación y gestión de nuevos productos y mercados es imprescindible identificar y priorizar sus riesgos y a continuación concebir y ejecutar experimentos que los resuelvan sistemáticamente. En cuanto a los tipos de experimentos más útiles, los autores distinguen dos:

  • Experimentos enfocados: se utilizan para eliminar un riesgo específico, habitualmente de tipo fatal o dependiente de las decisiones.
  • Experimentos integrados: están diseñados para comprobar cómo diversos elementos (el modelo de negocio, el producto, el mercado) funcionan conjuntamente. En esencia, implican lanzar el negocio –o una parte de él– en un ámbito restringido, p.ej., pilotos, prototipos, mercados de prueba.

Los grandes emprendedores no asumen riesgos: los gestionan. Determinar cuáles de las asunciones clave son correctas -y cuáles no- y hacer rápidamente los ajustes pertinentes marcan a menudo la diferencia entre el éxito y el fracaso.

Y tú ¿ya has identificado tu incertidumbre más importante?

12 comentarios

Los orígenes de Agile (1)

por en 13 febrero 2011

Desde hace unos años todo es Agile: la creación de software, el desarrollo de productos, las organizaciones… En este post explicamos los orígenes de esta filosofía, los beneficios que aporta y algunas de sus limitaciones.

Desde hace más de diez años las filosofías Agile están revolucionando el desarrollo de software. Por poner como ejemplo a alguien habitual en este blog, Steve Blank y Eric Ries han incorporado el Desarrollo Ágil como una de las bases de su Startup Stack (junto a Customer Development y Business Model Generation). Tal ha llegado a ser el predicamento de esta filosofía que en los últimos tiempos hay quien intenta convencernos de que Agile no solo es la panacea para el desarrollo de productos de cualquier tipo y en cualquier mercado, sino que todo aquel que no se haya convertido a Agile no es más que un “dinosaurio de las cascadas” o -lo que casi es peor- un “cowboy metido a programador”.

Por aportar un poco de contexto y abrir el debate sobre el papel de Agile en el desarrollo de productos vamos a repasar los orígenes y principios básicos de este movimiento (desde la perspectiva de alguien que -aunque hace mucho tiempo que dejó de programar- sí que dedicó los primeros años de su carrera a la Ingeniería del Software).

Lo primero que hay que decir es que lo que ahora se conoce como Agile surgió a partir de los años ochenta del pasado siglo (e incluso antes) en forma de metodologías “ligeras” de desarrollo software, como respuesta a las limitaciones de las metodologías “pesadas” tipo Waterfall (Cascada). Dichas metodologías pesadas se habían definido inicialmente para el desarrollo de proyectos de software a medida como una adaptación de los métodos al uso en los sectores de la fabricación y la construcción. Estos son entornos intensivos en el uso de materiales y maquinaria específica y donde los costes de hacer cambios cuando el proyecto está avanzado son prohibitivos, lo que exige una exhaustiva definición inicial de requisitos y un diseño cerrado. Las metodologías de desarrollo software tipo cascada asumen que hay un cliente que sabe cuál es su problema (por eso contrata el desarrollo) y se basan en unas fases secuenciales sin solapamientos y un diseño inicial estable e invariable (BDUF, Big Design Up Front).

Sin embargo el desarrollo de programas, por su propia naturaleza, no se ajusta muy bien a dichas condiciones: la complejidad de los problemas que se suelen resolver mediante software, la indefinición de los requisitos del cliente, la importancia de la interacción entre el producto final y sus usuarios, el continuo cambio tecnológico, etc. hacían imposible que aspectos como la solución dada al problema del cliente, los requisitos, el diseño e incluso la arquitectura del programa pudieran mantenerse constantes durante el desarrollo. Y el modelo en cascada no está preparado para encajar bien esos cambios.

Por otra parte la tecnología del software posee algunas características particulares que abrieron la posibilidad de otro tipo de metodologías; entre estas peculiaridades podemos citar la facilidad para “componentizar”/modularizar el desarrollo, crear prototipos o automatizar las pruebas y los (comparativamente) bajos costes de realizar cambios que aporta su naturaleza “inmaterial”. A partir de los pasados años ochenta empiezan a aparecer una serie de nuevos modelos para el desarrollo de software a medida, tales como el Desarrollo Rápido de Aplicaciones, el Espiral o el Proceso Unificado y -más tarde- metodologías como XP (Extreme Programming) o FDD (Feature Driven Development). Estas metodologías se basan en un desarrollo iterativo e incremental en el que los requisitos y las soluciones van evolucionando gracias a la comunicación con los usuarios y la colaboración entre equipos multidisciplinares autoorganizados, todo con el objetivo de mejorar la calidad del software y la capacidad de respuesta ante cambios en los requisitos del cliente y el entorno.

En la segunda parte de este post hablaremos del Agile Manifesto y de los beneficios y limitaciones de estos enfoques.

Este post en Marketing & Innovación.

9 comentarios

¿Por qué puede fracasar el marketing en medios sociales?

por en 30 enero 2011

El marketing social está en su pico de expectativas (algunos dicen incluso que cura el cáncer) pero permitid que os cuente un secreto: a veces no funciona. Aquéllos que queréis evitar encontraros en esa tesitura y, sobre todo, los que pensáis que “los medios sociales son gratis” o “eso es algo que se puede hacer con un becario”, seguid leyendo.

Desde hace algún tiempo corren ríos de e-tinta cantando los éxitos de las empresas en medios sociales (¿alguien no se ha enterado de lo de Old Spice?) pero lamentablemente se habla poco de los fracasos. En “7 Reasons Your Social Media Marketing Failed (and how to fix it!)” y “10 Reasons Why Social Media Fails” podéis encontrar listas con los errores más habituales y algunos consejos para evitarlos. A continuación os ofrezco un resumen (complementado con algún aprendizaje reciente en primera persona ;- )

  • No tenemos claros nuestros objetivos. ¿Qué queremos conseguir con nuestra presencia en medios sociales? Porque “estar en Facebook” o “que nos sigan en Twitter” no es una respuesta.
  • Desconocemos a nuestro público y qué medios utilizan (y cómo y para qué los utilizan). ¿En qué redes sociales participan? ¿Dónde comparten información y experiencias sobre productos como el nuestro? Cualquier enfoque decente de marketing social (como por ejemplo el POST de Forrester) debería empezar por la P de People. Por cierto, como veremos más tarde el mero hecho de concebirlos y tratarlos como “público” en el sentido de “audiencia” es ya un error.
  • Nula (o demasiada) estrategia. Ideas como “lo importante es estar en medios sociales” y “lo que hay que hacer es lanzarse” tienen su parte de verdad (sobre todo en un campo que está tomando forma ante nosotros y donde pocas prácticas están validadas) pero al final acabamos pareciendo pollos sin cabeza. El marketing social es uno más donde la estrategia sin ejecución es una ilusión pero la ejecución sin estrategia es el caos.
  • Contenidos pobres y poco adaptados a los diferentes medios. Ni siquiera el mejor guru social sería capaz de promover la mayoría de los contenidos que creamos (por aburridos y autoindulgentes). Además, solemos inundar todos los medios con los mismos contenidos, en lugar de tener el cuenta qué información buscan en cada uno nuestros clientes.
  • Expectativas irreales y poca paciencia. El marketing social no va a convertir un mal producto en oro ni va a convertir un servicio nefasto en maravilloso. Además, el éxito en el marketing social no se alcanza de la noche a la mañana, sino que pueden pasar meses antes de obtener resultados.
  • Falta de interacción. Éste es uno de los errores más habituales y graves. El marketing social no significa utilizar estos nuevos medios en modo unidireccional. Hay que prestar atención a las conversaciones que están teniendo lugar y crear diálogos personales con influenciadores y clientes. En lugar de “lanzar contenidos”, hacer preguntas o comentar las opiniones de otros en aquellos medios donde se expresan nuestros clientes.
  • Mala ejecución, recursos (y dinero) escasos e inadecuados. Por si alguien no se había dado cuenta, esas ideas acerca de que “los medios sociales son gratis” o “es algo que se puede hacer con un par de becarios avispados” NO son ciertas.
  • Demasiado énfasis en la venta. Las empresas que usen descaradamente los medios sociales para vender en lugar de para proporcionar información valiosa o para interactuar con sus clientes están abocadas al fracaso.
  • Objetivos y métricas que no son realmente sociales. Los medios sociales son una plataforma para construir relaciones con clientes, partners, prescriptores, etc. Las grandes cifras de “sigue”, “le gusta”… son un subproducto de unos buenos programas de relación en medios sociales.

¿Qué opináis? ¿Cuál es vuestra experiencia en marketing social y dónde es más fácil fallar?

5 comentarios

Diseñar para innovar

por en 16 enero 2011

El movimiento del Design Thinking propone el “pensar como un diseñador” como una estrategia interdisciplinar para la innovación. ¿Pero en qué consiste realmente?

El Design Thinking es un movimiento que en los últimos cinco años ha pasado por su pico de expectativas y -según algunos- ha entrado en su valle de la decepción. Esta corriente empezó a tomar forma a principios de la década del 2000, en un momento en que se atribuyó el éxito de algunas empresas -notablemente Apple- al diseño de sus productos (los lectores de este blog ya sabemos que eso es una simplificación ;- ) y otras muchas compañías buscaban respuestas para acelerar su crecimiento orgánico e innovar.

Algunas consultorías especializadas en diseño -especialmente IDEO-, autoras de proyectos emblemáticos, atrajeron la atención de un público que empezó a verlas como el paradigma de la creatividad y la innovación. (Como aclaración, estamos hablando de diseño con un alcance amplio, incluyendo el diseño industrial y su relación con fabricación, no solo de diseño de interacción, diseño gráfico o diseño web). Y así, las empresas -y las prácticas- del mundo del diseño fueron aplicándose en proyectos e iniciativas cada vez más complejos y ambiciosos.

La idea es que los mismos métodos y planteamientos que se aplican para crear los nuevos “objetos de deseo” que inundan el mercado resultan clave para mejorar servicios y experiencias de usuario y dotarles de un nuevo significado. Si tradicionalmente los diseñadores se habían enfocado en mejorar el aspecto y la funcionalidad de los productos, durante los últimos años el diseño ha ampliado su enfoque y llega a crear sistemas completos para proporcionar productos y servicios.

Desde mediados de la década pasada, ideólogos y portavoces en los campos empresarial, académico y periodístico como Tim Brown (CEO de IDEO), Roger Martin (decano de la Rotman School of Management) o Bruce Nussbaum (columnista en BusinessWeek) se erigieron en paladines del nuevo movimiento.

En su libro «Change by Design» Tim Brown define el design thinking como una metodología que impregna todo el espectro de actividades de la innovación con el espíritu del diseño centrado en las personas. Según el CEO de IDEO, el design thinking usa la sensibilidad y los métodos de los diseñadores para conjugar las necesidades de la gente con lo que es tecnológicamente factible y con lo que una estrategia de negocio viable puede convertir en valor para el cliente y en oportunidad de mercado. Las lentes de lo Deseable, lo Factible y lo Viable (empezando siempre por la primera) son las que el Diseño Centrado en las Personas utiliza para analizar el mundo.

Human-Centered Design

(Gráfico extraído del IDEO HCD Toolkit)

Esencialmente, la práctica del design thinking se basa en un proceso de descubrimiento creativo y enfocado en las personas, seguido de ciclos iterativos de prototipado, prueba y refinamiento.

Nuevamente recurriendo a Brown, en su artículo «Design Thinking» explica cómo este proceso no se articula como una serie predefinida de pasos ordenados, sino en un “sistema de tres estados”: Inspiración, Ideación e Implementación.

  • Inspiración. Las circunstancias (bien se trate de un problema o de una oportunidad) que motivan la búsqueda de soluciones. El punto de partida clásico para esta etapa es el brief: un conjunto de constricciones que proporciona al equipo del proyecto un marco desde el cual comenzar, benchmarks para medir el progreso y un conjunto de objetivos a alcanzar. El paso siguiente es descubrir cuáles son las necesidades de las personas a satisfacer. En esta fase –y puesto que frecuentemente la gente no puede decirnos cuáles son sus necesidades– sus comportamientos reales pueden proporcionarnos pistas muy valiosas sobre sus necesidades no cubiertas. La mejor fuente de información es salir al mundo y observar las experiencias reales de los usuarios.
  • Ideación. La generación, desarrollo y prueba de ideas que pueden conducir a soluciones. Una vez que se ha invertido un tiempo descubriendo necesidades, el equipo acomete un proceso de síntesis en el cual destilan lo que han observado y experimentado en forma de opciones e insights que puedan llevar a soluciones u oportunidades de cambio. Estas pueden consistir en visiones alternativas sobre un nuevo producto o en opciones para crear experiencias interactivas. Para asegurar un grado saludable de “pensamiento divergente” es imprescindible contar con equipos y personas interdisciplinares (“en forma de T”) y embarcarlos en un proceso estructurado de brainstorming. El objetivo es generar el mayor número posible de ideas (de lo más absurdo a lo más obvio) que son posteriormente agrupadas y clasificadas.
  • Implementación. Consiste en trazar un camino desde el proyecto hasta el mercado. Es en esta etapa cuando las mejores ideas que se han generado se convierten en un plan de acción concreto y completo. En el centro del proceso de implementación está el prototipado, que transforma las ideas en productos y servicios reales que se prueban, iteran y refinan. Mediante el prototipado, el proceso de diseño busca descubrir cualquier reto de implementación imprevisto o consecuencia no deseada. Adicionalmente, el storytelling, particularmente mediante multimedia, ayuda a comunicar la solución a un diverso rango de participantes dentro y fuera de la organización.

Estos estados no son lineales, sino que pueden tener lugar concurrentemente y pueden iterarse a medida que las ideas se van refinando y se toman nuevos caminos.

El design thinking nos aporta perspectivas muy valiosas para obtener mejores ideas (más radicalmente innovadoras) de manera más rápida y eficiente y no sólo es aplicable al desarrollo de nuevos productos y servicios. Sus proponentes lo presentan como un cambio radical en nuestra cultura: una reformulación de nuestro pensamiento y sensibilidad colectivos y de nuestros métodos de trabajo que les infunde un nuevo espíritu de innovación.

Al mundo de la empresa el design thinking le ha ofrecido un nuevo proceso capaz de producir creatividad e innovación y ha sido recibido como una panacea por gigantes como GE y Procter&Gamble. Pero es en su implementación en organizaciones de toda índole donde se han encontrado los mayores retos. A ellos dedicaremos un próximo post, pero antes veremos en qué consiste realmente pensar (y hacer) como un diseñador.

Este post en «Marketing & Innovación».

16 comentarios