• Author / Uploaded
• Albilla Rior

Citation preview

PRODUCT ACADEMY

VOL 1

AGILE PRODUCT

MANAGEMENT Guía de los Product Managers y Product Owners

Product Academy La guía de los Product Managers y los Product Owners

Este libro lo han escrito con pasión los Product Managers y los Product Owners de la empresa Thiga.

2

3

ÍNDICE

¿QUIÉNES SOMOS? Colocando el Producto en el corazón de cada empresa. Thiga divulga lo mejor del Product Management y del Product Design.

¿Quiénes somos?

05

Introducción

06

Imaginar el producto

08

Primer mandamiento: desarrolla tu visión de producto

09

Segundo mandamiento: no intentes solucionar un problema que no existe

16

Tercer mandamiento: evalúa el potencial de tu mercado

24

Construye tu producto

32

Nuestro objetivo es proporcionar a nuestros partners experiencia y soporte en

Cuarto mandamiento: construye tu hoja de ruta

33

cada paso de la creación, implementación y vida útil de un producto digital. Sin

Quinto mandamiento: escribe buenas historias de usuario

44

Sexto mandamiento: prioriza tu backlog

50

Acompañamos a nuestros clientes a través de: proyectos de Consultoría en es-

Séptimo mandamiento: no te olvides de la deuda técnica

56

trategia & organización así como Implants de perfiles de Product Managers &

Octavo mandamiento: todo es una cuestión de actitud

64

Haz crecer y mejora tu producto

70

Noveno mandamiento: construye u optimiza

71

sonrisas, Thiga ayuda a las organizaciones a crecer en madurez aconsejandoles,

Décimo mandamiento: utiliza tus productos

76

acompañándose con Product Managers experimentados y formándose.

Undécimo mandamiento: consigue nuevos usuarios

80

Duodécimo mandamiento: la adquisición es buena, pero la retención es mejor

88

sos y enfocados en ser un referente en la comunidad de producto. Organizamos

Decimotercer mandamiento: cuándo y por qué cancelar o retirar tu producto

96

conferencias, meetups, tenemos 3 libros publicados y escribimos artículos de

Agradecimientos y reconocimientos:

101

Nos definimos como una Boutique y un Pure Player de Product Management. Thiga ayuda redefinir la gestión de productos digitales aprovechando las mejores prácticas, metodologías y herramientas existentes al mismo tiempo que aplicamos nuestra experiencia obtenida de trabajar con más de 100 empresas a nivel internacional.

importar el estado o nivel de maduración en que se encuentre.

Product Designers en los equipos del cliente. Para nosotros, la teoría y la práctica van de la mano. Siempre con humildad y

En Thiga colocamos el Producto en el corazón de cada empresa. Estamos inmer-

manera periódica. Queremos aportar y compartir a la comunidad y con nuestros clientes hacemos lo mismo.

4

5

INTRODUCCIÓN Product Academy se ha escrito con el objetivo de ayudar a los Product Owners y Product Managers a desarrollar sus capacidades. Los Product Managers ya son una figura común desde hace décadas en la mayoría de industrias, pero su papel en la industria del software aún no está claro del todo. Y no precisamente porque este papel no sea importante, ¡más bien todo lo contrario!: el Product Owner ocupa una posición de vital importancia en el desarrollo de software de calidad. Y por eso hemos decidido escribir este libro. Nuestro objetivo es publicar un libro útil y específico sobre la gestión de productos, que refleje el concepto esencial de lo que implica realmente este trabajo y cómo hay que desempeñarlo. Este libro está dirigido a Product Owners y Product Managers que trabajan en un entorno ágil y que desean crear un nuevo producto o que están buscando nuevas formas de mejorar sus productos ya existentes. Así, el libro está dividido en tres partes que corresponden al ciclo de vida del producto: descubrimiento, desarrollo y crecimiento. El libro incluye los que consideramos los mandamientos más importantes que los Product Managers y Product Owners deben tener siempre en cuenta. Estos te guiarán desde la visión inicial del producto, pasando por todo su ciclo de vida y hasta que haya que prescindir de él. Cada mandamiento te ayudará a analizar las respuestas a preguntas reales que seguramente ya te habrás planteado: ¿Cómo puedo estar seguro de que estoy construyendo el producto adecuado? ¿Cómo puedo elaborar una hoja de ruta en sintonía con los objetivos de mi empresa? ¿Cómo puedo conectar con mis usuarios? ¿Debería cancelar mi producto? El equipo de Thiga se ha esforzado al máximo para compartir sus mejores métodos, herramientas y convicciones en las siguientes páginas. Esperamos que os ayuden, a ti y a tu equipo, a construir productos increíbles que se conviertan en el catalizador de los éxitos de tu empresa. ¡Feliz lectura!

6

Nicolas Léonard, Managing Director de Thiga España

7

Imaginar un producto

Primer mandamiento:

DESARROLLA TU VISIÓN DE PRODUCTO He inventado un quemador que no quema Así, nadie se quamará sin querer

En esta sección del libro te explicaremos cómo desarrollar y probar tus ideas de producto antes de apresurarte a desarrollarlo.

En fin... Frío Congelado Nada

Construir un producto digital con éxito es difícil; y seguramente por eso estás leyendo este libro. Tu producto necesita aportar un valor real a tus usuarios, pero no basta con eso: también tiene que ser de una altísima calidad, es decir, que tienes que construirlo adecuadamente. El mantra de cualquier Product Manager debería ser algo como «Construye el producto adecuado y constrúyelo adecuadamente». A medida que el ecosistema del desarrollo de software ha ido madurando, la cali-

8

dad de los productos digitales también ha experimentado una notable mejora, lo

9

cual está relacionado, por lo general, con la introducción de los enfoques ágiles

• ¿Cómo lo vas a introducir en el mercado?

y de DevOps en los equipos de desarrollo. Sin embargo, muchos equipos aún

• ¿Cuál es tu modelo de negocio?

aplican principios ágiles con la excusa de ir sacando nuevas features sobre la

• ¿Cómo puedes medir el éxito de tu producto?

marcha e incluso cambiar los objetivos principales del producto constantemente.

Para construir un producto con éxito, es vital que la visión de ese producto esté Aplicar el desarrollo de software ágil en un equipo no significa que debas desar-

claramente definida, la cual, además, te permitirá:

rollar todas las features que se te ocurran simplemente porque puedas o «tengas derecho» a cambiar de opinión cuando así lo consideres. Como Product Manager, tu papel es concebir una serie de bloques de software coherentes para que un

marketing y de finanzas.

equipo de desarrolladores y diseñadores les den vida, y no construir una lista infi-

• Motivar a tu equipo y a las partes interesadas.

nita de features sin conexión aparente. Dicho de otra forma: para dirigir el desar-

• Anticipar cómo planeas construir y entregar tu producto desde un punto de vista

rollo de tu producto, necesitas tener visión. Eso es lo que te permitirá construir un software que fidelizará aún más a los usuarios que ya tienes y conseguirá otros nuevos.

¿Y en qué consiste exactamente la visión de producto? Todas las empresas tienen una estrategia de negocio, y cada una de ellas necesita seguir un plan operativo para transformar su estrategia en un producto. La visión de producto se puede definir como la inventiva que permite que un Product Manager convierta una estrategia de negocio en un producto que funcione. La visión de producto no es un requisito único de los equipos ágiles, ni está limitada a proyectos de software. Sin embargo, para el caso de este libro, con visión de producto nos referimos al hilo conductor de las tres herramientas más importantes del Product Manager ágil: el backlog, el mapa de historias y el plan de lanzamientos (del cual hablaremos más adelante). Tu visión de producto debería responder a estas preguntas: • ¿Qué problema soluciona tu producto? • ¿Quién necesita tu solución? •¿Cómo puedes ofrecer una solución a los problemas a los que se enfrentan tus usuarios?

10

• Poner a trabajar en común a las partes interesadas: los equipos técnicos, de

tecnológico. Como se mencionó en la introducción, la visión de producto es aún más importante para los equipos ágiles que para aquellos que trabajan con enfoques de desarrollo más clásicos. En el desarrollo ágil, las features que se construyen y el orden que se sigue para ello no son siempre los mismos; por eso, la visión del producto cobra aún más importancia. Al comienzo de cada ciclo de desarrollo, todo el equipo tendrá que entender cómo encajan sus siguientes tareas en la definición principal y los objetivos del producto. Si no son capaces de hacerlo, quizá tengas que replantearte el trabajo que estáis haciendo. Pero también hablaremos de esto más adelante.

Enfoques para construir tu visión de producto Desde un punto de vista metodológico, te aconsejamos encarecidamente que pruebes el método del Lean Canvas. Este método, desarrollado por Ash Maurya, se basa en rellenar un Lean Canvas que te ayudará a definir e imaginar tu producto. Aunque al principio la idea del Lean Canvas pueda ser algo confusa, hay que pensar que la parte de la izquierda se refiere a nuestro producto y la derecha al mercado para el que lo estamos desarrollando:

11

LEAN CANVAS Métricas clave: ¿Qué métricas clave vas a utilizar para validar o invalidar tus Solución

=

Problema

?

ideas e hipótesis?

Ventaja injusta Propuesta única de valor

Métricas clave

+

Segmentos de usuarios

Estructura de costes: ¿Cuáles son tus costes fijos y variables? Fuentes de ingresos: ¿Cuál es tu modelo de negocio? ¿Cómo vas a generar ingre-

Canales

sos? Ventaja injusta: ¿Qué os convierte a ti y a tu equipo en las personas adecuadas para afrontar este problema y lanzar una nueva solución al mercado? Hablamos de cualquier cosa, como una ventaja técnica, la facilidad de acceso al mercado,

Estructura de costes

Fuentes de ingresos

una marca potente, etc. Construir un Lean Canvas es una gran forma de darle un enfoque integral y

PRODUCTO

MERCADO

constructivo a tu producto. Sin embargo, hay que tener en cuenta que el lienzo es la parte más importante de lo que refleja tu producto y negocio, así que no puedes esperar completarlo en una sola tarde de trabajo y utilizarlo a lo largo de todo un ciclo de vida del producto sin cuestionarlo en ningún momento. Así, no llegarás muy lejos. Este Lean Canvas tiene que actualizarse con regularidad, a medida que construyes tu producto y vas conociendo el mercado, y hasta que valides todas

Segmentos de clientes: ¿Quién es el usuario objetivo de tu producto? ¿Quiénes

tus hipótesis de partida, incluidas las más complejas.

serán los Early Adopters? Una vez organizado correctamente, tendremos que trabajar en profundidad en Problema: ¿Cuáles son los tres problemas principales que tu producto debería

cada sección del Lean Canvas. Lo explicaremos en el segundo y tercer manda-

solucionar para los Early Adopters y usuarios?

miento más detalladamente.

Propuesta única de valor: Es la parte clave del Lean Canvas donde intentarás definir cómo tu producto ofrece valor a los usuarios. Representa el punto crucial que decidirá si un usuario potencial se convierte en uno habitual. Solución: ¿Qué tres features principales abordarán las necesidades de tus futuros Early Adopters? Canales: Pueden ser gratuitos, de pago... ¡atrévete y propón algo diferente!

12

¿Cuánto tiempo debería llevarme? Mientras comienzas con el proceso de definición de tu visión de producto, no debemos olvidar nunca dos cosas: una, que invertir tiempo y recursos para definir la visión de producto «perfecta» no tiene por qué derivar necesariamente en un producto con éxito; dos, que tu visión deberá evolucionar con el tiempo y a medida que lo haga tu producto. En resumen: nada de lo que se te ocurra aquí o

13

en cualquier otra parte es algo definitivo.

producto que calculamos que tardará en desarrollase un año.

Si nos fijamos en muchas empresas emergentes, (startups) que ahora están te-

Las herramientas

niendo éxito, se ve claramente que aprendieron y trabajaron en redefinir su visión de producto a medida que lo iban construyendo; en el mundo de las startups, se trata de un proceso más comúnmente conocido como «pivotar». El equipo de Pinterest, la popular red social para descubrir productos, ideas y recetas, comenzó construyendo un carrito de compra multisitio donde los usuarios pudiesen añadir sus productos para que se les notificase su disponibilidad. Tras unos meses en marcha con su producto inicial, conocido como Tote, el equipo observó que la feature más valiosa de este era una lista de productos de diferentes tiendas en línea que se pudiera compartir. Y fue entonces cuando decidieron pivotar. Este movimiento hizo que Pinterest se convirtiese en el producto de éxito que conocemos y utilizamos hoy en día. Este es un buen ejemplo de cómo una visión de producto sólida permitió al equipo de Pinterest identificar a sus usuarios, su mercado y los problemas a los que se enfrentaban. Aunque las features iniciales que escogieron para construirlo no respondían de forma directa a los problemas más importantes de sus usuarios, sí que lograron aproximarse, y por eso fueron capaces de cambiar su visión y producto. Es muy posible que tu visión acabe evolucionando, pero, incluso así, el hecho de dedicar más tiempo a crear la primera versión del producto podría ayudarte a dar con la forma de introducirlo en el mercado adecuado sin invertir demasiado tiempo o recursos. En vista de lo anterior, parece que merece la pena materializar tu visión de producto, pero ¿cuánto tiempo y esfuerzo te va a costar? Debería ser un punto medio entre ser excesivamente cauto y pasar muchos meses comprobando tus hipótesis con experimentos empresariales complejos, y preparar tu Lean Canvas en una servilleta a la hora de comer. Para determinar en qué parte de la escala deberías moverte, fíjate en tus competidores: ¿cuánto tiempo les llevó construir su producto? ¿Cuánto crees que te va a llevar a ti? Por regla general, creemos que dedicarle alrededor de un mes a este proceso es una apuesta segura para un

14

Además del Lean Canvas, tienes otras herramientas interesantes a tu disposición: Tablón de visión de producto: http://romanpichler.com/tools/vision-board Generación de modelo de negocio: https://strategyzer.com/ Herramientas en línea: https://leanstack.com/ Tablón de validación: https://www.leanstartupmachine.com/validationboard/

Segundo mandamiento:

NO INTENTES SOLUCIONAR UN PROBLEMA QUE NO EXISTE

un producto con éxito, te recomendamos un sano ejercicio de autocrítica. La chispa de creatividad que, con el tiempo, dio lugar a una imagen mental de un producto digital de pleno derecho se basa seguramente en ciertas asunciones e hipótesis. Ahora es el momento de cuestionarlas. Antes de ponernos manos a la obra, recordemos las buenas prácticas para presentar un nuevo producto digital en el mercado. Muchas empresas nuevas están

¡Mira! te he traído muchas cosas interesentes para que no te aburras.

utilizando un enfoque que consiste en lanzar un producto mínimamente viable (MVP, en inglés) al mercado tan pronto como pueden. Esta técnica supone varias ventajas, como la de poder comprobar si tu producto es realmente la solución a los problemas de tus usuarios sin tener que invertir los recursos y el tiempo necesarios para construir un producto complejo con todo tipo de features. Siguiendo este enfoque, el MVP suele comercializarse y enviarse solamente a los Early Adopters, puesto que estos usuarios son los más propensos a adoptar tu producto. Además, este grupo de usuarios debería de ser más fácil y barato de conseguir a través de tus canales de distribución seleccionados (de los que hablaremos más adelante). También son los primeros usuarios a los que acudirás cuando lances tu producto, así que tiene sentido empezar por ellos. Una vez que hayas validado tus hipótesis y asunciones iniciales con estos usuarios (¡o abandonado tu producto, directamente!) podrás expandirte y venderle ese producto a una audiencia más amplia, o tu «mayoría activa», como expresa el siguiente diagrama de Moore.

DIAGRAMA DE MOORE

Muchos productos no encuentran su mercado y terminan por desaparecer. Los productos fracasan por muchas razones, pero suelen hacerlo porque intentan solucionar un problema que no existe. Para evitar este problema tan común y mejorar así tus posibilidades de construir

16

Innovadores

Early adopters

Mayoría activa

Mayoría pasiva

Escépticos

17

Facebook es famoso por haber aplicado este enfoque. Cuando lanzaron primero

los inversores y desarrolladores quieran ponerse a construir el producto lo antes

su servicio en Harvard, para después extenderse a otras universidades, el equipo

posible... Tu trabajo como Product Manager es evitar que todos estos objetivos

de Facebook encontró usuarios dispuestos a probar nuevas tecnologías y tam-

entren en conflicto y respaldar las decisiones de producto con información que

bién un grupo de gente con una gran capacidad social y muchas conexiones;

puedas obtener hablando con otras personas... ¡y en la vida real!

un campo de prueba perfecto para la primera versión del producto de Facebook. Tras probar el servicio y las asunciones que iban con él, la empresa fue poco a

Los enfoques descritos en los siguientes párrafos te permitirán empezar a rel-

poco expandiendo su base de usuarios a otros segmentos de mercado. A este

lenar el Lean Canvas con información sobre tus usuarios (problemas, segmento

enfoque lo llamamos "Think big, start small " («Pensar a lo grande y comenzar

de cliente, propuesta única de valor). A cambio, esta parte del Lean Canvas te

poco a poco»). Esta actitud es muy diferente de la de Get Big Fast («Crecer mucho

permitirá gestionar las decisiones de producto centrándote en el usuario, para

en poco tiempo» que empleaban las startups de los años 2000, cuando algunas

garantizar en todo momento que estarás lo más cerca posible de tus usuarios,

empresas infames se gastaron millones para desarrollar un producto sin poner

sus problemas y necesidades.

en duda jamás sus maravillosas ideas. Ahora, volvamos a las hipótesis que residen en los más profundo de la concepción de tu producto. Haz una lista de todas las hipótesis que te gustaría poner a prueba y que estén relacionadas con los Early Adopters a los que esperas ofrecerles tu producto primero: ¿Qué problemas están teniendo tus Early Adopters? ¿Cómo va a solucionar tu producto esos problemas? Posteriormente, tendrás que comprobar tu hipótesis de la forma más rápida y barata posible antes de salir a conocer a tus futuros usuarios. Puedes empezar analizando el mercado y a los usuarios para los cuales planeas construir tu MVP y ponerte en contacto con expertos de la industria, así como otros compañeros PM de producto de otras empresas. Combina esta información e intenta responder a estas preguntas: ¿Qué otros productos parecidos están utilizando? ¿Qué productos ya existentes similares al tuyo parecen solucionar su problema? ¿Los están utilizando tus Early Adopters? ¿Por qué? Utiliza estas respuestas para afinar o cambiar las hipótesis que te gustaría probar. Ahora es el momento de salir y conocer a tus futuros Early Adopters. Esto no siempre es fácil, porque puedes encontrarte con problemas procedentes de cualquier parte de tu empresa: tal vez el equipo de ventas no quiera poner en riesgo sus relaciones con los clientes; quizás el equipo de comunicación no quiera ar-

Conoce y entiende a tus Early Adopters Identifica tu panel mediante el uso de persona Para poner a prueba estas asunciones, necesitas crear un panel de Early Adopters. Estos usuarios te ayudarán a responder preguntas clave, iterar tu producto y entender mejor tu base de usuarios más amplia. Si la visión y promesa de tu producto les convence, es posible que incluso se conviertan en tus primeros usuarios reales y embajadores de productos. Antes de salir e intentar conocer a tus futuros Early Adopters, te recomendamos que dediques un tiempo a definir el perfil de este grupo (por ahora) imaginario de personas. El tipo de información que debería incluir tu producto cambia mucho según lo que estés intentando construir. Por ejemplo, el perfil de un Early Adopter de un producto B2B (para otras empresas) podría centrarse en unas habilidades o un perfil profesional muy específicos, mientras que un producto con una audiencia más amplia definirá a sus usuarios mediante indicadores socioeconómicos: edad, ingresos, educación, cultura digital... Ten este perfil en mente cuando tomes decisiones de diseño de producto y asegúrate de que sigues actualizando tus personas a medida que aprendes más de tus usuarios.

riesgarse a encontrarse con un problema de relaciones públicas; o puede que

18

19

Selecciona un panel de Early Adopters

problema para comprender su procedencia, cómo les afecta a los usuarios y qué están haciendo o utilizando estos ahora para evitarlo. No te quedes simplemente

Seleccionar un panel puede resultar frustrante al comienzo. Nosotros reco-

con lo que te dicen: pídeles ejemplos, historias y pruebas que demuestren que

mendamos empezar por lo más sencillo, captando gente que sabes que encaja

el problema existe en sus vidas. Si tu entrevistado te cuenta que están teniendo

con el perfil que has creado. Si les pides que te presenten a sus amigos y colegas,

un problema real, pero que no están haciendo nada al respecto, es posible que te

deberías poder formar un grupo de posibles Early Adopters.

esté mintiendo (de forma consciente o inconsciente); o quizás el problema que habías detectado en realidad no es tan importante para ellos.

Si esto no fuera suficiente, intenta conocer a tus usuarios ideales en el lugar donde se reúnan, ya sea en línea (redes sociales, foros especializados, etc.) o

Por lo general, puedes estar relativamente seguro de que has dado en el clavo

en el mundo real (en eventos, encuentros, seminarios...). Como último recurso

si una cantidad de entrevistados considerable (entre 10 y 20) te dicen que está

(eficaz, pero caro) puedes contratar a una agencia especializada para que se

teniendo el mismo problema. Mejor incluso es que muchos de ellos estén bus-

encargue del panel por ti. Esto es especialmente útil para productos muy especí-

cando una solución activamente, que hayan creado una ellos mismos o que estén

ficos, pero ten en cuenta el coste.

utilizando un producto ya existente (y si están pagando por ese producto, mucho mejor).

Una vez que estés satisfecho con el panel resultante, tendrás que empezar a pensar en cómo vas a entrevistarlos. Te recomendamos que lo hagas tú mismo;

Búsqueda de soluciones

según nuestra experiencia, los Product Managers que se implican personalmente obtienen mucho más conocimiento y valor durante el proceso. Esto se aplica tan-

Cuando estés seguro de que estás afrontando el problema que de verdad merece

to a la hora de dirigir las entrevistas como de analizar los datos.

la pena solucionar, ya es hora de empezar a pensar en algunas soluciones. Como habrás observado durante las entrevistas, mucha gente es muy buena descri-

Sus problemas son tus soluciones Entrevistas y observaciones Antes de comenzar, recuerda que empezaste con este proceso para aprender de tus usuarios. Vamos, que no es el momento de vender tu futuro producto. Te recomendamos empezar con algunas entrevistas individuales (y a ser posible cara a cara, que siempre es lo mejor). Si no tienes mucha experiencia, no dudes en crear un guión de entrevista inspirándote en algunos de los grandes ejemplos que existen, como el de Ash Maurya en Running Lean1. El objetivo de todo esto es que compares tu visión del problema con la de tu entrevistado. Repasa todos los problemas que has identificado uno a uno. Esfuérzate por llegar a la raíz del

20

1. amazon.com/Running-Lean-Iterate-Plan-Works/dp/1449305172

biendo sus problemas hasta el más mínimo detalle, pero a muy pocos se les da bien dar con las soluciones. Nos gusta mucho el Design Thinking como marco de herramientas que puede ayudarte a convertir una lista de problemas observados en posibles soluciones. He aquí los pasos y principios más importantes: Trabaja con un equipo multidisciplinar, compuesto por tecnólogos, diseñadores, expertos empresariales... Todos desempeñarán un papel importante y aportarán una perspectiva interesante. Comienza con una fase de divergencia: utiliza todo el material que has acumulado hasta ahora, incluidas las transcripciones de las entrevistas, para encontrar y hacer una lista de varias posibles soluciones. No te preocupes si alguna

21

idea te parece un tanto descabellada. Reúne al equipo e identifica algunas de las mejores ideas durante una fase de convergencia. Puedes evaluar las ideas según su viabilidad técnica, si encajan con tus gamas de productos existentes y tu marca, las posibilidades de monetización, la competencia existente, su singularidad y la posibilidad de patentarlas...

Construye prototipos Todo vale a la hora de construir prototipos. Lo que buscas es una forma rápida, fácil y sencilla (es decir, con la menor cantidad de código posible) de expresar tus ideas. Utiliza las herramientas que tienes a tu disposición para construir algo que puedas presentar a tu panel: desde vídeos hasta bocetos de interfaces, maquetas y prototipos (creados con herramientas como InVision, Marvel, Sketch, Balsamiq...). Una vez más, te recomendamos que intentéis probar esto entre vosotros para poder iterar rápidamente y con el menor coste posible, sin necesidad de recurrir a un estudio de diseño o cualquier otra ayuda externa.

Pon tus ideas a prueba Ahora que ya tienes el prototipo de tu solución, es el momento de volver a llamar a los miembros de tu panel y organizar sesiones de pruebas con ellos. El objetivo es entender si las soluciones que has propuesto encajan con los problemas que están experimentando los miembros del panel. Deja que echen un vistazo a tu prototipo o que lo utilicen; pregúntales lo que les gusta y lo que no y lo que les parece importante, irrelevante o que falta en el prototipo que has creado. Si obtienes muchas respuestas positivas, asegúrate de que los miembros del panel no están sesgados o intentando ser amables. Pregúntales si les gustaría apuntarse a tu lista de correo para estar al tanto de la salida del producto, hacer una reserva o ayudarte a difundir información sobre tu producto. Esto te ayudará a medir el entusiasmo de los miembros del panel y, con suerte, obtener el beneficio añadido de asegurarte de que se conviertan en tus primeros clientes cuando lances el producto.

22

23

Tercer mandamiento:

EVALÚA EL POTENCIAL DE TU MERCADO

Las empresas grandes suelen llevar a cabo estudios de oportunidad y viabilidad exhaustivos que les ayuden a entender si merece la pena construir un producto o entrar en un mercado. Normalmente, las empresas utilizan recursos internos para estudiar el mercado y hacer proyecciones de negocio e ingresos que permitan a sus líderes empresariales tomar decisiones informadas sobre una nueva

¡Anímate! Todo saldrá bien

No lo estoy pensando...

oportunidad de producto. Sin embargo, estos estudios suelen llevar tiempo, lo que significa que tendrás menos espacio para construir e iterar sobre el producto, algo que consideramos muy importante. Es posible que creas que una buena forma de solucionar esto es recurrir a estudios de mercado que están a la venta. Según nuestra propia experiencia, esos estudios nunca se adecuan con precisión al caso de negocio que estamos estudiando; sus datos pueden aportar poca claridad o ser incluso contradictorios, lo que os podría desviar a ti y a tu producto del camino correcto. Existen herramientas y métodos que puedes utilizar para poner a prueba tus hipótesis de negocio de forma ágil y sencilla, tanto si eres el Product Manager de una empresa de la lista Fortune 100 como de una startup de solo 3 personas.

Ahora mismo, deberías tener cierta seguridad de que has identificado un grupo de usuarios que están experimentando un problema que les está provocando dificultades reales. También deberías haber identificado la solución que vas a intentar ofrecer a estos primeros usuarios para ayudarles con los problemas que se están encontrando. Podría ser tentador lanzarse a desarrollar el producto en esta etapa. A pesar de que has identificado potencialmente un problema importante, un grupo clave de usuarios y un producto sólido, todavía no tienes definido tu modelo de negocio: ¿Qué aspecto tiene tu estructura de costes? ¿Cómo vas a generar ingresos? ¿Cuánto va a costar tu producto y cómo lo van a adquirir tus clientes? No importa que hayas imaginado un producto muy sólido, vas a tener que poner a prueba las asunciones que has hecho de tu mercado antes de que puedas empezar a construirlo.

24

Mira de puertas para dentro: estudia a tu equipo Antes de desviar tu mirada hacia el mercado, que es incontrolable y cambiante, te recomendamos que te fijes bien en tu empresa y equipo, los dos elementos que deberías tener más controlados. Como Product Manager, puedes plantearte varias preguntas que te ayudarán a tener una idea más concreta de las posibilidades que tiene tu producto de triunfar: ¿Eres verdaderamente capaz de construir este producto correctamente? Durante esta fase, evalúa las capacidades de tu equipo: ¿Tienes lo que hay que tener, técnicamente, para presentar este producto? ¿Tienes lo que hay que tener para vender el producto con eficacia y asegurarte de que tu plan de negocio funcione?

25

crear un producto muy específico que solamente incluya a un grupo de posibles ¿Por qué debería tu empresa construir este producto? Lo que realmente im-

usuarios pequeño? ¿Y si fuera al revés? En cualquier caso, hacer una estimación

porta aquí es analizar cualquier ventaja competitiva u otros puntos fuertes

del tamaño de tu mercado potencial te permitirá entender si el modelo de negocio

que puedas tener respecto a la competencia. Y ahí es donde entra la sección

que has identificado es viable. Como ventaja añadida, este ejercicio permite que

«Ventaja injusta» de tu Lean Canvas. Dichas ventajas pueden ser de cualquier

fluyan las ideas sobre cómo adquirir usuarios, ya que la situación puede variar

tipo: desde una base de clientes existente hasta una oportunidad de asociación

mucho cuando te diriges a un mercado más abierto o a otro más específico.

exclusiva, una ventaja tecnológica, un equipo especializado o una estrategia de marketing... No te olvides de que ser ágil y rápido también puede ser una ven-

El objetivo de evaluar el mercado es simplemente calcular la cantidad total de

taja, pues te ayudaría a ser el primero en entrar en el mercado. No hay empresa

posibles usuarios que tu producto o servicio pueden adquirir. Si ampliamos esta

que pueda combinar todas estas ventajas, pero sí es lógico que cuentes con

idea, también podremos calcular los posibles ingresos aplicando la siguiente fór-

una o dos antes de comenzar a construir el producto para crear el contexto

mula:

adecuado que te ayudará a tener éxito en el mercado elegido. Ingresos = (Tamaño de mercado) x (Porcentaje de mercado estimado) x (Estima¿Encaja el producto con el resto de tu estrategia de negocio y de marca? ¿Tiene

ción de cantidad de compra media por cliente) x (Precio por compra).

sentido convertir tu idea en un producto, teniendo en cuenta el resto de productos y servicios que ofrece tu empresa? Esta pregunta también te ayuda a

A continuación, explicamos las ideas clave más comunes de ambos enfoques

asegurarte que no planeas construir algo que podría entrar en conflicto con

para calcular el tamaño de un mercado:

otras partes de tu empresa. Enfoque Top down (descendente): Comienza con toda la población, aplicando ¿Es el momento adecuado para lanzar tu producto? El tiempo es un factor muy

después varios filtros sociales y demográficos hasta llegar a tu grupo de usua-

importante para el éxito de tu producto, ya que depende de las evoluciones tec-

rios. Por ejemplo, en el caso de una aplicación de móvil que ayude a las perso-

nológicas y los mercados en constante cambio. Actuar con rapidez no siempre

nas mayores a pedir comida para sus mascotas en Estados Unidos, tendrías

es la mejor solución. Por una parte, comenzar a adquirir usuarios antes que

que aplicar los siguientes filtros: > Personas mayores de 65 en EE. UU. > Que

la competencia podría suponer una gran ventaja competitiva, pero, por otra,

tengan smartphone > Que tengan mascotas > Que compren en línea. En este

entrar demasiado pronto en el mercado podría acabar mal (como aprendimos

ejemplo podemos suponer que seguramente nuestro mercado será bastante

con el caso de Webvan).

pequeño, ya que las personas mayores no suelen utilizar sus teléfonos tanto como las generaciones más jóvenes, y mucho menos para hacer sus compras.

26

Mira de puertas para afuera: ¿cómo de grande es el mercado?

Para ampliar nuestra visión del mercado potencial, tal vez podríamos incluir a

Ahora, supongamos que tu producto va a cumplir con las expectativas de tus

Enfoque Bottom up (ascendente): Este enfoque es factible en mercados madu-

usuarios; lo siguiente que tendríamos que hacer es calcular la dimensión de tu

ros y ya establecidos. En este caso, deberías poder evaluar el tamaño total del

posible grupo de usuarios. ¿Es posible que tu visión de producto actual te lleve a

mercado calculando el número de usuarios de todos tus futuros competidores.

niños y cuidadores de personas mayores que pudieran utilizar la aplicación en su lugar.

27

Esto a veces es más fácil de decir que hacer, pues dependerá de cuál sea tu

o menos clara de que va a cuajar en el mercado. Por suerte, hay algunas formas

mercado y de la transparencia de tus competidores al publicar sus cifras. Por

rápidas y seguras de comprobarlo, como las reservas y el micromecenazgo. Es-

ejemplo, puede que te cueste más averiguar esas cifras en el espacio B2B enfo-

tas dos iniciativas comparten dos objetivos en común. Por un lado, te permitirán

cado a empresas, mientras que en el caso de las redes sociales tus rivales sue-

saber si tus futuros usuarios están realmente preparados para pagar o utilizar

len publicar sus cifras de usuarios con frecuencia.

tu producto, lo cual, llegados a esta etapa, es el indicador más sólido de que tu producto y el mercado están en sintonía. Por otra parte, las reservas te permitirán

Multiplicando estos números por el grado de penetración que crees que será

financiar y acelerar el desarrollo de tu producto (por ejemplo, ampliando tu equi-

posible por año, ya puedes empezar a hacerte una idea de cuál va a ser tu adqui-

po o agilizando la fabricación del producto). Pebble es conocida por aplicar este

sición potencial de usuarios.

enfoque, y ha recurrido a varias campañas de micromecenazgo en Kickstarter que batieron récords y que les ayudaron a lanzar cada una de las iteraciones de

A lo mejor te preocupa que tu mercado potencial sea muy pequeño y tu producto

sus smartwatch. Eso les permitió medir el interés del mercado por sus productos

demasiado específico. No obstante, eso no significa que debas descartar tu idea,

y obtener el capital necesario para agilizar su proceso de fabricación.

sino que tu modelo de negocio necesita adaptarse a un mercado más concreto. Aunque no existan unas normas rápidas o preconcebidas, lo cierto es que,

Sin embargo, este enfoque no siempre es factible por distintos motivos. Otra tác-

en general, los negocios de publicidad y las microtransacciones no funcionan

tica que te permitirá poner a prueba el interés de tu mercado con rapidez y sin

demasiado bien en los mercados minoritarios, puesto que los modelos que se

muchos costes es la prueba de humo. Las pruebas de humo se pueden realizar

basan en grandes volúmenes de pequeños pagos requieren muchos usuarios

de varias formas, pero la idea general es simular la existencia de tu producto o

para poder ser rentables.

bien una nueva feature para medir el interés potencial de tus usuarios. Se podría, por ejemplo, crear una campaña de publicidad digital que redirija a una página

Tal vez sea justo lo contrario, y te preocupe que tu mercado sea demasiado

de destino que solo muestre maquetas de tu futura aplicación y que invite a los

grande y que esté lleno de competidores maduros que ya ofrecen productos de

visitantes a apuntarse para recibir un enlace de descarga en cuanto la aplica-

calidad. Esto no tiene por qué ser un obstáculo, pues, en cierto modo, demuestra

ción esté lista. A esto se le suele llamar puerta falsa, porque se está invitando a

que merece la pena apostar por ese mercado. Sin embargo, tendrás que centrarte

clientes potenciales a que atraviesen una puerta que no lleva a ninguna parte.

en diferenciar tu producto para atraer así a los usuarios. Un ejemplo es el caso de Dropbox, que lanzó su producto en 2008, cuando ya existían muchas solu-

Lo más importante de este enfoque es definir claramente el embudo de adqui-

ciones de almacenamiento en la nube. Fueron capaces de diferenciarse gracias

sición de usuarios y las métricas clave que, con suerte, te permitirán deducir

a un producto muy fácil de adoptar e intuitivo, además de ser estable. Hoy en día,

cuántos de tus usuarios o visitantes habrían empezado a utilizar tu producto si

son una de las empresas líderes de su mercado.

estuviese disponible. Este ejercicio requiere un gran volumen de usuarios, ya que estarás extrapolando la información obtenida con esta estrategia para evaluar

Poner a prueba tu mercado La forma más fácil y sencilla de medir el interés de tu mercado respecto a tu producto es ver si tus futuros usuarios lo comprarán o lo usarán. Ojo, con esto no te estamos animando a que desarrolles tu producto antes de tener una idea más

28

el tamaño total de tu mercado. Por ejemplo, si tu campaña de AdWords la vieron 10 000 usuarios y 1000 de ellos dejaron sus correos para ser los primeros en descargar tu aplicación, podrías extrapolar esto al tamaño total de tu mercado —que podría ser, digamos, de 10 000 000 usuarios— y así entender cómo reaccionaría todo el mercado a la propuesta de valor de tu producto. Esta operación debería

29

ayudarte a acotar tus números respecto al tamaño del mercado y a entender mejor cómo debes proceder para generar ingresos en el futuro. Eso sí, utiliza las pruebas de humo con precaución, porque lo último que quieres es que los usuarios piensen que tu producto no está cumpliendo con lo prometido o que tiene fallos. Sé claro con tus usuarios cuando lleguen al final de la prueba de humo y explícales que todavía estás construyendo el producto o la feature que estabas probando. No intentes disfrazar estas pruebas como fallos técnicos, ya que esto les dará una mala impresión a quienes podrían haber sido tus futuros usuarios. Otro tipo de pruebas de humo intentan probar el valor cualitativo que el futuro producto o feature ofrecerá al usuario. Estas pruebas suelen utilizarse para fingir o simular una feature particularmente complicada y difícil de desarrollar y ver si merece la pena seguir trabajando en ella. Por ejemplo, el fundador de Zappos, el gigante vendedor de calzado en Internet (y que más tarde compraría Amazon), simuló una tienda de zapatos multimarca en línea, personándose en las tiendas clásicas para comprar los zapatos y enviárselos a sus clientes. Esto le permitió demostrar a sus inversores que los estadounidenses estaban preparados para empezar a comprar zapatos en línea. Este enfoque requiere más trabajo que la prueba de humo descrita más arriba, porque hay que construir parte del producto (en este caso, la tienda en línea), pero te puede permitir ofrecer una experiencia de producto casi final sin tener que construir las partes más complejas de tu producto o negocio. Las pruebas de humo son una gran forma de obtener información sobre la viabilidad de tu producto en el mercado escogido, pero recuerda que nunca pueden reemplazar a las fases de concepción y diseño de producto. La prueba de humo es un método que debería permitiros a ti y a tu equipo dar forma a una idea definitiva, pero no debería utilizarse para ampliar la fase de concepción y divergencia que comentamos en el segundo mandamiento.

30

31

Construye tu producto

Cuarto mandamiento:

CONSTRUYE TU HOJA DE RUTA Tendría que haber cogido la autovía...

Ahora que ya te tienes clara tu visión de producto, te guiaremos a través del proceso de construir un gran producto digital, paso a paso.

¿Qué es una hoja de ruta? Una hoja de ruta representa el camino que tú y tu equipo debéis seguir para llevar tu producto desde el estado en que se encuentra hasta tu visión de producto. Está compuesta por una lista de hitos de producto priorizados y asociados a fechas de lanzamiento (que pueden ser más o menos precisas; lo abordaremos más adelante). Tanto si estás comenzando con un nuevo producto como si estás trabajando en el enésimo lanzamiento, necesitas una hoja de ruta para planificar el desarrollo continuo de tu producto y dividir tu visión de producto en lanzamientos alcanzables. Ten en cuenta que la hoja de ruta es un documento operacional que debería contener información como la complejidad de cada lanzamiento o hito de producto y el tiempo que estimas que te llevará construirlo. También debería incluir información sobre posibles riesgos y dependencias que puedas tener (tanto de

32

33

otras partes de tu empresa como de factores externos). Una hoja de ruta no es lo

No te preocupes si tienes que añadir una fila más para identificar riesgos o de-

mismo que una lista de features deseadas; se trata más bien de una ruta infor-

pendencias; estas no están incluidas en la versión de hoja de ruta de Roman Pi-

mativa que puedes seguir para llevar tu producto hasta el lugar donde quieres

chler. Además, a parte de añadir las métricas claves que quieres seguir de cerca,

que esté.

también puedes añadir a la fila de métricas los valores o umbrales que estás tratando de alcanzar con cada lanzamiento.

Te recomendamos que para una hoja de ruta de alto nivel utilices el formato «orientado a objetivos», creado por Roman Pichler y muy popular. Tienes que cubrir los siguientes campos para cada lanzamiento: Las fechas de entrega (expresadas con fechas exactas, trimestres o como lo prefieras). El objetivo o tema de cada lanzamiento.

¿Cómo elaboro una hoja de ruta? Hay muchas formas de crear una hoja de ruta. En esta sección vamos a explicar dos métodos muy conocidos: el mapa de historias y el mapa de impacto. En su versión inicial, el mapa de historias de Jeff Patton era un simple método

Las features principales que se incluirán en ese lanzamiento. Las métricas a las que prestar atención para medir el éxito del lanzamiento.

para organizar features. En un mapa de historias, las partes principales del recorrido del usuario se colocan horizontalmente y en orden cronológico. En el eje vertical, el Product Manager divide cada una de estas partes en features individuales que permitirán que el usuario alcance su objetivo. Por lo general, se colocan de mayor a menor prioridad, es decir de arriba a abajo.

HOJA DE RUTA ORIENTADA A OBJETIVOS Fecha

Nombre de lanzamiento Objetivo

2/04/19

Junio de 2019

Q3 de 2019

Q4 de 2019

S1 de 2020

El mapa de impacto es un método creado y popularizado por Gojko Adzic. De lo que se trata es de asignar objetivos de negocio y organizativos de alto nivel a un conjunto de features listas para incorporar en la hoja de ruta que dirigirá el desarrollo del producto. Ambos métodos te ayudarán a comenzar una hoja de ruta, y combinándolos deberías poder construir los productos adecuados, y construirlos bien (¡que no se te olvide nuestro mantra!).

Mapa de impacto Features

El objetivo principal de un mapa de impacto es ayudarte a traducir tus objetivos organizativos en features. Si tu objetivo es hacerte con el 50  % de tu mercado

Métricas

34

durante el primer año, una de las features correspondientes podría ser construir un sistema de recomendaciones dentro de tu producto.

35

Tus objetivos: ¿por qué quieres construir o mejorar tu producto? Por lo general, deberás contar con una lista de KPI (indicadores clave de rendi-

MAPA DE IMPACTO

miento) definidos en tu Lean Canvas. Para definir tus objetivos, asigna un valor

1

fijo que quieras alcanzar a cada KPI que hayas decidido medir. La idea es estable-

Caza de gangas

cer objetivos medibles que te permitan evaluar con facilidad el éxito de tu pro-

Comprador cauto

Canvas. Los participantes: ¿quién va a influir en estos objetivos? ¿Quién es tu audiencia?

Seguimiento de comunicaciones de la empresa

4 Ventas privadas

Cupones

5 Recomendaciones

Un mapa de impacto te ayudará a identificar dos tipos de participantes: aquellos

4 Reserva de nuevos productos

que tendrán un efecto indirecto en tus objetivos (como anunciantes y proveedores) y tus usuarios finales. Tu impacto: ¿cómo quieres cambiar el comportamiento de tus participantes para poder alcanzar tu objetivo? Este es uno de los pasos más complicados, porque

3 Rebajas 2 Packs de productos

ducto. Un ejemplo sería alcanzar 100 000 usuarios activos mensuales, lo que se basará en un KPI de usuarios activos mensuales, como se seleccionó en el Lean

Promociones

Acceso prioritario a nuevos productos

Seguidor fiel

1

Sección de novedades

2 Lista de correo Conversaciones con representantes de la marca

Generar más de 2000 ventas al día

3 Venta cruzada

no solamente necesitas tener una idea muy clara del uso actual de tu producto, sino que también tienes que imaginar cómo te gustaría cambiar tu producto para influir en el comportamiento de tus usuarios y alcanzar tu objetivo.

1

Publicación de anuncios

Anunciantes

4 Búsqueda de acuerdos de publicidad cruzada

Las features: ¿qué necesitas hacer o construir para cambiar el comportamiento de tus usuarios? Aquí es donde definirás las features. Las features tienen que describirse según el recorrido del usuario, así que no hace falta entrar en porme-

Equipo interno

Descuentos para amigos

2 Códigos promocionales

nores sobre cómo tienen que diseñarse. A continuación encontrarás un ejemplo de mapa de impacto para una web de comercio electrónico que está pensando en desarrollar nuevas features para aumentar sus ventas totales a 2000 ventas diarias más.

36

37

A modo de ejemplo, continuemos y expliquemos la rama más alta del diagrama. Aquí, el comprador cauto contribuye al objetivo de 2000 ventas más al día

Arranca tu grupo de trabajo presentando todo el trabajo que has hecho hasta el

adoptando un nuevo comportamiento: cazar gangas. Este comportamiento surge

momento. Presenta tus personas, tu visión de producto y tus objetivos.

gracias a dos nuevas features: promociones y paquetes de productos. Esto demuestra la manera en la que enfoque del mapa de impacto puede ayudarnos a

Normalmente, nosotros pegamos pósits en una pared o pizarra para visualizar

visualizar cómo los objetivos se relacionan con los participantes y las features.

y construir el mapa de historias. Empieza colocando tus personas en la parte de

Ten en cuenta que este ejemplo se centra en un solo objetivo, y que es posible

arriba del espacio que hayas dispuesto para tu mapa de historias. Si retomamos

que necesitemos varios mapas de impacto para abarcar todo lo que supone tu

el ejemplo del comercio electrónico, colocaríamos los tres personas que identi-

producto.

ficamos en la parte de arriba: nuestro comprador cauto, nuestro seguidor fiel de la marca y nuestro empleado (dejemos a un lado por ahora a los anunciantes).

Los mapas de impacto no son un paso necesario para todos los productos y

Cada uno de estos personas utiliza el sitio web de comercio electrónico de forma

empresas. Puede utilizarse para la totalidad de tu producto, una parte concreta

diferente y sigue un recorrido diferente. El primer paso para construir tu mapa

de él o incluso para nada si crees que tu empresa es lo suficientemente madura

de historias es pensar mucho en el recorrido del usuario de cada perfil, y colocar

como para empezar a asignar features al recorrido del usuario directamente. Sin

estos recorridos debajo de cada perfil.

embargo, este ejercicio puede ofrecer una visión muy útil para los equipos que están acostumbrados a trabajar con objetivos de negocio y tienen dificultades

Después tienes que añadir features. Cada paso del recorrido del usuario necesi-

para visualizar cómo estos se pueden traducir en features y qué pasos interme-

tará una lista de features para existir. Llegados a este punto del mapa de histo-

dios hace falta dar.

rias, hay que intentar ser receptivo y creativo. Ya habrá tiempo más adelante para priorizar o eliminar features que no consideres que son críticas para la misión, o

Mapa de historias El mapa de historias es una visualización muy importante de la hoja de ruta de tu producto, que actualizarás y a la que acudirás frecuentemente durante la construcción de tu producto. Puede que sea una herramienta importante para el Product Manager, pero siempre aconsejamos crear primero el mapa de historias en equipo. Normalmente, recomendamos organizar un grupo de trabajo de entre dos horas y medio día de duración. Es buena idea que para este grupo de trabajo invites a colegas de los equipos técnicos, de marketing, diseño y negocios. En primer lugar, esto te permitirá entender los retos a los que te enfrentarás desde muchas perspectivas diferentes.

que puedan ser directamente inútiles. Una vez que hayas dispuesto tus personas, recorridos de usuario y todas las features necesarias para habilitar estos recorridos, necesitas priorizar tus features en lanzamientos. Un lanzamiento debería ser un grupo coherente de features que habiliten un recorrido del usuario en particular o una experiencia de principio a fin. Por ejemplo, no tiene sentido incluir la página de configuración del usuario en tu primer lanzamiento si la feature de registro de usuarios está programada para el segundo lanzamiento. Cada uno de estos lanzamientos deberá corresponderse con un objetivo específico de usuario; en el siguiente ejemplo, el objetivo es querer que se compren bienes durante eventos promocionales y rebajas (Lanzamiento 1).

También tiene la ventaja de involucrar a compañeros de toda la empresa, lo que significa que siempre podrás contar con un miembro del equipo especializado para ayudarte con cualquier reto que te encuentres a lo largo del camino.

38

39

Crea y mantén tu hoja de ruta

Aquí tenemos un ejemplo de un posible mapa de historias para el caso del sitio web de comercio electrónico utilizado antes:

Ahora que has completado tus mapas de historias e impacto, podemos utilizarlos para rellenar tu hoja de ruta orientada a objetivos, que se convertirá en tu refe-

MAPA DE HISTORIAS

rencia principal a lo largo de la vida de tu producto. Cada lanzamiento debería corresponderse con uno o varios de los lanzamientos planeados en tu mapa de historias. Los contenidos de los primeros lanzamientos seguramente estén muy Amantes de la marca

Cazagangas Publicidad

Catálogo de productos

Complemento lista de correo

Marca promocional

Mantener Enviar código promociones promocional actualizadas Newsletter R1 promocional

Promociones push

40

Carrito Código promocional

riores contengan menos información. Es útil tener por lo menos un objetivo en mente, pero no importa tanto tener una lista definitiva de features, ya que estas seguramente evolucionarán a medida que se sucedan los primeros lanzamien-

HOJA DE RUTA ORIENTADA A OBJETIVOS Promoción de productos de rebajas

Newsletter de Promoción de novedades productos de rebajas

Fecha

2/04/19

junio de 2019

Q3 de 2019

Q4 de 2019

S1 de 2020

Lanzamiento 1

Promoción de packs de productos

Invitaciones a rebajas exclusivas

Recomendación de packs de productos

Página de productos exclusivos

Recomendación de productos relacionados

Recomendaciones

Nombre de lanzamiento

Acuerdos de publicidad cruzada Invitación pre- Página de prelanzamiento lanzamiento

creación de codigó para próxima compra

R5

Conexión

tada a objetivos:

Acceso a recomendaciones personalizadas R3

Querer volver al sitio

Catálogo

claros para ti; sin embargo, es perfectamente normal que lanzamientos poste-

tos. De nuevo siguiendo el mismo ejemplo, esta sería nuestra hoja de ruta orien-

R2

Trato especial y ofertas exclusivas R4

Publicidad

Código promocional

Página de novedades en rebajas

Conocer ofertas y productos nuevos

Carrito

Empleados

Objetivo Acceso de empleado

Generador de códigos promocionales

features

Estar al día de las promociones

Conocer las rebajas y nuevos productos

Tener acceso a recomendaciones personalizadas

Trato especial y ofertas exclusivas

Querer volver a la web

• Códigos promocionales • Etiquetar los productos que están rebajados

• Rebajas • Página de novedades

• Packs de productos • Venta cruzada

• Ventas privadas • Invitaciones prelanzamiento • Códigos promocionales para empleados

• Recomendaciones • Reserva de productos • Códigos promocionales de «próxima compra»

• Cantidad de códigos promocionales canjeados • Nuevas cuentas creadas • Número de ventas

• Consulta de páginas nuevas • Nuevas cuentas creadas • Número de ventas

• Cantidad de ventas de paquetes de productos • Cantidad de ventas cruzadas • Número de ventas

• Cantidad de participantes en ventas privadas • Ingresos generados de las ventas privadas • Cantidad de registros para el prelanzamiento • Códigos promocionales canjeados • Número de ventas

• Nuevas cuentas creadas • Códigos promocionales canjeados • Cantidad de recomendaciones • Cantidad de reservas de productos • Número de ventas

Reserva de productos

Métricas

41

Asignar fechas a los lanzamientos puede ser complicado, tanto como para dedicarle un mandamiento entero a este tema. Sin embargo, con el enfoque del desarrollo ágil, el Product Manager o Product Owner debe comprender bien dos cosas antes de estimar cualquier fecha de lanzamiento. En primer lugar, la velocidad del equipo: ¿cuántas historias de usuario (atento, hablaremos de las historias de usuario en el siguiente mandamiento) se ponen en marcha cada semana? Y, en caso de trabajar con Scrum, ¿cuántos puntos de historia? Con un equipo estable, deberías poder predecir la velocidad del equipo tras dos o tres sprints. En segundo lugar, el Product Manager también necesita tener una estimación aproximada del backlog del producto. Para ello, nosotros normalmente hacemos una estimación mágica; un grupo de trabajo que permite que tu equipo de desarrollo estime muchas historias en poco tiempo. Una vez que tengas una idea de estos dos parámetros, podrás estimar cuánto tiempo llevará cada lanzamiento. Como se ve en el ejemplo de arriba, cuanto más tarde se produce un lanzamiento, menos precisión se utiliza en la estimación de la fecha de lanzamiento, porque el backlog no es tan detallado y podrías haber sobreestimado o subestimado algunas features. Al igual que tu futuro producto, tu hoja de ruta requiere mantenimiento. Si has ajustado tus objetivos o, simplemente, has aprendido más sobre tu mercado gracias a las métricas y KPI que has puesto en marcha, necesitarás ajustar tu hoja de ruta. Asegúrate de comprobar y actualizar con regularidad tus mapas de historias e impacto, ya que te ayudarán a guiar la evolución de tu hoja de ruta y asegurarte así de trabajar siempre de la mejor forma para tu producto y tus usuarios.

42

43

Quinto mandamiento:

ESCRIBE BUENAS HISTORIAS DE USUARIO

rio. Como Product Owner, tienes que trabajar para asegurarte de que tus historias encajan con tu equipo, y no al revés. Da igual lo que hayas leído sobre formatos y buenas prácticas para escribir historias de usuario; tienes que escuchar a tu equipo. Dicho esto, aquí tenemos un formato de historia de usuario muy extendido para que puedas empezar, inspirarte e iterar sobre él.

Quizá habría sido mejor idea utilizar el diseño que estaba en JIRA...

Una historia de usuario debería incluir: Un título: «Pago de cliente con tarjeta VISA» Una descripción narrativa utilizando las estructuras «Como...», «Necesito...», «Para...». Por ejemplo: «Como cliente con tarjeta VISA, necesito introducir los datos de mi tarjeta para pagar los elementos de mi carrito de la compra» Utilizar este enfoque tiene la ventaja de asegurarte que estás escribiendo las historias de usuario con tus usuarios en mente, comenzando por lo que están intentando hacer y por qué. Una lista de criterios de aceptación. Estos te ayudarán a mencionar todos los detalles que no se mencionan en la descripción de más arriba y a expresar todas las cosas que esperas que se desarrollen alrededor del núcleo de lo que estás describiendo en tu historia de usuario. Por ejemplo, un criterio de aceptación para este caso sería que el formato de la tarjeta VISA tiene que verificarse

Formato de una historia de usuario La forma correcta de escribir historias de usuario es un tema muy debatido. A lo largo de este mandamiento intentaremos darte algunos consejos e indicaciones para que arranques de la manera que creemos que es la más adecuada. Sin embargo, no te olvides de que todo lo que encontrarás aquí es una recomendación y que la forma correcta de escribir historias de usuario siempre será la que mejor os funcione a ti y a tu equipo. Igual que con muchos otros conceptos ágiles, el equipo de desarrollo tiene la última palabra respecto a cómo de clara y preparada está una historia de usua-

44

cuando el cliente la escribe (hablaremos de esto después). En algunos equipos debería ser suficiente una historia de usuario muy esquemática para que empiecen a desarrollar la feature correcta. En otros, las historias de usuario deberán parecerse más a una mini especificación. Por supuesto, el nivel de detalle que decidas incluir en cada historia puede variar según su complejidad. Normalmente, nosotros observamos que cuanto más próximo está el Product Owner a su equipo, más cortas y concisas son las historias de usuario. Sin embargo, por muy buena relación que puedas tener con tu equipo de desarrollo, cada historia de usuario debería superar cada paso del modelo INVEST. Independiente: Una historia de usuario debe ser autosuficiente, es decir, que no debe depender de otras historias para no provocar problemas de prueba y plani-

45

ficación.

visual que te ayude a explicar y aclarar tus historias de usuario. No olvides que una historia es una narrativa pensada para fomentar el debate y asegurarse de

Negociable: Una historia debería estar siempre abierta a discusión e iteración.

que todos los integrantes de tu equipo están de acuerdo y entienden las necesi-

Tus equipos de desarrollo y pruebas tienen que poder opinar.

dades y motivos de los esfuerzos de desarrollo.

Valiosa: Todas las historias deben aportar un valor tangible a tus usuarios, por

Retomando la idea inicial: no te olvides de que el formato correcto de una historia

eso estas se expresan con una descripción narrativa que gira alrededor de ellos.

de usuario es aquel que funciona para tu equipo. Evita seguir o adoptar religiosamente y sin adaptar una metodología que hayas leído en un artículo. Pregúntale

Estimable: Una historia de usuario tiene que ser lo suficientemente clara y pre-

a menudo a tu equipo de desarrollo si está contento con las historias en las que

cisa para que el equipo de desarrollo pueda estimarla.

están trabajando y cómo podríais mejorarlas. Te animamos a hablar de esto con tu equipo según vuestras retrospectivas habituales.

Pequeña (Small): Intenta siempre escribir historias de usuario que describan una tarea de desarrollo factible en un periodo de tiempo relativamente corto y que no implique demasiada complejidad en una sola tanda. Esto evitará una visión de túnel o limitada y te asegurará ser capaz de entregar una nueva versión de tu producto con frecuencia.

Criterios de aceptación: el grupo de trabajo de «los tres amigos»

Probable (Testable): Una historia de usuario describe una narrativa orientada a

Los criterios de aceptación son un grupo de criterios que te permitirán validar una

ciertos objetivos, lo que significa que deberías ser capaz de probar todas las his-

historia de usuario una vez que se ha terminado su desarrollo y se han cumplido

torias una vez que se hayan completado.

esos criterios; guiarán a los equipos de desarrollo y pruebas durante su trabajo, así que es importante que todo el mundo pueda opinar sobre ellos y compren-

Por supuesto, el modelo INVEST es un conjunto de directrices que no siempre vas

derlos a la perfección. El grupo de trabajo de «los tres amigos» intenta fomentar

a poder seguir. Por ejemplo, de vez en cuando habrá interdependencia entre las

precisamente eso.

historias de usuario, por lo que tendrás que priorizarlas con cuidado. Este modelo es una herramienta para ayudar a los Product Owners a mejorar sus historias de

Antes de comenzar con el grupo de trabajo, el Product Owner deberá haber ter-

usuario intentando seguir un conjunto de directrices.

minado los criterios de aceptación de las historias para compartirlos y discutirlos con el resto de participantes. Los desarrolladores y testers tendrán que haberlos

Ten siempre en cuenta que el Product Owner no debe asumir nunca que una his-

leído antes de llegar al grupo de trabajo, donde aportarán una lista de preguntas

toria de usuario contiene la solución correcta para los problemas de sus usua-

y sugerencias.

rios. Cada historia debería escribirse tras recoger toda la información necesaria de los equipos de negocio, los propios usuarios o cualquiera que pueda aportar

Tras un debate inicial durante el cual el Product Owner responderá a las dife-

valor.

rentes preguntas sobre la tarea de desarrollo descrita en las historias de usuario, deberéis ir elaborando un borrador entre todos con una lista de lo que debe pro-

Y no dudes en recurrir a maquetas, diagramas, flujos y cualquier otra herramienta

46

barse en cada historia. El grupo de trabajo no consiste en confeccionar un plan de

47

pruebas general, sino identificar las situaciones principales que hay que probar y

Estos criterios de aceptación están muy bien, pero el grupo de trabajo también

cómo hacerlo: con pruebas manuales, unitarias...

tiene la ventaja de garantizar que todo el equipo está en sintonía con el trabajo que hay que hacer en cada historia de usuario. Ahora que todo el equipo com-

Lo que debería surgir a raíz de «los tres amigos»:

parte la misma visión de la historia, debería ser más sencillo desarrollarla con menos idas y venidas.

Lo que se creará es una lista de pruebas de aceptación, que les resultarán familiares a aquellos que trabajen en un entorno de desarrollo orientado a compor-

Ojo con «los tres amigos»

tamiento (BDD). Esto suele formalizarlo el equipo de pruebas o el Product Owner una vez finalizado el grupo de trabajo. Pueden escribirse de la siguiente manera:

Como todo lo que proponemos, estos grupos de trabajo solo deben utilizarse cuando tengan sentido. No siempre es necesario tener a tres personas definiendo

DADO (un contexto)

los criterios de aceptación para una feature básica, y mucho menos para arreglar

CUANDO (el usuario hace algo)

un error (¡el equipo ya sabe dónde está el fallo!). Sin embargo, te recomendamos

ENTONCES (se observa el resultado de las acciones dadas)

encarecidamente utilizar este grupo de trabajo, especialmente al comenzar un nuevo proyecto o cuando se incorpora un nuevo miembro al equipo, para asegu-

Una vez que tus criterios de aceptación estén escritos de esta forma, te reco-

rarte de que todo el mundo comparte la misma idea de cómo debe escribirse una

mendamos que le pidas a todo el mundo que los vuelva a leer para confirmar

historia de usuario. Con suerte, esto hará que en el futuro haya menos problemas

que el equipo sigue estando de acuerdo. Esta sintaxis, llamada Gherkin, se utiliza

de compresión y podrás dedicar menos tiempo a reescribir historias o a explicár-

en muchas herramientas que permiten la prueba automática de features, como

selas a tu equipo.

JBehave y Cucumber.

No te olvides de que tu objetivo es construir un gran producto con la mayor eficiencia posible, y no pasarte el tiempo escribiendo documentación innecesaria.

Cuando utilices este tipo de criterios de aceptación tendrás que escribir criterios concretos con datos reales y no con frases genéricas. Si volvemos a la historia de usuario del pago con tarjeta VISA, los criterios de aceptación quedarían así: DADO un usuario con un número de tarjeta VISA 4672 6677 8183 8471, válida hasta el 01/2020 y con criptograma 436, CUANDO el usuario introduce su número de tarjeta 4672 6677 8183 8471

Y la fecha de caducidad 01/2020



Y el criptograma 436

ENTONCES se acepta el pago

48

Y se redirige al usuario a la página de confirmación de pago

49

Sexto mandamiento:

PRIORIZA TU BACKLOG

Para priorizar correctamente, el Product Owner debe utilizar una gran cantidad de variables, métodos y herramientas. En las siguientes páginas repasaremos algunos de los métodos de priorización más utilizados y respetados: MoSCoW, Kano y el mapa de historias.

MoSCoW MoSCoW es un método de priorización a medio plazo. Consiste en ordenar tus historias de usuario en diferentes categorías: M - Debe tener (Must have): Lo que se describe en la historia de usuario hay que desarrollarlo obligatoriamente. S - Debería tener (Should have): La historia de usuario deberá desarrollarse si es posible. C - Podría tener (Could have): Podría desarrollarse, pero no es imprescindible para los usuarios o los equipos de negocio. W - No tendrá (Won’t have): No se incluirá a medio plazo, pero podría ser útil en una versión posterior. En el momento en que ya tienes una colección de historias de usuario en tu backlog, necesitas asignarles prioridad. Si trabajas con Scrum, tendrás que empezar a crear tus sprints y rellenarlos con historias de usuario. Por supuesto, solo será una aproximación, porque todavía no has estimado el valor de puntos de historia o medido cada una de ellas. Tu objetivo como Product Owner debería ser entregar en primer lugar las historias de mayor valor a tus usuarios o negocio. Como ya comentamos en el quinto mandamiento, cada historia incluye el valor para el usuario, pero puede ser difícil darle prioridad a una historia en base únicamente a esa idea, a veces poco clara y otras demasiado obvia.

50

Organizar un grupo de trabajo MoSCoW con partes interesadas de diferentes ámbitos puede ser una gran forma de empezar a priorizar tu backlog, pero este método conlleva ciertas limitaciones. Por ejemplo, los participantes suelen pensar que «todo es importante», así que todas las historias suelen acabar en los grupos «debe tener» o «debería tener». Esto pasa a menudo porque todo el mundo tiene un punto de vista diferente y cada historia es importante para alguien concreto. También sucede en empresas en las cuales suelen darse expectativas poco realistas o cuando los Product Managers o Project Managers no saben decir NO. En estas culturas, los participantes están convencidos de que cualquier cosa que se coloque en «podría tener» o «no tendrá» puede acabar también en la papelera. El Product Owner tiene la responsabilidad de promover una mentalidad positiva

51

No me gusta

facción e insatisfacción de los usuarios con una feature. Algunas features pue-

Puedo aceptarlo

Este método lo creó Noriaki Kano en 1984, inspirado por la asimetría de la satis-

PREGUNTAS HECHAS CON UNA PERSPECTIVA DISFUNCIONAL

Neutral

Kano

O = Obligatorio/Esencial L = Lineal E = Excitante C = Contradictorio Q = Cuestionable I = Indiferente

Esperable

titividad entre departamentos o personas respecto a lo que debería construirse.

Me gusta

y enfocada a la creación de valor para el usuario y el negocio, y evitar la compe-

Me gusta

Q

E

E

E

L

Esperable

C

I

I

I

O

Neutral

C

I

I

I

O

Puedo aceptarlo

C

I

I

I

O

No me gusta

C

C

C

C

Q

den ofrecer poca satisfacción cuando están presentes, pero su ausencia puede PREGUNTAS HECHAS CON UNA PERSPECTIVA FUNCIONAL

provocar a su vez una gran insatisfacción. Si tu backlog es bastante maduro y completo, el método Kano te permitirá priorizar las features principales que quieres incluir en tu producto. Este método también es colaborativo y debería llevarse a cabo en un grupo de trabajo de cuatro pasos con varios participantes: Paso 1: Identifica las features que necesitas priorizar. Ten en cuenta que una feature no

Paso 3:

tiene por qué equivaler a una historia de usuario, sino a la suma de varias; esto

Compara las discrepancias entre las perspectivas funcionales y disfuncionales y

se definirá según tu producto y lo específicas que sean tus historias de usuario.

clasifica las features en estos tipos: Funcionalidades esenciales u obligatorias (O): esas son las features princi-

Paso 2:

pales de tu producto que no se pueden excluir.

Plantea estas preguntas a cada miembro del grupo de trabajo:

Funcionalidades lineales (L): Llamadas así porque, añadiendo más funcionali-

El producto incluye esta feature. ¿Qué opinas? (perspectiva funcional)

dades lineales, se incrementará en valor de tu producto de forma proporcional.

El producto no incluye esta feature. ¿Qué opinas? (perspectiva disfuncional)

Funcionalidades excitantes (E): No son esenciales, pero pueden ser un gran añadido y complacer a los usuarios.

Los participantes escogerán entre las siguientes respuestas: Me gusta

Funcionalidades contradictorias (C): Para los casos en los que exista una gran diferencia de opiniones entre los participantes del grupo de trabajo. Podrían

Esperable

requerir más investigación.

Neutral

Cuestionables (Q): Tendrías que intentar averiguar por qué estas features gus-

Puedo aceptarlo

tan tanto o tan poco. Con suerte, esto no debería de pasar muy a menudo.

No me gusta

Indiferentes (I): La gente suele ser indiferente a esas features y, lógicamente, no deberían ser una prioridad. Con suerte podrás iterar sobre ellas para meterlas en las categorías O, E o L.

52

53

Paso 4: Visualiza tus resultados en un diagrama

Otra cosa muy útil de los mapas de historias es la habilidad para observar interdependencias entre features de alto nivel y ver la priorización desde la persMODELO DE KANO

Fuerte

pectiva del recorrido del usuario, así como para ofrecerte una visión clara de qué features podrían ser menos prioritarias o puramente técnicas. En conclusión, la clave para priorizar tu backlog adecuadamente es hacerlo colaborando con varias partes interesadas y entendiendo el valor de tu producto, así

Excitante e increíble

como sus fortalezas y debilidades, desde varias perspectivas y utilizando una serie de criterios diferentes. Esto te permitirá entender el valor de una feature desde un punto de vista más global, permitiendo que decidas de forma efectiva qué features deberían desarrollarse primero y cuáles pueden esperar a más ade-

Rendimiento lineal

lante en el ciclo de vida de tu producto.

Esencial

Débil Ausencia

Presencia de características

Presencia

Este método nos parece particularmente interesante porque se basa en la percepción que los usuarios tienen del producto y suele revelar expectativas sorprendentes de algunas de las partes interesadas.

Mapa de historias En el cuarto mandamiento ya hablamos en profundidad de los mapas de historias. El aspecto visual de este enfoque es muy bueno para ayudarte a construir tu backlog, y también para ayudarte a priorizarlo. Por ejemplo, os ofrece a ti y a tu equipo una forma muy buena de visualizar la prioridad de las features principales de alto nivel de tu producto (como ya comentamos en el cuarto mandamiento).

54

55

Séptimo mandamiento:

bir código, incrementando así el capital invertido en un producto de software; como resultado, el equipo generará nuevos errores y requisitos de mantenimien-

NO TE OLVIDES DE LA DEUDA TÉCNICA

to. La deuda técnica es todo el código que no se utiliza, que está roto, que es difícil de mantener o ampliar o que necesita actualizar sus librerías, frameworks o lenguajes.

La deuda técnica es inevitable... Por eso necesitamos identificarla, categorizarla y explicarla

De todos modos, ¿A quién le importan las deudas?

Una herramienta muy interesante para evaluar tu deuda técnica es el «cuadrante de deuda técnica» (Technical Debt Quadrant), creado por Martin Fowler. Este cuadrante ayuda a que el Product Owner pueda organizar la deuda técnica en cuatro categorías diferenciadas: CUADRANTE DE DEUDA TÉCNICA

¿Pero qué es la deuda técnica? La deuda técnica es una metáfora acuñada por primera vez por Ward Cunningham, quien tomó prestado el concepto de deuda del sector financiero para aplicarlo a la industria de las TI.

VOLUNTARIA

EXCESIVA Y ARRIESGADA La deuda técnica suelen generarla los equipos que están haciendo un desarrollo «rápido y sucio» de forma consciente porque no tienen el tiempo necesario para escribir, probar y mantener su código adecuadamente. Ejemplo: Un equipo que se apresura a incorporar features en una web de comercio electrónico antes de una importante campaña navideña.

MODERADA Y MENOS ARRIESGADA Deuda creada de forma intencionada para poder llegar a una fecha de lanzamiento. Los intereses (fallos y mantenimiento) pueden ser tan pequeños que nunca se necesite corregirlos. Ejemplo: Una pieza básica de código que normalmente no requiere cambios.

deuda se utilizan para reembolsar parte del capital prestado y también el interés correspondiente. Si estos reembolsos no se hacen periódicamente, la suma de los pagos de intereses aumentará. Ward Cunningham aplica esta lógica a los proyectos de software y dibuja una comparación entre el sector financiero y el de TI en el que el código representa el capital y los errores representan los intereses. Cuando los desarrolladores construyen una nueva feature, lo que hacen es escri-

56

INVOLUNTARIA

En el sector financiero, los pagos mensuales que uno hace para devolver una Deuda creada generalmente por equipos que no son conscientes de los riesgos potenciales y buenas prácticas cuando conciben y construyen productos de software. Ejemplo: Una empresa de reciente creación que se apresura a validar una idea o ser la primera en entrar en un mercado, sin preocuparse por la calidad del código producido y los problemas que puedan surgir a lo largo del ciclo de vida del producto.

Deuda técnica inevitable que surge a pesar de una buena arquitectura y buenas decisiones de diseño de software durante el desarrollo del producto. Normalmente, tienen que pasar meses después de una decisión para que el equipo sea capaz de entender qué decisiones deberían haber tomado desde el principio.

57

Por qué debes tener en cuenta la deuda técnica

Un producto que no necesita mantenimiento, que es fácil de mejorar y que es

Puede que parezca que esto se sale un poco de las responsabilidades del Product

ducir la calidad para entregar más rápido, pero asegúrate de hacer siempre lo

Owner, pero nada más lejos. Si quieres construir un gran producto y hacerlo bien,

posible para que producto esté bien construido, haciéndolo fiable y robusto.

sin fallar en ninguna fecha de entrega y acabar ralentizando todo el proceso por el mantenimiento y la reparación de errores, necesitas aprender a dominar la deuda de tu producto. Cuando lo explicamos así, lo que esperamos es que sientas que está en tu mano construir un producto con un código de calidad como base. Como Product Owner, necesitas ser el primero en dar ejemplo y hacer las cosas bien, sin atajos y siempre un paso por delante de la deuda técnica. La deuda técnica puede influir en tres aspectos de tu producto: Mantenimiento: ya sea mantenimiento correctivo (corrigiendo errores y problemas en el software) o mantenimiento preventivo (mejorando o adaptando tu software para asegurar su compatibilidad con tu stack tecnológico), tú y tu equipo debéis tener siempre presente que la aplicación tiene que mantenerse periódicamente. Cuantas más necesidades de mantenimiento tenga tu aplicación, más tiempo por sprint habrá que dedicarle a solucionar errores y parchear problemas, lo que significa que construirás tu aplicación más despacio, te costará más e incluirá menos features. Facilidad de evolución: la idea de trasfondo de la filosofía ágil y el papel del Product Owner es ver el desarrollo del producto como una sucesión de iteraciones. La facilidad de evolución es la facilidad (¡o falta de ella!) con la que puedes iterar

100  % fiable es una quimera. Como Product Owner, tu trabajo es encontrar un equilibrio entre maximizar la facilidad de evolución y la fiabilidad manteniendo los requisitos de mantenimiento al mínimo. Siempre tendrás la tentación de re-

Trabaja en reducir la deuda técnica Tras estos últimos párrafos, esperamos que os estéis preguntando «¿Cómo puedo minimizar mi deuda técnica sin dejar de entregar las features a tiempo?». ¿Cómo puedo aprender a vivir con la deuda técnica manteniéndola al mínimo?

Para controlar la deuda técnica necesitas ser capaz de medirla Antes de intentar reducir tu deuda técnica, necesitas medirla y entenderla. Como Product Owner, mostrar interés en esto podría ayudar a motivar al resto de tu equipo para que se entregue a la tarea con la atención necesaria. Comienza por trabajar con tu equipo para introducir algunas herramientas de software que te ayudarán a medir la deuda. SonarQube es una gran herramienta para esto, y ofrece algunos complementos que calcularán tu deuda técnica y propondrán un indicador de porcentajes para que puedas controlarla. Incluso si estos valores son cuestionables y no pueden aplicarse a cada línea de código, siguen siendo un gran punto de partida y te permitirán medir el impacto de las acciones que tu equipo lleva a cabo. DEUDA TÉCNICA

sobre tu producto. Una aplicación con mucha deuda técnica será más complicada de iterar que otra con poca deuda. Fiabilidad: la deuda técnica puede tener un gran impacto en la fiabilidad de tu software. Todos sabemos que el usuario se frustra si un software no funciona como debe, y podría no volver a utilizarlo si tienen una mala experiencia.

DEUDA TÉCNICA

8,4 %

Proporción

Duplicaciones

Complejidad

$54,131 108 días nombre

Coste de reinversión

Esfuerzo de reinversión

58

Violaciones

No hay información disponible sobre la cobertura

Desglose por eje Comentarios

59

Prioriza tu deuda: Interrogante: Debes tratar de minimizar el incremento de deuda técnica en estos MATRIZ BCG

productos, lo que significa que deberás hacer mucho mantenimiento preventivo. Estas aplicaciones podrían llegar a ser algún día tus estrellas, y no te gustaría

Alto

Débil

Estrella

Interrogante

Encuentra expertos artesanos Hoy en día no hay muchos desarrolladores por ahí sueltos, pero hay un tipo que tienen incluso más demanda que el resto: los artesanos del software. La artesanía del software es un movimiento cultural y profesional que hace hincapié en

Vaca

Perro

Bajo

Crecimiento del mercado

descubrir que están cargadas de deuda cuando se convierten en una.

Alta

Baja

Cuotas de mercado

que los desarrolladores estén muy formados, tengan curiosidad y sean muy cuidadosos con la calidad del código que crean. Los artesanos siguen una regla muy importante, a la que Robert C. Martin le ha dado forma: «Deja el código mejor que como estaba». Eso significa que hay que llevar la mejora continua al nivel más específico: cada vez que un desarrollador toca una parte de código, tiene que dejarla mejor que como se la encontró inicial-

¿Te acuerdas de la matriz de producto de Boston Consulting Group? Seguro que

mente; los artesanos del software están constantemente incorporando pruebas

sí y, aunque esto no sea ninguna novedad en un libro sobre metodologías ágiles,

unitarias, eliminando errores y actualizando el código a medida que trabajan. ¡Un

es una gran herramienta para afrontar la deuda técnica.

gran remedio para combatir la deuda técnica!

Recordemos que el objetivo de esta matriz es ayudarte a categorizar tus produc-

Definición de «Terminado»

tos en una de las cuatro categorías. La forma en la que vayas a afrontar tu deuda técnica depende de en qué categoría de producto estés trabajando:

La definición de «Terminado» debería escribirse junto al Scrum master de tu equipo o al desarrollador principal. La definición de «Terminado» es la que te permitirá

Estrella: Estos productos suponen una parte importante de los ingresos de tu

a ti, como Product Owner, confirmar que la historia está realmente finiquitada y

empresa. Haz lo imposible para eliminar la deuda técnica de este producto.

que se han aplicado unas buenas prácticas de desarrollo, es decir, que el código debería ser legible además de incluir pruebas unitarias y funcionales. Una gran

Vaca: Trata de reducir la deuda técnica para asegurarte de que tu producto sigue

forma de asegurarte es animando a tu equipo de desarrollo a hacer revisiones de

siendo mantenible y fiable.

código antes de entregar una historia de usuario para pruebas y desarrollar features haciendo pair programming (programación en pareja) cuando sea posible.

Perro: No intentes reducir la deuda técnica de estos productos, porque, de todos modos, tampoco les estás prestando atención en otros sentidos.

60

61

La deuda técnica no puede esperar Aquí tienes una lista de cosas que puedes hacer para empezar con buen pie desde ahora mismo: Incluye una revisión de indicadores de calidad de código en cada retrospectiva; así, todo tu equipo sabrá dónde está la deuda. Basa tus estimaciones de puntos de historia en la cantidad de deuda implicada en el desarrollo de una nueva feature. Si esto se hace correctamente, el coste de la feature será mayor cuanto mayor sea la deuda implicada. Así, podrás llevar la cuenta de cuánta deuda técnica le cuesta a tu equipo cada entrega. Organiza «días de limpieza». Si tu equipo tiene problemas para gestionar la deuda técnica, dedícale días completos a esa única tarea. Anima a que la gente refactorice, pero no le dediques sprints completos. Refactorizar es la práctica de «ordenar» el código, mejorando su legibilidad y facilitando su mantenimiento e iteraciones. Tu equipo de desarrollo debería dedicarle tiempo a la refactorización, pero asegúrate de acotar esos esfuerzos, pues eso te ayudará a entender lo que se ha hecho y medir el progreso (igual que cuando escribes historias de usuario muy pequeñas).

62

Octavo mandamiento:

TODO ES UNA CUESTIÓN DE ACTITUD

de esto, un buen Product Owner necesita aprender a compartir información con todos estos equipos de forma efectiva y comprensible. Es inevitable tener que contestar a preguntas técnicas que formule el equipo de negocios, y viceversa. Un buen Product Owner puede prescindir de la jerga técnica y confusa y responder de forma clara y efectiva.

Expresa los valores de negocio y la misión de la empresa Como Product Manager, eres el portavoz de una gran parte de tu empresa frente a tu equipo de desarrollo. Tienes que ser capaz de expresar lo que te gustaría que construyesen, pero también el valor que eso representa para que el equipo de desarrollo entienda y se implique con el producto en el que están trabajando.

Es un poco friki

Por definición, el Product Owner es alguien que atesora los valores ágiles, entre los cuales destacan la colaboración y la transparencia. El Product Owner no es el «jefe» de su equipo de desarrollo, sino que es una parte más del equipo, igual que un desarrollador, tester o diseñador. Muchas organizaciones no están acostumbradas a este tipo de equipo, así que nos gustaría dedicarle un tiempo a explicar los que creemos que son algunos de los valores y features más importantes.

¿Qué hace a un buen Product Owner?

y cómo; incluso aunque no estés directamente implicado en el desarrollo de tu producto. Entender qué APIs están utilizando para entregar una feature o las cualidades del framework que están utilizando en el equipo de front-end son algunos ejemplos de lo que deberías querer aprender (de todos modos, te va a tocar hacerlo en algún momento). Al fin y al cabo, también formas parte del equipo encargado de comunicarle a las partes interesadas qué decisiones técnicas se han tomado y por qué. Además, un buen Product Owner debería ser independiente y autosuficiente a la

Habla muchas lenguas

hora de afrontar pequeñas tareas técnicas. Tu equipo de desarrollo no echará de

Lógicamente, no nos referimos al sentido literal, sino a que el Product Owner

por quinta vez o cambiar un número de teléfono de la base de datos de pruebas

ejerce de punto intermedio entre los equipos técnicos y de negocio, y necesita ser capaz de comunicarse de forma efectiva con todo el mundo. Hablar con tus clientes, directivos, equipos de ventas, colegas de marketing, los propietarios en la entrada y los desarrolladores en la cuarta planta... todo esto forma parte del día a día del Product Owner. Y si, ¡es mucho! Como resultado

64

Serlo te ayudará a entender lo que está haciendo tu equipo, además de por qué

menos enviarte la URL de preproducción cada semana, cambiar tu contraseña antes de una demostración.

Está preparado para todo Un buen Product Owner sabe que trabajar en software puede ser un viaje turbulento. Debe ser una persona con rapidez para pensar en alternativas, reorganizar

65

el backlog si fuese necesario y adaptarse a las circunstancias cambiantes para

ciendo. Escucharte cada mañana les ayudará a entender lo que está por venir en

garantizar que el equipo de desarrollo pueda trabajar en las mejores condiciones

el backlog, pero también les permitirá entender cómo es tu día a día y qué retos

posibles. Un buen Product Owner trabaja con su equipo para superar cualquier

afrontas.

obstáculo, y se ganará el respeto del equipo por ser un colega ágil y flexible.

Presentación de historias de usuario Es un miembro divertido del equipo Ya sea durante la sesión de planificación del sprint o revisando el backlog, es muy El desarrollo de software puede muchas veces complicarse. Mantener una acti-

importante que el Product Owner esté presente, ya que este es el momento en el

tud positiva puede ayudar mucho a que tu equipo se sienta como tal, lo que a

que los equipos suelen cuestionar tus historias de usuario, haciendo que muchas

cambio les hará trabajar mejor juntos. Y un poco de humor nunca hace daño

veces evolucionen. Es también un buen momento para escuchar las conversa-

cuando las cosas se complican. Además, asegúrate de darle el crédito corres-

ciones que mantienen los desarrolladores entre si, lo que te ayudará a entender

pondiente a tu equipo, no solo en el día a día sino también en momentos impor-

qué tipo de features les parecen complicadas y requieren conversaciones más

tantes, como demostraciones e hitos de producto. A fin de cuentas, son los que

extensas, y cuáles son fáciles de implementar.

lo han desarrollado.

Retrospectiva

Construye una buena relación con el equipo de desarrollo Cada persona desempeña un papel dentro del equipo. Es importante que como Product Owner tu papel se perciba de la misma forma que el de tus compañeros del equipo de desarrollo. El Product Owner no debería estar en un pedestal ni ser considerado un miembro especial del equipo. Necesitas demostrarle a tu equipo

Product Owner. Ten cuidado, esto sería una mala señal. Ningún equipo ágil y sano querría excluir a alguien de una retrospectiva, y esto incluye al Product Owner. Siendo tan parte del equipo como cualquier desarrollador, el Product Owner no solo debe estar presente para comentar cualquier problema que pueda existir, sino también para escuchar a los desarrolladores que quieran aportar algo respecto a cómo se está diseñando y construyendo el producto.

que eres uno de ellos.

Demostraciones

Y la mejor forma de empezar es jugando con las mismas reglas que tus com-

El Product Owner debe asistir a las demostraciones. En algunas ocasiones, el

pañeros. Participa en todos los eventos habituales, ya estéis trabajando con Kanban o Scrum. Tienes que estar disponible para las reuniones diarias, el planning poker, la planificación del sprint, demostraciones y retrospectivas; igual que los desarrolladores, testers y diseñadores.

La reunión diaria La reunión diaria es el mejor momento para que tu equipo sepa lo que estás ha-

66

Jamás se ha visto que un Scrum master trate de hacer una retrospectiva sin el

Product Owner será la persona que desarrolle la demostración, pero recuerda que el énfasis debería estar puesto en el equipo de desarrollo: son ellos los que están construyendo el producto y deberían de ser los que presentasen su trabajo y recibiesen felicitaciones por lo que han creado. Nada estropea más rápido a un equipo que ver a su Product Owner presentar una nueva versión del producto como si fuese fruto únicamente de su trabajo. Participando activamente en todos los eventos más importantes, el Pro-

67

duct Owner es capaz de seguir el día a día del equipo, asegurando que se está

No, eso no es lo que vamos a hacer después. No, esa feature no encaja en este

construyendo el producto correcto y contribuyendo a la mejora continua del equi-

lanzamiento, ni en el producto en general. No, no podemos terminar seis meses

po.

antes.

Igual que con muchos de los otros grupos de trabajo presentados en este libro,

Decir esto no es nada fácil. Algunas veces tendrás que defender posturas contro-

es importante recordar que los rituales diarios de Scrum y Kanban también se en-

vertidas y convencer a las partes interesadas y a los directivos para que acepten

riquecen con variedad de opiniones y perspectivas, así que siempre es buena idea

cosas que en principio no tenía intención siquiera de escuchar. Es uno de los

incorporar a miembros del equipo no técnicos en estos momentos importantes.

aspectos más importantes y por lo general, más difíciles de ser Product Owner.

Gestiona a las partes interesadas Ofrece visibilidad Parte de tu trabajo como Product Manager es asegurarte de que las partes interesadas en tu producto entienden lo que está sucediendo: ¿qué se está construyendo? ¿Por qué? ¿Qué efectos se espera que tenga? Todas estas son preguntas que escucharás a menudo. Existen muchas formas de comunicarse con esas partes interesadas y, según sea la cultura y tamaño de tu empresa, diferentes estrategias: desde una wiki bien documentada hasta un boletín semanal. Otra gran forma de comunicar el trabajo de tu equipo es con una buena gestión visual y mostrando una total transparencia con cualquier parte interesada que quiera saber cómo avanza el desarrollo del producto. La gestión visual es parte esencial de la vida diaria en Kanban, y hoy en día también vemos a muchos equipos Scrum adoptando este método de gestión. Esto os permitirá a ti y al equipo de desarrollo, así como a otras partes interesadas, saber con rapidez y claridad cómo está transcurriendo la vida del producto en cualquiera de sus etapas.

Aprende a decir no Como Product Manager, tendrás que lidiar con los desarrolladores. A veces, te dará la sensación de que estás protegiendo de los dueños empresariales y las partes interesadas. También debes proteger tu producto, y para eso hay que aprender a decir «no».

68

69

Haz crecer y mejora tu producto Ahora que la primera versión del producto está lista y que este se ha lanzado, tienes que seguir mejorándolo. Los mandamientos de este capítulo tratan sobre las mejoras iterativas y la construcción de una base de usuarios.

Noveno mandamiento:

CONSTRUYE U OPTIMIZA Un último cambio y esta maravilla nos llevará en volandas

Esto no llega ni a carro...

Una vez que tu producto esté disponible en el mercado, todo se revolucionará un poco. Acabarás recibiendo peticiones de: Tus usuarios y equipos de atención al cliente, que te informarán de errores que siempre tendrán que solucionarse inmediatamente. Tus usuarios, que no volverán a utilizar tu producto si no construyes cierta feature para la semana que viene. Tu CEO, que quiere que construyas algo porque un amigo suyo le dijo en una cena que estaría muy bien. Tu equipo de ventas (para software orientado a empresas), pidiéndote que incorpores una feature para lograr su objetivo trimestral de ventas. Suma todo lo anterior a las features que crees que son importantes para estar a la altura de tu competencia o construir algo nuevo e interesante; compaginar lo

70

71

que tú quieres con lo que tus usuarios buscan te parecerá una tarea imposible.

Como Product Owner, escuchar a tus usuarios es muy beneficioso, y una parte

En ese momento tendrás que dar un paso atrás, recordar tu visión de producto e

importante de tu trabajo, pero no dejes que las exigencias y peticiones de tus

intentar definir qué es lo más importante para el futuro de tu producto. Lógica-

usuarios te afecten más delo necesario, pues podrían desviarte del camino.

mente, es mucho más fácil decirlo que hacerlo. En su libro Rework, Jason Fried de Basecamp nos explica cómo evitan ellos que Parte de tu lucha interna (y esencial) de ser Product Owner es dar prioridad al de-

los usuarios dirijan el desarrollo del producto. Llega incluso a decir que no hay

sarrollo de nuevas features, al trabajo de optimización y al desarrollo de mante-

que prestar tanta atención a los comentarios de los usuarios, y que permitir que

nimiento.

los usuarios dirijan el trabajo de tu equipo acaba llevando a crea una colección de features sin ton ni son en lugar de un producto. A modo de ejemplo, veamos esta

El resto de este capítulo recoge una serie de consejos y estrategias que espera-

cita de un capítulo que precisamente se llama «Di que no por defecto»:

mos que puedan ayudarte a tomar estas decisiones tan complejas. «No te creas aquello de que "el cliente siempre tiene la razón"». Imagínate que

No permitas que tus usuarios tomen el control

eres cocinero. Si muchos de tus clientes dicen que tu comida está muy salada

La era del desarrollo de producto orientado al cliente ha llegado. Tanto empresas

estropeando el producto para el resto.»

o picante, la cambias. Pero si unos pocos clientes quisquillosos te piden que pongas plátano en tu lasaña, descartas la idea... y eso es lo que hay que hacer. Contentar a unos pocos clientes alborotadores no merece la pena si eso acaba

grandes como pequeñas (desde conocidas marcas de zapatillas o de patatas fritas) están ahora sacando partido de lo que aportan sus clientes para desarrollar

Esta puede parecer una mentalidad un tanto extrema, pero Basecamp ha demos-

nuevos productos. El concepto de desarrollo de producto orientado al cliente es

trado que esta forma de trabajar puede ser muy eficaz. Centrarse en los usuarios

muy bueno; al fin y a cabo, se trata de un producto que se crea para cubrir las

no significa que haya que atender sus peticiones más excéntricas, sino escuchar

necesidades de sus usuarios. Sin embargo, no es lo mismo el desarrollo orien-

sus problemas y encontrar soluciones con la ayuda de tu equipo. Los comenta-

tado al usuario que el centrado en el usuario.

rios de los usuarios deben considerarse única y exclusivamente como una gran fuente de conocimiento.

A medida que sigues desarrollando tu producto tras el lanzamiento, los usuarios: Pedirán que se incluya una nueva feature, asegurando que están dispuestos a pagar lo que haga falta para que se incluya en el producto, aunque su petición no tenga fundamento.

Entiende el impacto de una feature antes de construir otra

Se quejarán incesantemente sobre un problema que tienen con tu producto,

Lo normal es que cuando lanzas una nueva feature, no suele ser la solución per-

pero seguirán pagando por él y utilizándolo.

fecta a los problemas de tus usuarios, incluso a pesar de haberla probado lo sufi-

Expresan su frustración y exigencias a pesar de que éstas no tengan nada que

ciente previamente. Seguro que has escuchado a tus usuarios y que has dedi-

ver con el producto y su uso.

cado el tiempo necesario a comprender el impacto de una feature, tanto de forma cualitativa (mediante entrevistas a los usuarios) como cuantitativa (mediante

72

73

analítica web). Empezar a trabajar en una feature antes de que se haya confir-

de métricas pirata conocido como AARRR. AARRR gira en torno a la medición de

mado que la anterior ha funcionado significa que no estás aprendiendo de cada

cinco indicadores que utilizan diferentes métricas:

iteración de tu producto, por lo que te recomendamos que incluyas en tu flujo de Adquisición: Cantidad de nuevos usuarios que adquieres.

trabajo una fase de comentarios sobre cada feature.

Activación: Cantidad de usuarios que ya están a bordo y que comienzan a utiSi trabajas con Kanban, una manera de evitar que te olvides seguir la evolución

lizar el producto.

de una feature tras su lanzamiento satisfactorio es incluir una columna de «im-

Retención: Porcentaje o cantidad de usuarios que vuelven y utilizan tu producto

pacto conseguido». Si estás trabajando con Scrum, ten siempre a mano una lista

repetidamente.

de features lanzadas recientemente en una pizarra de software dedicada o de

Ingresos (Revenue): Cantidad de ingresos generados por una cantidad X de

gestión visual.

clientes de pago. Referencia: Cuántos usuarios nuevos atraen tus usuarios actuales.

Backlog

Developing

Lanzado

impacto conseguido

Analizaremos las AARRR en el duodécimo mandamiento. Por ahora, ten en cuenta que cada vez que decides optimizar una feature existente o bien añadir una nueva, esa feature necesita tener impacto suficiente y moverse en uno de esos indicadores. También te recomendamos que intentes darle una visión cualitativa a la satisfacción de tus usuarios. Hay muchas formas de conseguirlo (por ej., utilizando Net

KANBAN DE FLUJO DE TRABAJO

Promoter Score), pero la idea es saber si los usuarios aprecian tu producto y de qué features disfrutan más. Si te das cuenta de que algunas features no le gustan a la mayoría de tus usuarios, puede que haya que plantearse eliminarlas. Si tu

Déjate guiar por los objetivos cuantitativos

producto tiene features que poca gente utiliza o disfruta, puede verse afectado y perder atractivo y facilidad de uso.

¿Aún te cuesta decidir si concentrarte en optimizar o construir nuevas features? Déjate guiar por los KPI cuantitativos; cada decisión que tomes deberá estar orientada a mejorarlos. Para guiar tus decisiones, puedes comenzar por utilizar métricas de negocio tradicionales, como los ingresos y beneficios. Sin embargo, para dar un paso más en tu análisis cuantitativo, te aconsejamos que prestes mucha atención al marco

74

75

Décimo mandamiento:

UTILIZA TUS PRODUCTOS ¿Que si lo he probado?

Utilizar tu producto también es una buena forma de empatizar con tus usuarios. Entender los retos que intentan superar al utilizar tu producto te ayudará en tu misión para intentar resolverlos. Si te pones en el lugar de tus usuarios, es posible que te encuentres con problemas técnicos o de experiencia de usuario antes que ellos, evitando así una situación incómoda o incluso malas valoraciones en

¿Por qué iba a hacerlo?

Google Play o la App Store. Utilizar tu propio producto (dogfooding) ya es una forma de centrarte en lo más importante: la experiencia general del usuario con tu producto. El mero hecho de utilizar lo que has estado construyendo te ofrecerá una visión integral de tu software y te ayudará a verlo tal y como es, sin los condicionantes añadidos de los backlogs, las fechas de entrega y las partes interesadas. Si los miembros de tu equipo de desarrollo logran convertirse en usuarios habituales de tu producto, también podrán entender lo que están desarrollando desde un punto de vista práctico, sintiéndose así más responsables del éxito del producto. Sin embargo, esta ventaja trae consigo un pero: utilizar tu producto muy a menudo podría cegarte, no siendo capaz de ponerte en el lugar de los usuarios. Para evitarlo, te recomendamos que vuelvas a consultar tus user personas tan a menudo como puedas. Esto te ayudará a dejar a un lado el conocimiento que ya tienes de tu propio producto y centrarte en la nueva feature en la que estás traba-

La expresión anglosajona Eat your own dog food fue acuñada por primera vez

jando desde la perspectiva de alguien que nunca pensó que la fuera a necesitar.

por Apple y Microsoft. Esta expresión, que constituyó una parte esencial de la cultura de estas empresas, les recordaba a los empleados que tenían que ser los primeros usuarios y los más entendidos de los productos que ellos mismos estaban construyendo. Este dicho y su cultura implícita aporta muchas ventajas, y muchas empresas la han adoptado desde entonces. Repasaremos los elementos demuestran esas ventajas en los siguientes párrafos.

Entiende a tus clientes La mejor manera de entender cómo utilizan tus usuarios el producto es convertirte tú mismo en un usuario de este. Debes profundizar en el producto y conocer sus puntos fuertes y débiles como si fuesen los tuyos propios.

76

Mejora tu entrega continua Parte de la idea de convertirte en un usuario habitual de tu propio producto es conocer de cerca el concepto de probar un producto sin descanso, que es la clave del enfoque ágil. Utilizar tu producto continuamente, sobre todo si puedes utilizar una versión de preproducción, te permitirá evitar tener que arreglar features que ya hayan sido desplegadas en tu entorno de producción. El hecho de probar y utilizar tu software continuamente también debería ayudarte a programar una serie de entregas frecuentes y sin sobresaltos. Sin embargo, utilizar tu propio producto no te exime de realizar rigurosas pruebas y controles de calidad, ni ahorrar en la calidad del código.

77

El mejor embajador de un producto es el equipo Como Product Owner o Product Manager, está claro que tienes que utilizar tu producto lo máximo posible. Y lo que es más: si esta cultura se extiende a toda la empresa, los efectos pueden ser muy positivos. En primer lugar, podrás contar con la opinión directa de una primera tanda (o anillo) de usuarios, entre los que se incluyen usuarios no tecnólogos o especialistas en producto, como los equipos de administración y contabilidad. En segundo lugar, conseguir que todo el mundo utilice el producto contribuirá a que los implicados se sientan responsables y orgullosos de lo que hacen a diario. Incluso si el trabajo diario de tu equipo no está totalmente relacionado con la evolución del producto, su motivación debería verse mejorada si usan el producto con frecuencia. Por último, esta práctica ofrece la gran ventaja de convertir a todos los integrantes de tu empresa en potenciales embajadores del producto con su entorno más cercano. Los equipos de toda la empresa acabarán conociendo el producto desde una perspectiva mucho más personal, y no dependerán tanto de los equipos de marketing y de producto para comprender lo que sus compañeros están construyendo. Esto es particularmente relevante en el caso de los equipos de ventas. No hay nada más convincente que escuchar el discurso de venta de un vendedor que entiende a la perfección una pieza de software y que incluso es capaz de hacer una demostración con sus propios datos y casos de uso.

78

79

Undécimo mandamiento:

CONSIGUE NUEVOS USUARIOS ¡Todavía no es suficiente ¡prueba otra vez!

objetivos? Además de los objetivos financieros necesarios, como el beneficio, el retorno de inversión (ROI) y los márgenes de beneficio, intenta marcar un objetivo tras superar cada punto clave del recorrido del usuario que hayas establecido. Una buena forma de hacerlo es a través del marco AARRR que presentamos en el décimo mandamiento y que te anima a asignar indicadores clave a cada paso del

Nos está costando más de lo que pensaba

ciclo de vida de tu usuario: Adquisición: El rendimiento de los diferentes canales que estás utilizando para adquirir usuarios (marketing interno o externo, búsqueda pagada, etc.). Activación: Tu capacidad para convertir una adquisición inicial en un usuario real de tu producto. Por lo general, un usuario se considera activo en el momento que ha utilizado las features principales de tu producto (por ejemplo, si ha publicado una foto en Instagram). A esto también se lo conoce como compromiso o integración. La activación no solo depende de tener gran producto; también puede conseguirse de forma activa a través de campañas de activación en tus canales de marketing. Y esta también es una buena forma de hacer que los usuarios inactivos vuelvan a utilizar tu producto. Retención: Cómo de «pegajoso» es tu producto: ¿Cada cuánto tiempo regresan tus usuarios? ¿Cuánto tiempo permanecen como usuarios activos?

Nota: este mandamiento se ha escrito especialmente para productos B2C SaaS o de servicio a consumidores.

Además de construir un gran producto, la otra preocupación del Product Manager es conseguir nuevos usuarios. Estás construyendo algo estupendo, ¡pues claro

Referencia: Una medida de qué porcentaje de tus usuarios animan activamente a sus amigos, colegas o desconocidos en línea para que prueben tu producto. De forma visual, el cuadro será algo así:

EL MARCO AARRR

que quieres que lo utilice mucha gente! ¿Cómo puedes abordar la adquisición de usuarios? ¿Qué pasos debes dar? Este mandamiento repasará los principios básicos de la adquisición de usuarios.

El bloque inicial: objetivos y KPI Antes de lanzar cualquier campaña de adquisición o intercambiar ideas sobre disparatados planes de marketing viral, dedica un tiempo a recuperar tu visión de producto. ¿Qué quieres conseguir? ¿Qué KPI medibles puedes alinear con tus

Marketing externo

Marketing interno

Publicidad, relaciones públicas, marketing directo

SEO, blogging.

Adquisición

Audiencia Referencia

Retención

Activación

Usuarios activos

Churn

Usuarios inactivos Reactivación

Ingresos

Freemium/Publicidad/Venta de bienes y servicios

80

81

Construye y optimiza tu funnel Aunque el marco AARRR parece muy directo, ¡todavía queda mucho por hacer tras bambalinas! Veamos cómo optimizar los primeros tres pasos: adquisición,

tir a tus usuarios potenciales), o a una página para registrarse en tu aplicación. Algunos usuarios rebotarán, lo que significa que habrán dejado tu sitio web sin haber visto una segunda página. Necesitas trabajar en reducir este porcentaje a un mínimo siguiendo estos pasos:

activación y referencia.

Mejora el rendimiento de tu página de destino. Para conseguir esto, necesitas entender cómo tus usuarios potenciales navegan en la página; qué leen, qué

Nota: para profundizar más en la referencia, mira el decimotercer mandamiento.

botones generan interés en ellos, etc. Esto puede hacerse con pruebas A/B o

Paso uno: atrae a tus usuarios potenciales

con una herramientas de analítica como Hotjar o Amplitude. Una vez que en-

Tienes que elaborar una estrategia de adquisición junto al departamento de

que quieres.

tiendas lo que sucede, optimiza las páginas para fomentar el comportamiento

marketing o al Product Marketing Manager para poder tentar a los usuarios y

Mejora el objetivo de tus campañas de marketing. Si la gente rebota de tu pá-

atraerlos hacia tu producto. Hay muchas formas de hacer esto, y normalmente es

gina de destino, ¿puede ser que no hayas atraído a la gente adecuada? Hay

buena idea mezclar varias:

muchos filtros que puedes utilizar para apuntar a tu objetivo de usuarios potenciales si estás utilizando una herramienta como Facebook ads.

Tu ranking de búsqueda, que puedes mejorar trabajando en el SEO (Search Engine Optimisation, u optimización en buscadores) de tu producto. Si estás

Asegúrate de que tu página de destino se ve bien en dispositivos móviles. Esto

trabajando en una aplicación, también puedes trabajar en el ASO (App Store

quiere decir que necesitas una página que responda adecuadamente para

Optimisation, u optimización en las tiendas de aplicaciones) para darle visibili-

adaptarse al dispositivo que está utilizando el usuario. Si estás mostrando un

dad a tu aplicación en los stores de Apple y Google.

enlace de descarga para una aplicación, asegúrate de que es diferente para

Campañas de marketing directo dirigidas a los buzones de entrada de aquel-

los usuarios de Android y de iOS. Pequeños cambios como este pueden mar-

los usuarios potenciales de los cuales posees (o compraste) una dirección de

car la diferencia a la hora de facilitar la experiencia de integración y disminuir

correo electrónico.

tu porcentaje de rebote. Tampoco te olvides de asegurarte de que los enlaces

Publicidad de pago en línea, como por ejemplo SEA (Search Engine Advertising,

utilizados en tu material de marketing son válidos para diferentes dispositivos.

o publicidad en buscadores). Trabajos de relaciones públicas, que requieren que alguien con capacidad de

Optimiza tus páginas de destino y afina la comunicación para los diferentes

influencia escriba hablando de tu empresa o producto. Decidas lo que decidas que es mejor para tu producto, empresa y marca, los usuarios deberían comenzar a llegar a tu página de inicio, de destino o cualquier otra parte de tu producto. Este paso puede optimizarse muy fácilmente de por si: encuentra el enfoque de marketing que genera los mejores indicadores por inversión según marque tu métrica ROI. Con suerte, los usuarios accederán a una página de destino (una página que construyes con el único objetivo de conver-

82

tipos de visitantes: • Debería existir una primera versión de la página para la gente que descubre tu producto por primera vez.

• Debería haber otra versión para aquellos que no se registraron pero vuelven por segunda vez (puedes utilizar cookies para identificarlos).



• Una última versión para los usuarios que ya tienen una cuenta pero han vuelto a la página de destino quizá tras un descanso largo de tu producto

83

Paso dos: convertir a los usuarios potenciales ¿Qué feature o combinación de features pueden presentarse como un recorrido Si tu producto es un servicio SaaS, el objetivo de tu página de inicio seguramente

coherente que permitirá que el usuario entienda para qué sirve tu producto y

sea animar a que tus usuarios se registren en el producto. Por desgracia, no to-

qué problemas intenta resolver?

dos los usuarios potenciales que adquieras superarán esta parte del funnel. Esto

¿Cómo puedes estar seguro de que la solución a los problemas de tu usuario se

es lo que puedes hacer para asegurarte de que no pierdes a demasiados en este

presenta como parte de una experiencia fluida?

punto clave: Una vez que hayas contestado a estas importantes preguntas, te recomendamos Intenta entender qué segmento de tus usuarios potenciales están registrán-

que hagas lo siguiente:

dose. Quizá exista un rasgo distintivo del que puedas sacar partido para optimizar tu objetivo todavía más. Si tu objetivo es perfecto, deberías de tener unos

Lo primero que querrás hacer es un guión gráfico: ¿desde dónde llegará el

resultados de conversión bastante buenos ya, ¡los usuarios potenciales a los

usuario? ¿qué sabe ya del usuario? ¿qué les atraerá más? ¿cómo puedes dirigir

que atraes deberían estar deseando descubrir tu producto y solucionar sus

al usuario de una parte de la experiencia a la siguiente?

problemas!

Piensa en varias opciones: todos tus usuarios son diferentes entre sí y no tienen por qué gravitar alrededor de la misma feature, página o recorrido cuando

Analiza exactamente en qué punto los usuarios abandonan el proceso de regis-

prueben tu producto por primera vez.

tro. Como Product Owner que intenta adquirir nuevos usuarios, es normal que-

Enséñale a tu usuario qué proporción de tu producto ha utilizado o descubierto

rer pedirles mucha información: pero recuerda que cada formulario o pregunta

ya. Por ejemplo: LinkedIn muestra un indicador de porcentaje cuando rellenas

echará atrás a algunos de ellos. Cuanto más largo sea el proceso de registro,

tu perfil.

más usuarios perderás.

Trata de gamificar el proceso desbloqueando nuevas features progresivamente, entregando pequeños premios dentro de tu producto o haciendo que tu usuario

¡Facilítales la vida a tus usuarios potenciales! Implementa los sistemas de ini-

se sienta satisfecho otorgándole un status o título especial.

cio de sesión más apropiados para tu audiencia objetivo. Además, recuerda que mucha gente tiene preferencias muy claras respecto a los mecanismos

Todo esto es mucho trabajo, y debería ser el fruto de una larga colaboración con

de registro. Por ejemplo: no todo el mundo quiere utilizar Facebook Connect.

tu equipo de diseño. Deberías estar buscando constantemente cómo mejorar tu

Trata de ofrecer algunas opciones y deja que los usuarios escojan lo que más

funnel de adquisición y eliminar cualquier fricción que pueda existir en tu pro-

les convenga.

ceso. No dudes en recoger información de primera mano acerca de la experiencia de integración directamente de las opiniones de la app store; hablando con

Paso tres: del registro al usuario habitual

el equipo de atención al cliente, que tiene contacto directo con los usuarios; o incluso hablando con algunos usuarios directamente, si tienes esa posibilidad.

Esta es la parte más complicada del proceso, depende de la calidad de tu producto y de cómo encaje con la audiencia a la que se dirige. Ha llegado el momento de construir y promocionar la primera experiencia que el usuario tendrá con tu producto. Para empezar, contesta a lo siguiente:

84

85

¿Y cómo hago que mi producto sea viral?

NET PROMOTER SCORE (O NPS)

Una vez que hayas encontrado un enfoque de adquisición, activación y retención

forma directa de medir la satisfacción de tus usuarios con tu pro-

que funcione, necesitarás empezar a trabajar en la viralidad de tu producto, o

ducto. El NPS se mide a través de una pregunta muy fácil: De 0 a 10,

dicho en términos más modestos, tu índice de referencia. Por definición, un pro-

¿cuánto estarías dispuesto a recomendar este producto?

Puedes utilizar el NPS para medir la viralidad indirectamente. Es una

ducto viral es aquel que tiene una gran proporción de adquisición derivada de la referencia entre usuarios. Hay dos medidas que puedes observar para entender

Tu NPS te ayudará a dividir tu base de usuarios en tres categorías:

la viralidad de tu producto: De 0 a 6: Usuarios poco satisfechos y que incluso podrían dañar la reputación de tu producto.

EL FACTOR K

De 7 a 8: Este grupo está satisfecho con el producto, pero no está

Este KPI es el indicador de cuántas referencias generadas por usuario.

momento.

Dicho de otra manera, el factor K es la cantidad de usuarios media que cada usuario atrae a tu producto. Para calcular esto, tienes que multiplicar tres variables diferentes: El porcentaje de usuarios que invitan a otra gente al producto. La cantidad de usuarios que invitan de media. El índice de éxito, dicho de otra forma, cuántas de esas invitaciones

enamorado del producto y podría saltar a la competencia en cualquier De 9 a 10: Estos usuarios adoran tu producto y están preparados para recomendarselo a su familia, amigos y compañeros. Una vez que hayas recogido esta medida de una cantidad suficiente de usuarios, puedes calcular la diferencia entre la cantidad de usuarios satisfechos e insatisfechos. Si tu resultado es negativo (más usuarios insatisfechos que satisfechos), tendrás que trabajar en la satisfacción

generan la adquisición de un nuevo usuario.

de tus usuarios. Si es positiva, ¡vas por el buen camino!

Todo el mundo sueña con tener un producto cuyo factor K es mayor

Si quieres mejorar tu índice de referencia puedes construir features

que 1, porque eso significa que el índice de crecimiento por referencia orgánica es exponencial. Por supuesto, tendrás que trabajar en mejorar tu factor K mejorando tu funnel de adquisición y el propio producto.

sociales que ayuden a que los clientes más satisfechos compartan tu producto. Sin embargo, ten cuidado con esto: no quieres crear una feature que genere spam y que termine por tener un efecto negativo en la viralidad de tu producto.

Herramientas Todo lo que necesitas para comenzar a mejorar tu adquisición, activación y retención lo encontrarás en el duodécimo mandamiento.

86

87

Duodécimo mandamiento:

LA ADQUISICIÓN ES BUENA, PERO LA RETENCIÓN ES MEJOR

del producto y sus objetivos. Sin embargo, ten cuidado con contar a los usuarios que se conectan a tu sitio o aplicación como usuarios habituales, ya que algunos puede que no estén utilizando ni una sola feature. Te recomendamos pensar en alguna clase de «funnel de retención», un conjunto de comportamientos de usuario necesarios para considerar si una persona es un verdadero usuario de tu producto o no. Por ejemplo, Spotify podría utilizar un número concreto de reproducciones musicales al mes para definir lo que considerarían un usuario activo

Allá vamos, ¡a toda máquina!

mensualmente. ¡Espera un momento, por favor!

Las cohortes tienen la respuesta Contar cuántas cuentas de usuario hay registradas en tu servicio es obvio, y puede que te haga sentir que has cumplido con tu misión como Product Manager. Sin embargo, está claro que este número se incrementará con el tiempo, así que no es un gran indicador de la salud de tu producto (a menos que elimines cuentas, cosa que no te recomendamos). Incluso si quieres definir una métrica para usuarios activos mensuales, podrías acabar cometiendo el error de sobreestimar el éxito de tu producto. Por supuesto, tener un número de usuarios activos mensuales cada vez mayor son buenas

Si tu producto necesita un gran volumen de tráfico habitual para darle valor a la

noticias, pero incluso esta métrica algo más precisa no te ayudará a entender

empresa (y seguramente este sea el caso si tu producto es freemium, SaaS, ba-

si tus usuarios siguen utilizando tu producto tras un cierto periodo de tiempo,

sado en publicidad o en compras dentro de la aplicación) es posible que ya seas

o si simplemente estás adquiriendo cada vez más usuarios que solo se quedan

consciente de que adquirir usuarios es muy bueno, pero asegurarte de que esos

durante unos meses.

usuarios que adquieres por primera vez vuelvan a utilizar tu producto es todavía más importante. En otras palabras, no podrás hacer crecer tu producto y base de

Para poder tener una imagen más precisa de cuánta gente utiliza tu producto con

usuarios si no aciertas con la retención. En las siguientes páginas encontrarás

asiduidad, te recomendamos que utilices un análisis de cohortes. Una cohorte es

unas guías para ayudarte a mejorar la retención de tu producto.

un grupo de usuarios que comparten un rasgo común; en el caso de la industria del software es normalmente la fecha de registro en tu producto. Analizar tu pro-

Mide tu retención Antes de intentar cuantificar tu retención necesitarás definir lo que la retención significa para tu producto. La retención no es algo fácil de definir, depende mucho

88

ducto utilizando cohortes implica que construirás grupos de usuarios definidos por la semana en la que se registraron en tu producto. Entonces podrás evaluar el uso que cada grupo hace de tu producto semana a semana para ver si cada grupo, de media, utiliza tu aplicación durante más o menos tiempo (semanas, meses, años...). Como Product Manager, todas las features que decidas desar-

89

rollar con tu equipo y las iniciativas de marketing en las que trabajes deberían

usuarios, pueden ser muy útiles para probar versiones beta de nuevas features e

intentar mejorar tu índice de retención de cohortes, esto es, que los usuarios de

invitar a nuevos usuarios.

cada cohorte deberían seguir siéndolo durante un periodo de tiempo más largo Usuarios inactivos: En algún momento fueron usuarios regulares de tu producto,

que la cohorte anterior.

pero hace mucho tiempo que no se han conectado a tu sitio web o aplicación. Tu Una vez que esté todo preparado, la mejor forma de estudiar tu retención de co-

objetivo debería ser entender por qué han dejado de utilizar tu producto, corregir

hortes es con un mapa de calor triangular, como el que se muestra a continua-

los problemas potenciales con los que se encontraron y comunicárselo para que

ción. Esta tabla te permitirá visualizar fácilmente el valor expresado en porcen-

vuelvan a ser activos.

taje de retención de cada cohorte, semanalmente. Usuarios resucitados: Estos son los usuarios que dejaron de ser inactivos. Es importante no confundirlos con los usuarios habituales que nunca dejaron de

MAPA DE CALOR TRIANGULAR Usuarios

utilizar tu producto, porque tienes que intentan comprender qué les hizo regresar Semanas

a tu producto y qué es importante para ellos.

SEGMENTACIÓN DE USUARIOS Cohortes de usuario se muestran horizontalmente y te permiten entender la retención Retención de fecha específica te permite entender cómo los hábitos de uso se pueden ver afectados por fechas específicas (vacaciones, fines de semana, paradas de mantenimiento...).

Activación Adquisición

Nuevos usuarios

Retención para la semana 2 de todas las cohortes

Usuarios activos mensuales incluyendo usuarios expertos

Abandono

Abandono

Resurrección

Usuarios inactivos

Analiza el compromiso de tus usuarios Para poder entender correctamente tus métricas de retención necesitas segmentar también tu base de usuarios según la frecuencia de uso y fecha de última visita. Una forma fácil de hacerlo es dividiendo tu base de usuarios en tres grupos. Usuarios expertos: usuarios habituales que conocen muy bien tu producto. Es posible que sean usuarios activos en tu comunidad, ya sea en redes sociales, foros, o en tu propio producto si tiene un componente social. No te olvides de estos

90

Según tu producto, puedes segmentar tu audiencia de formas diferentes. Puede que la mejor forma de diferenciar segmentos sea por la duración media de la sesión o quizá por las features más frecuentemente utilizadas. Es importante recordar que para mejorar la retención de usuarios necesitas conocer más a fondo tu base de usuarios, y la segmentación por compromiso de usuario es una buena manera de conseguirlo.

91

Mejora tu retención Averiguar cómo debería ser la retención de tu producto puede resultar complicado. Te recomendamos que lo consultes con otros Product Managers con productos similares o que leas algún blog recomendado para intentar encontrar un objetivo de retención mínimo con el que empezar. Ten en cuenta que la retención varía mucho entre los diferentes segmentos de mercado, tipos de producto y el tipo de usuarios a los que intentas atraer y retener. Una vez que te hayas marcado un objetivo, puedes empezar de varias formas:

usuarios: ¿Se han olvidado de tu producto? ¿Por qué? ¿Dejó esta persona de utilizar la aplicación por un error o porque faltaba una feature? Si logras averiguar por qué tus usuarios se están olvidando de tu producto, podrás crear y aplicar una campaña mucho más efectiva para reactivarlos: Menciona una feature que no existía cuando utilizaban tu producto. Explícales que un problema conocido de tu producto se ha solucionado y hay

Trabaja en el marketing de tu producto

una actualización disponible.

Tu índice de retención refleja la propuesta de valor de tu producto: si mucha gente

Mejora el funnel de retención de tu producto

está probando tu producto, pero pocos se convierten en usuarios recurrentes, es posible que haya una falta de coherencia entre tu mensaje de marketing y el valor que ofrece tu producto. Si ese es el caso, reorienta tus esfuerzos de marketing para asegurarte de que se centran en el valor real que tu producto ofrece a los

Antes de comenzar a trabajar, estudia bien tus métricas e identifica qué partes

usuarios.

del ciclo de vida del usuario te están costando más usuarios. Intenta averiguar por qué sucede y piensa en cómo puedes mejorar tu producto y darle fluidez al

Reactiva a tus usuarios Hoy en día estamos rodeados de magníficos productos digitales. Es posible que tus usuarios se olviden de tu aplicación o servicio si tienen la pantalla repleta de diferentes aplicaciones, o en un navegador con una lista de favoritos quilométrica. Es posible recuperar a estos usuarios si les vuelves a invitar a utilizar tu producto. Una buena campaña de marketing puede hacer maravillas si se planifica bien. Pero ojo: algunas campañas de marketing pueden resultar demasiado agresivas, mal orientadas o muy insistentes y tener un efecto negativo, alejando a tus usuarios para siempre. Para evitar que esto suceda, antes de empezar hazte estas preguntas sobre tus

92

funnel. Una gran estrategia es identificar a los usuarios individuales que han dejado de utilizar tu producto en el punto de tu funnel en el que estás teniendo más problemas y entrevistarles. Para aislar e identificar a estos usuarios, necesitarás herramientas de analítica avanzada (Amplitude funciona muy bien). Así, estos usuarios podrán explicarte el problema que tuvieron, lo cual confirmará tus sospechas o bien te reconducirá por otro camino. Además, a lo mejor pueden proponer mejoras para tu producto. Tras hablar con una docena de usuarios y seleccionar unas cuantas buenas ideas, realiza algunos test A/B en diferentes cohortes y mide los resultados. Después solo necesitarás mantener aquella implementación de producto que te ofrece los mejores resultados de retención.

93

y comentarios es un excelente lugar para comenzar. AppAnnie o Distimo pueden Las mejoras iterativas son muy buenas, pero a veces tendrás que dar un paso

facilitarte la tarea.

más para conseguir los resultados que quieres: Si quieres invitar a tus usuarios a que compartan sus impresiones directas, Piensa de nuevo tu experiencia de usuario desde un punto de vista más pro-

busca algo como UserVoice, un servicio fácil de configurar y que te permitirá

fundo y global. Para mejorar tu retención, puede que merezca la pena modificar tu

estar en contacto directo con tus usuarios. También puedes intentar mejorar las

producto para incluir features de gamificación o un nuevo sistema de onboarding.

opiniones de tus clientes de forma más general, pidiéndole a los equipos de aten-

Intenta construir features que enganchen y que aseguren que tus usuarios ten-

ción al cliente que utilicen una herramienta como Zendesk; así, tendrás acceso a

gan que volver a menudo. Las features con un componente social suelen funcio-

paneles y métricas que te ayudarán a mejorar la retención.

nar bien, porque generan compromiso y también te dan un motivo para enviar notificaciones a tus usuarios cuando otros usuarios interactúan con ellos. Si aún te está costando encontrar ideas que mejoren tu retención, dale un giro a la situación estudiando a tus usuarios expertos en lugar de a aquellos que se olvidan de tu producto. Estos usuarios están en contacto con lo que hace que tu producto sea bueno, y el hecho de que lo usen de forma habitual es un buen indicador del valor que tu producto les ofrece. Utilízalos como inspiración para demostrarle al resto de usuarios lo brillante que es tu producto.

Las herramientas Como hemos destacado a lo largo de este mandamiento, mejorar tu retención comienza por un buen entendimiento del uso que se le da a tu producto. Para ello, hoy en día existen muchas herramientas de analítica que te ayudarán: Google Analytics, Mixpanel, Amplitude, Fabric y Kontagent, Contensquare son algunas de las más recomendables. Tómate tu tiempo para probarlas y valorarlas, pues encajarán mejor o peor con tu producto según la plataforma (web, móvil...), el modelo de negocio (por publicidad, suscripción...) y los usuarios (consumidores o empresas). Además de la analítica pura y dura, hay otros aspectos que debemos considerar: ¿Qué dicen los usuarios de tu producto? Si estás administrando una aplicación móvil que se distribuye a través de una tienda, estudiar y seguir sus valoraciones

94

95

Decimotercer mandamiento:

CUÁNDO Y POR QUÉ CANCELAR O RETIRAR TU PRODUCTO

activa de un Product Manager o un equipo de estrategia de producto para poder cancelarlos adecuadamente y evitando el máximo posible de daños colaterales. En el mundo de las startups es habitual ver a pequeñas empresas emergentes con una gran cantidad de productos con muchas features. A veces, esto puede funcionar, pero a menudo llega un punto en que la variedad de productos y servicios impide el crecimiento de una empresa. Ya sea para reaccionar ante un mercado

Deberíamos desconectarlo...

que evoluciona o construyendo algo para un posible cliente importante en el en-

¿De verdad?

torno B2B, hay muchas razones para diversificar un producto en otro nuevo, aña-

¿Está seguro?

dir una serie de nuevas features a un producto existente o comenzar una nueva Si parece que está bien...

línea de productos. Alargar esto durante mucho tiempo sin consolidar o cancelar ninguno de tus productos puede dañar tu adquisición de usuarios, su satisfacción y la retención. Por lo general, el equipo de producto se dará cuenta de que esta estrategia de producto rápida y poco cuidada no les funciona y se tomará la decisión de consolidar o cancelar algunos productos. Un claro ejemplo es el caso de 37 Signals (ahora Basecamp), una empresa de servicios de software. A comienzos de 2014, el equipo de 37 Signals anunció que cancelaban casi todos sus productos, salvo Basecamp. En aquel momento, Basecamp generaba el 87 % de los ingresos y el 90 % del crecimiento de la empresa. Se arriesgaron incluso a cambiar la marca de la empresa, abandonando el nombre original de 37 Signals para adoptar el nombre de su producto estrella: Basecamp.

Los Product Managers tienen la tendencia a hablar de sus productos como si fuesen lo mejor del mundo, la solución perfecta a los problemas de la gente. Y es perfectamente normal, porque diseñar, construir, probar, publicar y mantener un producto implica mucho trabajo. Sin embargo, todo ese entusiasmo que transmites u otros te transmiten esconde una realidad inevitable: casi todos los productos acaban muriendo. Puede pasar lentamente, de forma controlada... o de repente. Algunos productos van desapareciendo lentamente porque, por ejemplo, la tecnología en la que se basan ya no se utiliza (¿te acuerdas de las aplicaciones de los primeros móviles y el WAP?). Sin embargo, otros requieren la intervención

96

Este tipo de transición nunca es fácil para las empresas, y los Product Managers involucrados harán muchas preguntas difíciles de responder tanto para ellos como para la dirección: ¿por qué se canceló mi producto? ¿Qué pasó con ese gran lanzamiento en el que estábamos trabajando y que pensábamos que aumentaría los ingresos? ¿Cómo le voy a decir a los clientes y usuarios del producto que este se va a cancelar? Por supuesto, nadie comienza un producto con el objetivo de cancelarlo, pero es parte del trabajo del Product Manager asegurarse, si hace falta, de que la cancelación de un producto se lleva a cabo sin dificultades y por los motivos adecuados.

97

inicial de la empresa o porque su deuda técnica se convierte en algo imposible Incluso cuando las compañías van más allá (Google, por ejemplo), es importante

de sobrellevar.

que mantiene esta estrategia y best practice de retirar del mercado regularmente parte de su cartera de productos. Le invitamos a echar un vistazo a todos los productos "Killed by Google" en https://killedbygoogle.com/.

¿Tu producto está pasando un mal momento? Como Product Manager, necesitas preguntarte las siguientes preguntas cuando empieces a tener la sensación de que el camino se está complicando mucho: ¿Es tu producto económicamente viable? - Dicho de otra forma, ¿son los ingresos que genera suficientes? ¿Estás cumpliendo los objetivos? - ¿Y el margen de beneficio? ¿Te cuesta generar beneficios debido a los altos costes de mantenimiento y al exceso de deuda técnica? ¿Cuentas todavía con el equipo y los recursos para garantizar que tu producto se desarrolla, prueba, entrega y mantiene con un alto nivel de calidad? ¿Emplearía mejor tu equipo el tiempo si trabajase en otro producto de tu empresa con más éxito? ¿Tu producto está acabando con otros productos de tu empresa o están estos acabando con tu producto? De ser así, ¿qué productos están cosechando más éxito, el tuyo o el resto? En el caso de Basecamp, la decisión de cancelar la mayoría de sus productos se produjo porque no querían que la empresa creciese más. Decidieron que era mejor seguir siendo pequeños y que, para poder construir productos de alta calidad, reducirían la cantidad de productos en los que trabajaban los equipos, centrando los esfuerzos de la empresa en el producto más rentable y prometedor. Muchas veces es necesario cancelar un producto porque este se ha alejado del propósito

98

¿Cómo puedes cancelar un producto adecuadamente? ¿Deberías dejar de prestar tanta atención a tu producto, pero seguir vendiéndolo? ¿Deberías dejar de venderlo, pero asegurarte de la corrección de los errores y del mantenimiento general para que tus clientes actuales puedan seguir utilizándolo? ¿Deberías cancelarlo por completo, dándole a tus usuarios tiempo suficiente para migrar sus datos y encontrar otro producto? La decisión es tuya, y depende mucho del contexto de tu empresa. Sin embargo, si decides cancelar completamente un producto, antes de darle al botón de apagado te recomendamos que le des el tiempo suficiente a tu clientes y usuarios para entender lo que va a pasar y para que puedan encontrar otra solución que se adecúe a sus necesidades. Aquí van algunos ejemplos: 37 Signals decidió mantener mayoría de sus productos hasta el día de hoy, pero ya no lanza actualizaciones ni features nuevas. En parte, los mantienen en marcha para venderlos o crear spin-offs en la medida de lo posible, como hicieron con su CRM, Highrise. Google es conocido por lanzar muchos productos diferentes e, inevitablemente, cancelar muchos de ellos. Es conocido el caso de Google Reader, un lector RSS y agregador de noticias muy querido. Antes de cancelarlo por completo, ofrecieron tiempo suficiente a su comunidad para que encontrase otras soluciones que cumpliesen con sus expectativas. También cancelaron la red social Orkut, y de nuevo se aseguraron de ofrecerle tiempo suficiente a sus usuarios para descargar sus fotos e información antes de cancelar el servicio para siempre.

99

Adobe cedió su framework Flex a la fundación Apache en lugar de cancelarlo oficialmente. Esto a veces se considera la solución más fácil y rápida, porque la

Agradecimientos y reconocimientos:

comunidad de open source sigue ofreciendo soporte para el producto y el dueño inicial no tiene que preocuparse de los usuarios enfadados. El mundo del open source puede ser una especie de papelera de reciclaje para muchas piezas de

No habríamos podido terminar este libro sin todos aquellos que dedicaron su

tecnología más antigua o propietaria.

tiempo a escribirlo, leerlo, editarlo y diseñarlo. Muchas gracias a todos los que

¿Estoy perjudicándome a mí mismo si cancelo mi producto?

participaron, en especial: • A todos los miembros de Thiga que escribieron o editaron partes del libro. • A Marie Aumont, de Michel & Michel, por su agilidad, amabilidad y gran ética profesional

Si gestionas varios productos, cancelar uno de ellos no es tan malo. Tendrás más

• Florent Farvacque, por sus ilustraciones llenas de humor .

tiempo y recursos para dedicarle al resto de tus productos, lo que con suerte

• Patricia Lluberas y Cesar Alonso por su tiempo, correcciones e intento de mejo-

significará que te irá mejor con ellos.

rar lo mas posible este libro para todos los Product Managers hispanohablantes. • Lydie Billaud, de la agencia Michel & Michel y Sarah Borderie de la agencia

Si solo gestionas un producto, puede ser muy duro ser la persona que sugiera que

Creads Partners por el intenso trabajo hasta el último momento, y por soportar

a tu producto le ha llegado la hora, por dos motivos:

nuestros cambios de opinión incesantes (eso es mucho más que agilidad).

Cancelar tu producto puede hacerte sentir que todo tu trabajo ha sido en vano y, como resultado de ello, tus perspectivas laborales sufrirán un revés. Puede que creas que no «valías» para construir un producto duradero. Sin embargo, que un Product Manager cancele su propio producto hoy en día puede entenderse como una maniobra empresarial inteligente, pues en principio pones fin a un malgasto de recursos, tiempo y esfuerzo dentro de la empresa. Con suerte, tu equipo y tú seréis capaces de centraros en un tema más fructífero. ¡Los Product Manager también son humanos! Si has estado trabajando duro en algo durante varios años, es comprensible que sea difícil poner fin a tu propio producto. La decisión de cancelar un producto es difícil de afrontar. Utiliza todo lo que tengas a tu disposición para medir los impactos y posibles consecuencias que tendrá tu decisión. No es una situación agradable, pero saber cuándo es el momento de dejar de luchar por tu producto puede ahorrarte muchos dolores de cabeza y noches sin dormir, además de dinero, tiempo y recursos.

100

101