Diplomatura en Product

Management
Módulo 2:

User Experience y Tecnologías en la

era del Software

Unidad 2:

User Research y MVPs

Presentación

En esta unidad del curso se presentan los marcos de trabajo basados en datos de
usuario para generar una primera versión del producto.
Objetivos
● Saber cómo diseñar y lanzar un producto en base a datos del usuario.
● Cómo priorizar lo más importante para el usuario.
● Entender cómo hacer un lanzamiento de producto.
Bloques temáticos
1. Necesidades vs Requerimientos 6
2. Kano Análisis 10
3. Principio de Pareto o Regla del 80/20 16
4. Observación Directa e Indirecta 18
5. Funnel de Ventas 20
6. MVP y MVF 22
7. Lean Startup 24
8. Lean UX 28
9. Testing A/B 31
10. Canary Release & Rolling Deployment 34
11. Concierge 36
12. Mystery Shopper 38
13. Feature Stub 40
14. Conclusiones 43
1. Necesidades vs Requerimientos
Equilibrar los problemas y las necesidades de los usuarios con los requerimientos
internos suele ser algo desafiante ya que solemos confundirnos los problemas de los
usuarios con los requisitos internos. Debemos considerarlos como temas igualmente
importantes pero muy diferentes.

Muchos Gerentes de Producto pueden representarse con este escenario Anti-Product

Manager o también llamado “Mozo”:

Su trabajo es "recopilar los requisitos" del negocio. Acudir a la gente del negocio y
preguntarles qué se necesita construir. Dentro de la gente del Negocio suele haber
algunos que hablan con los usuarios. De los que hablan con los usuarios, también
están los que les preguntan que construir, lo cual no es bueno porque los usuarios no
son diseñadores, solo son una persona que tiene una experiencia puntual con el
producto de muchas experiencias posibles. En general la gente de negocios da una
lista larga de requerimientos sin priorizar o con casi todos los requerimientos con la
misma prioridad, y le piden al PM construirlas. Sin embargo, estas no siempre están
relacionadas con problemas de los usuarios. La mayor parte del tiempo se está
construyendo lo que la empresa piensa que es necesario en lugar de resolver las
necesidades reales de los usuarios. Diseños no basados en datos o con datos de una
o dos personas amigas, familiares o compañeros de trabajo que usan o podrían usar
el producto. En definitiva, son datos no representativos. Otro inconveniente es que
la lista de requerimientos varía durante la construcción por variación de prioridades
internas o motivos caprichosos. Esto ocasiona dejar desarrollos frenados, para ser
retomados luego, con impacto en la eficiencia, aumento de tiempos de desarrollo,
disminución de la calidad, mayor riesgo a errores y malestar en el clima laboral, por
falta de previsibilidad en lo que se tiene que hacer.

Este escenario pre apocalíptico, suele ser el de la mayoría de las empresas en mayor
o menor medida antes de abrazar la Agilidad, Design Thinking, Lean Startup u otros
marcos de trabajo saludables. Estos marcos de trabajo tienen el foco en dar valor al
usuario y al negocio en contextos complejos.

Los requerimientos pueden aparecer en las siguientes formas:

● Lo que necesita un sector para funcionar, algo interno no siempre necesario

o de valor usuario/negocio.
● Lo que un sector dice que el usuario les pide, desarrollar algo, que no se sabe
a qué necesidad viene asociada. O que datos o análisis se usó para tomar esa
 decisión. En ocasiones estos vienen con una estimación de la ganancia que se
obtendrá al construirlos, la cual no se suele controlar.
● También los requerimientos pueden venir con fecha fin, o esfuerzo fijado por
gente que no desarrolla ni construyó nunca.
● Otra variante son los requerimientos descritos en 5 palabras, que nadie
entiende que son, ni la persona que los escribió.
● Ideas de solución vestidas de problemas. En algún momento se definió un
template para requerimiento que tiene un espacio para completar el
problema pero esto se malinterpreta y se pone la solución. Ejemplo: el cliente
necesita una billetera virtual, o el cliente tiene el problema de no tener una
billetera virtual. La pregunta que busca encontrar el problema es ¿para qué
el cliente quiere una billetera virtual? La respuesta puede ser para enviar
dinero a sus amigos cuando comparten gastos y el saber este problema puede
llevar a un gran número de soluciones. Muchas veces solo se sabe lo de la
Billetera virtual, porque simplemente se copió a la competencia, que vienen
ganando en clientes.
● Requisitos disfrazados en lenguaje técnico, ni si quiera se entiende que es la
solución, son como un conjunto de piezas de rompecabezas que no se sabe
que forman.

Fuera del mundo del revés, hay dos requisitos que se debe buscar:

● Necesidades insatisfechas: problemas que el cliente conoce y puede definir.

● Necesidades no detectadas: frustraciones que los clientes no saben que
tienen.

Veamos un ejemplo de una necesidad no detectada. El hombre invento la rueda en

la edad de piedra y la valija se inventó en 1880 cuando se popularizó los viajes. Hasta
1987 no se inventó la valija con ruedas, más de 80 años con una necesidad no
detectada.
Las experiencias, o vivencias de los usuarios sirven para detectar problemáticas o
necesidades.

"Tengo que llevar la valija durante 15 minutos de una punta a otra del aeropuerto".

“Para avanzar una canción a la siguiente, hay que presionar FF en la casetera unos
10 a 30 segundos aproximadamente, dependiendo del largo del tema actual”.

“En la máquina de escribir debes estar atento porque si hay un error de ortografía o
algo mal tipeado hay que escribir la hoja nuevamente”.

Al entender el contexto del usuario por medio de entrevistas se puede detectar

problemas que él no sabía que tenía o inclusive estaba tan resignado, que los olvidó.

Aprender a realizar entrevistas a usuarios, entender sus frustraciones y sus

experiencias, es la clave para escribir un requerimiento de solución. Entender el
contexto, porque hace lo que hace, qué valor tiene para él, cuánto pagaría por
resolver este problema, luego de esto se va entender cuál es el camino a la mejor
solución.

Y si usted es un PM de esos que le llegan esos requerimientos apocalípticos, le

sugerimos que profundice hasta entender la necesidad del usuario, y luego con su
equipo de desarrollo proponer una hipótesis de solución al problema.

El PM debe tener su foco en solucionar los problemas que realmente tienen los
usuarios para que la empresa siga funcionando o sigan llegando contratos (en el caso
de ser un contratista).

Una herramienta que puede servir para transformar conversaciones sin criterio o sin
criterio de valor para la organización, es utilizar un diagrama de priorización muy
simple,con dos ejes:

● Alineación al Negocio: cada empresa debe tener una estrategia puntual, para
un trimestre o para el año. Cuanto más alineado esté el requerimiento más
importante será. Si su organización no tiene una estrategia claramente
definida, le recomendamos que mientras tanto tome el criterio de lo que más
beneficios económicos generará. Eje Y
● Valor al Cliente: qué valor tiene el resolver esta necesidad o problema para
el usuario. Eje x

Con estos dos ejes presentes y dibujados puede agrupar los requerimientos que
relevados.
2. Kano Análisis
En la primera etapa del proceso de desarrollo de Producto, el foco es Empatizar con
los usuarios target, para entender su contexto, necesidad, problema y oportunidades
de mejora. El modelo Kano que veremos a continuación es una de las técnicas más
importantes de priorización de características de producto.
Modelo Kano
Esta técnica fue desarrollada en los años ’80 por Noriaki Kano, a través de la cual se
estudia el impacto que tiene en los usuarios las mejoras en las diversas
características de los productos. Explicando cómo algunas mejoras solo alcanzan
para mantener las expectativas básicas mientras que mejorar otros aspectos pueden
cautivar o enamorar a los clientes con un esfuerzo mucho menor. Por estas razones
la herramienta facilita la gestión de productos ordenando la priorización de acuerdo
con el segmento del mercado que deseemos cubrir.
El modelo utiliza un gráfico de dos ejes para realizar el mapeo de las diferentes
características según sus valores correspondientes a la satisfacción brindada por la
inversión.
Las categorías descriptas por Kano son:
Obligatorias: Son aquellas características que los clientes asumen como implícitas
del producto por lo cual, no suelen explicitar como necesidad pero su ausencia o
pobre implementación generan una gran insatisfacción. Esto nos sirve para moderar
la inversión en estas características dado que una vez cubierto el estándar del
mercado posiblemente no generará un mayor incremento en la satisfacción del
cliente. Algunos ejemplos pueden ser que un hotel brinde agua caliente en los baños,
un celular con tecnología WiFi o que el auto cuente con sistema de sonido.
Desempeño: Estas tienen una relación directamente proporcional con la calidad de
su implementación. Esta relación lineal cuando se implementa bien dan más valor,
cuando se implementan mal resta. Suelen ser las que piden los usuarios, no son
grandes innovaciones. Estas características esperadas en el producto compiten de
manera directa con las brindadas por otros productos. Los productos que solo
satisfacen las características "Obligatorias" y "Desempeño" pueden ser percibidos
como "promedio" del mercado y por lo tanto reemplazables con otros similares que
seguramente existen y en estos casos el diferencial debe estar en otro punto
(ejemplo el precio). Un ejemplo puede ser un jabón con fragancia, el usuario estará
más contento de acuerdo con la calidad de la fragancia que perciba. Si no percibe la
fragancia o esta no la huele bien restará. Otro ejemplo en el caso de un hotel, una
necesidad obligatoria es una cama, la necesidad de desempeño es que tan buena sea
la cama, si la cama es muy mala resta, si es muy buena suma.
Atractivas: Estas características son aquellas no esperadas por el cliente que
implementadas generan una enorme satisfacción, pero en caso de no estar presentes
el cliente no estará descontento. Podríamos verlas como diferenciadoras que separan
nuestro producto de los competidores. Es por eso que incluso implementaciones no
del todo refinadas tienen el potencial de generar gran impacto y satisfacción en el
cliente. Ejemplos con las pilas que empezaron a incluir un medidor de cuanto queda
de carga, la lavandina que agregó un sistema anti-salpicadura o los bancos que te
alertan del vencimiento del pago de impuestos. Si no están las características
obligatorias y las de desempeño, las atractivas no agregan ningún valor. Ejemplo: si
la televisión no tiene control remoto (característica obligatoria) no importará que
tenga extra-resolución (característica atractiva), nadie la comprará.
Indiferentes: son estas características que no generan diferencia existan o no. Estas
funcionalidades suelen implementarse, sin tener en cuenta el punto de vista del
cliente y deben suprimirse para ahorrar costos. (Si hay muchas de estas, pueden
tapar las funcionalidades principales y pasan a convertirse en indeseadas). Ejemplo,
una mesa que está decorada en la parte no visible, el enchapado de la parte no
visible de los cajones, asientos resistentes a 450 kg pero que se vende a personas
que pesan menos de 150 kg.
Indeseadas: Son las características opuestas a las unidimensionales. Son aquellas que
el cliente activamente no quiere y cuantas más de ellas tenga el producto mayor
será su insatisfacción. Ejemplo: cuando se presenta una picada de queso en el plato
y para decorar este se dibuja un ratón que es lo que menos quiere ver un cliente.
El impacto del tiempo
El estudio de Kano además de categorizar las necesidades también descubrió que
estas no son fijas, sino que dependen del momento de su implementación y tienden
a trasladarse con el paso del tiempo. Así, por ejemplo, una característica
considerada atractiva al momento de implementarse pronto puede convertirse en de
desempeño y eventualmente en obligatoria. Tal es así con las cámaras en los
celulares, las cuales inicialmente fueron una característica atractiva y rápidamente
se volvieron de desempeño cuando los clientes la esperaban en cualquier equipo, (y
cada vez con mejor calidad) para actualmente considerarse mandataria.

En Silicon Valley, cuna de la ideación, se suele decir que la ideas

no valen nada lo importante es la ejecución.
Priorización por MoSCoW
Este método de priorización es uno de los más simples y conocidos en el mundo de
la construcción ágil. Su nombre proviene de la combinación de palabras de acuerdo
con el tipo de prioridad que puede asignarse:

● Must have (Mandatoria): Son aquellas funciones que DEBEN ser incluidas en el
producto para poder salir a producción, esta definición de alcance es clave al
inicio del proyecto para definir el MVP (mínimo producto viable).
● Should Have (Debería Tener/ Esperada): Estas funcionalidades exceden lo
incluido en el MVP por no ser críticas, pero son importantes y le dan un gran
valor al usuario y se deberían implementar tan pronto como sea posible.
● Could Have (Podría tener / Deseable): Son aquellas funcionalidades que
aportan algún valor y pueden no ser costosas, pero serán las primeras en quitar
del alcance en caso de excedernos en el tiempo o tener menos recursos.
● Won't Have (No están incluidas, pero se analizará para un futuro): estos
pueden ser requerimientos solicitados pero excluidos por el momento.
Lo importante de aplicar esta técnica es mantener un balance entre el porcentaje
de características de cada uno de los tipos para mantener flexibilidad durante la
priorización. Si todas las características a desarrollar son Must, no se podrá reducir
el alcance, puede esto ser necesario para cumplir con la fecha de implementación.
Normalmente los porcentajes que se suelen asignar a cada una son: un máximo de
60% a los mandatorios, y 20% para cada uno de los restantes.
Es importante ser muy claro y transparente con los interesados sobre la asignación
de estas prioridades, para que sepan que solo el “Must” es lo que asegura de mínimo
el equipo de desarrollo para realizar en un periodo dado.
Equivalencia de las prioridades del modelo Kano con MoSCoW
 MoSCoW Kano

Must o Debe Obligatorias

Should o Debería Desempeño

Could o Podría Atractivas

Won't Have o No Indeseadas, Indiferentes

tendrá

Valor vs Complejidad de desarrollo

Este tipo de priorización, que también puede verse como impacto / dificultad, es
una herramienta muy clásica que se la utiliza tanto para la gestión del producto como
otras áreas que requieran sopesar un plan de acción.
Consiste en un gráfico de dos dimensiones con los ejes de valor y complejidad. El
primero se refiere al valor que el negocio considera que le aporta una característica
y el segundo es la complejidad de desarrollo, la cual suele indicarla el equipo
técnico, es el esfuerzo + incertidumbre. En ambos casos conviene tener valores
relativos para facilitar la priorización entre ellos.
Con esta información es mapeada en el gráfico cada una de las características de la
siguiente manera:
Una vez terminado este mapeo procedemos a identificar en cuál de los cuatro
cuadrantes posibles (alto valor-baja complejidad, alto valor-alta complejidad, bajo
valor-baja complejidad, bajo valor-alta complejidad) está cada una. Las ubicadas en
Alto Valor-Baja Complejidad entrarán como primera prioridad, en cambio las
correspondientes a bajo valor y alta complejidad las descartamos del alcance. Las
características ubicadas en los otros dos cuadrantes deberán priorizarse entre ellas
para lograr una cohesión en el producto maximizando el valor y minimizando el costo.
3. Principio de Pareto o Regla del 80/20
El economista italiano Vilfredo Pareto, que a principios del siglo XX llegó a la
conclusión de que para muchos eventos aproximadamente el 80% de los efectos se
deben al 20% de las causas. Por ejemplo, podríamos encontrar que el 20% de los
clientes representan el 80% de las ventas, y el 20% de nuestro tiempo produce el 80%
de los resultados.

Este principio es una regla particularmente útil para lograr un crecimiento en la

productividad sin modificar demasiado los recursos utilizados. Dado que si podemos
enfocarnos en el 20% de esfuerzo que produce el 80% tendremos margen para
incrementarlos sin aumentar considerablemente los recursos utilizados. Incluso, de
acuerdo a los estudios de Perry Marshall1 se llegó a la conclusión que el principio
aplica de manera exponencial, siendo la regla del 80/20 continúa, o sea, el 20% más
valioso del 20% más valioso (4% del total) representa el 64% del resultado (80% del
80%) y así sucesivamente.

Esta herramienta, usada con inteligencia, nos permite saber cómo enfocar nuestros
recursos para maximizar el resultado. El descubrir ese 20% prioritario debe ser
trabajado con el equipo, especialmente con los poseedores de conocimiento del
negocio y contexto para hallarlo y tomar las decisiones correspondientes para
adaptarnos a esas necesidades y priorizar acorde a esto la evolución de nuestro
producto.

A nivel gestión del producto se debe contar con la información del grupo que
representa el 80% de nuestros consumidores. Para que podamos saber cómo priorizar
y/o qué hipótesis validar con la intención de obtener resultados lo antes posible.

1 Libro: 80/20 Sales & Marketing, Autor: Perry Marshall.

 2

2 Imagen: Libro "El principio de Pareto", Economía y Empresa,

4. Observación Directa e Indirecta
La investigación o Research es el poder obtener información para la toma de
decisiones. Orientado a UX, Experiencia de Usuario, esto es crítico para entender el
contexto, los usuarios, la problemática o el desafío a resolver.
El tiempo para dedicar es un factor clave, ya que es el dinero invertido en la
investigación y también el costo de oportunidad. Si se descubre algo tarde se puede
perder la oportunidad de ser el primero y hacer una diferencia con el producto o
característica a desarrollar.
Que incluye la investigación:
● Reunirse con varios usuarios.
● Reunirse con potenciales usuarios target.
● Tiempo requerido para el reclutamiento de usuarios.
● Organización, calendarios, viajes, reservas de salas.
● Tiempo de inactividad entre sesiones de investigación (esto suele ser en
ocasiones la mitad del tiempo).
● Registro de datos.
● Resumen de datos.
● Análisis de los datos.
● Informes a las partes interesadas.

Dentro de los tipos de investigaciones existen dos tipos principales:

Cualitativo: este reúne datos en base a la observación directa y buscan entender el
porqué de las cosas o cómo suceden. Con estos se entiende el propósito de las cosas
y porque suceden. También se detectan incoherencias del hacer y del decir.
Cuantitativo: recolectan información en forma indirecta por medio de:
● Encuestas
● Análisis
● Registros de datos (todas las técnicas para conocer el comportamiento)
Estas dan respuestas a las preguntas ¿Qué..? y ¿Cuántos..?. Son muy útiles para dar
prioridad a un tema.
Su orden de ejecución es primero las cualitativas y luego las cuantitativas. Pero esto
no quita que pueda haber un ida y vuelta entre ambas si suceden situaciones no
esperadas o no comprendidas.

Revisión de Expertos
Si no posee un experto en UX en el equipo, puede ser contratado en ciertas ocasiones
importantes. Este analizará la interfaz de usuario, y la experiencia de acuerdo con
los objetivos que se buscan. La revisión con expertos, si nunca las han realizado verán
que aportan gran valor, a un costo bajo y en poco tiempo.

Prueba de Usuarios a distancia

Es una manera de disminuir los costos. Para esto por medio de un grupo de usuarios
se prueba el producto (digital o se envía por correo). Para los casos digitales, hay
varias aplicaciones (por ejemplo inVisionApp), que pueden hacer que los usuarios
prueben el producto desde su Smartphone mientras se graba la sesión, viendo sus
rostros y escuchando sus voces.

Crowdsourcing (Colaboración masiva)

Por medio de las redes sociales (Facebook, Instagram, Linkedin, Twitter,etc) se
puede conseguir gran cantidad de usuarios para obtener su opinión. La idea es hacer
llegar el producto o prototipo a una gran cantidad de personas para obtener un
feedback. La contra que tienen estas pruebas es que los usuarios que participan no
son seleccionados. Esto está pensado para productos digitales.
5. Funnel de Ventas
Funnel de Ventas o también llamado embudo de ventas, o embudo de conversión es
un sistema diseñado para atraer a potenciales clientes (leads) y convertirlos en
clientes.

Esta es una herramienta de marketing clave para ventas digitales. Por este motivo
vemos necesario que todo PM debiese tener idea de que se trata mínimamente. En
algunos roles específicos, el PM puede ser responsable además del producto del
Funnel de Ventas por el impacto directo que tiene en su producto. Un ejemplo real
en la venta de tickets de Teatro, varios teatros terciaria sus funnels, otra empresa
se encarga de hacer las publicidades para captar clientes hasta vender la entrada.
En el rubro automotriz, la empresa Toyota, además de desarrollar sus productos,
autos, se encargan de la venta de estos por medio publicidades de captación y en su
página web tiene todo lo necesario para reservar un auto y venderlo. Repito, no
todos los PMs manejan sus flujos de venta pero sí deben entenderlos, porque dan
mucho feedback sobre cómo ven su producto los clientes. También hay una relación
entre Marketing y Producto. No importa lo excelente que sea la estrategia de
Marketing si el producto no es el adecuado para nadie, no se va a vender.

Un dato a tener en cuenta es que la mayoría de los compradores comienzan su

investigación en un motor de búsqueda, Google. También la mayoría lee, se informa
sobre el producto antes de comprar en la web. Los embudos de ventas surgen para
aprovechar este comportamiento del consumidor.

Las fases de un embudo son el viaje del comprador hasta realizar la compra.

1. Conciencia: el comprador se da cuenta de que tiene un problema o necesidad

que resolver.
2. Interés: el comprador quiere entender más sobre su problema. Ya empieza a
buscar posibles soluciones.
3. Consideración: el comprador empieza a comparar diferentes soluciones del
mercado para ver cuál le es más conveniente.
4. Conversión: el comprador quiere adquirir un producto.

Cada una de las etapas tiene sus indicadores para entender qué está sucediendo
en cada una. Por ejemplo:

Venta de Toyota Corolla

 Por medio de avisos publicitarios en Google, por campañas en TV para dar a
conocer el auto y otros medios se logran que diariamente lleguen 1.000 personas
a la página web del Toyota Corolla.

Vamos a usar un usuario Target llamado Pedro para el ejemplo.

1. Conciencia: Pedro se da cuenta que al no querer contagiarse de coronavirus,

u otras enfermedades, no quiere viajar más en medios públicos.
2. Interés: Pedro empieza a investigar sobre autos, y su seguridad para viajes en
autopista (videos de youtube y paginas especializadas)
3. Consideración: Pedro se da cuenta que necesita un auto seguro, y empieza
a ver que uno de los autos más seguros dentro de su presupuesto es el Toyota
Corolla.
4. Conversión: decide aprovechar la oferta del plan de pago en cuotas del
Toyota Corolla convencido de que es la solución correcta para él.

Pedro es un ejemplo feliz de un cliente, que representa a muchos. Digo “feliz”

refiriéndose a que completo todo el embudo de ventas. No todos los clientes
completarán este embudo. En cada una de las etapas se tendrán distintos indicadores
para entender, por ejemplo, cuánta gente ve el video completo de explicación de
las cualidades del auto. Cuántas de las que ven el video completo hace clic al final
para ir a la página de ventas. De las que llegan a la página de ventas, cuántas hacen
clic en ver especificaciones y cuántas de estas hacen clic en comprar. Luego le
interesará saber cuántos concretaron la compra.

Ejemplo:

1. 1.000 personas llegan a la página de Toyota diariamente. < ¿Está bien? ¿Es
poco? ¿Qué hacer para que llegue más? ¿Por qué lo eligieron?>
2. 600 Hacen clic en Corolla detalles. < ¿Cuál es la expectativa? ¿Por qué lo
eligieron?>
3. 100 Hacen clic en comprar < ¿Qué fue los que los tentó?>
4. 20 iniciar a completar sus datos < ¿Qué pasó con los que no
completaron?>
5. 10 la concretan < ¿Qué pasó con los que no compraron, que los freno?>
6. MVP y MVF
En la actualidad es difícil conocer un equipo de producto que no conozca este
término, aunque posiblemente sea uno de los peor utilizados. La definición más
formal de un producto mínimo viable (MVP por su sigla en inglés: Minimum Viable
Product) es la versión de un nuevo producto que permite al equipo obtener la máxima
cantidad de validación de aprendizaje con el menor esfuerzo. Esta definición quiero
complementar con la frase de Reid Hoffman (fundador de LinkedIn) “Si no estás
avergonzado por la primera versión de tu producto, lo lanzaste demasiado tarde”.
Esta frase facilita comprender el objetivo de un MVP, siendo una herramienta de
aprendizaje sobre las necesidades y comportamiento del usuario antes de invertir
demasiado. Como muchos autores y casos de estudio han demostrado durante los
años, ningún análisis de mercado puede ser 100% preciso, en particular cuando
hablamos del lanzamiento de un nuevo producto. De esta manera podemos validar
(o invalidar) hipótesis a través de pruebas directas con el usuario. Estos prototipos
generados deben hacer foco en la validación no en el crecimiento, esto puede ser
un poco anti intuitivo ya que se puede creer que es necesariamente el mismo
producto que sigue escalando. De ahí surge la propuesta de Steve Cohn de utilizar el
término Experimento Mínimo Viable (MVE por su sigla en inglés), ya que es un
experimento para aprender del usuario más que un producto a vender.

En pocas palabras, el foco del MVP es el de validar la hipótesis de valor al usuario,

no tratar de incorporar la mayor cantidad de funcionalidades. A continuación,
podemos ver errores comunes comparados con el enfoque correcto:

TERRIBLE MALO BIEN UN MVP REAL

Valor Valor Valor Valor

Beneficios Beneficios Beneficios Beneficios

Funcionalidades Funcionalidades Funcionalidades Funcionalidades

Cuando nos preguntamos: Cuando nos preguntamos Cuando nos preguntamos: Cuando nos preguntamos
"¿Qué funcionalidades "¿Cuáles son las mínimas ¿Que versión puedo construir? "¿Cómo puedo validar mi
podemos construir?" funcionalidades para ¿Qué captura la mayor parte proposición de valor?"
brindar algo de valor?" del valor?
En resumen, un MVP debe cumplir con las siguientes reglas:

● Sirve para validar o no una hipótesis sobre el producto.

● Sirve al menos a una audiencia.
● Hace foco en al menos un problema de la audiencia.
● Brinda una experiencia usuario distinta.
● Es construido y puesto en el mercado en un plazo corto.

Un MVF, es un Minimum Viable Feature, es la Característica Mínima Viable. Es muy

similar a un MVP, la única diferencia que ya hay un producto existente y lo nuevo es
una característica en el producto.
7. Lean Startup
Un Startup es una nueva organización que busca ser innovadora. Estas organizaciones
se caracterizan por su altísimo riesgo de no perdurar. Son emprendimientos de gran
incertidumbre. La mayoría fracasan por no encontrar el camino rápidamente.
Algunos emprendimientos fracasan mucho más tarde por no tener “brújula
organizacional”, o porque su brújula no marca bien el norte. Generando esto
impactos muy muy negativos en sus inversionistas y también en la posibilidad de
corregir el rumbo y ser exitosos.

¿Qué es Lean Startup? Es un marco de trabajo para la generación de Startups o áreas

que comienzan normalmente desde cero.

¿Cuándo se utiliza? Originalmente este marco de trabajo se desarrolló para generar

una organización emergente, una Startup, con el menor riesgo posible, logrando dar
valor al cliente, obtener ganancia y de una forma efectiva y eficiente. Luego, la
mentalidad que hay detrás de Lean Startup, se utilizó para productos o servicios
innovadores, dentro de organizaciones ya asentadas.

Este marco de trabajo está basado en Lean, marco de trabajo surgido en Japón,
usado en Toyota, para optimizar el flujo de trabajo de la cadena de desarrollo, y en
toda la fábrica.

Objetivo: Cómo, con la mínima inversión y en el mínimo tiempo, generar un startup

que se sostenga, focalizado en aprender del mercado.

¿Para qué se incluye Lean Startup en el temario? No para enseñar a generar un

Startup, sino porque en el contexto actual, es valioso adoptar las capacidades de
adaptabilidad de una Startup en cualquier organización.

“Debido al nivel de incertidumbre ocasionado por la era digital, hoy, toda

organización debe ser tratada como un Startup y cada empleado debe comportarse
como un emprendedor”

Los 3 grandes focos metodológicos de Lean Startup son Crear-Medir-Aprender.

Cada cosa para crear será parte de una estrategia de ampliar el aprendizaje, el
negocio y crecer a la máxima velocidad. Buscar cómo crear un negocio sostenible a
partir de esa visión.

El aprendizaje se basa en datos tomados de consumidores reales y significativos.

Evitar suposiciones y datos vanidosos.
PASO 1: CREAR

El objetivo es crear un MVP, “Producto Mínimo Viable” (por sus siglas en inglés), que
responda estas dos hipótesis:

● Hipótesis de valor: la hipótesis de valor debe ser una suposición basada en

estas preguntas ¿aporta valor a los usuarios?, ¿lo utilizarían?, ¿lo comprarían?
● Hipótesis de Crecimiento: ¿se puede escalar en nuestro sector de clientes?
¿Hay suficientes clientes en el mercado?

El producto mínimo viable (MVP) sirve para validar estas dos hipótesis. Cualquier otro
fin que tenga, es un desperdicio de tiempo y dinero. La calidad no es el foco.

Técnicas:

a. Prueba de humo: vender el producto sin haberlo fabricado, sólo con elementos de
marketing.

b. MVP en un video: contar los detalles del producto en un video explicativo para
tomar la opinión de los clientes sin haber construido ningún producto. Esto lo suele
utilizar Samsung para sus celulares.

c. Mago de Oz: ofreces un producto que parece el real, pero detrás hay una persona,
haciendo lo que debería hacer el producto. Ejemplo real: Buscar a los clientes que
hicieron una compra todos los meses, y enviar un mail el mes que no compró con
ofertas. Luego buscar si hizo una compra dentro de los 10 días. Todo esto a mano,
pero a futuro seria todo automático con un programa.

PASO 2: MEDIR

Establecer un punto de partida:

Para medir el crecimiento podría utilizarse tasas de conversión de clientes, tasas de

suscripción y de prueba.

Para entender si da valor, medir las reacciones del consumidor ante el producto,
determinar qué precio pagarían, y medir cuál es su satisfacción.

Ambas hipótesis deben tener preguntas claras, para lo cual se deben poder medir.
Esta será la brújula del startup. Aquí se debe orientar a hacer todo en base a las dos
hipótesis. Esto es la fijación de indicadores claros, limitados y mejorados.
Indicadores Vanidosos: parece que mejora, pero no. Ejemplo, si entran más clientes
a la tienda (vanidoso), pero no se vende más.

Indicadores Accionables: Si impactan en crecimiento o valor.

PASO 3: APRENDER

¿Estamos progresando o debemos pivotar?

Pivotar: es un cambio en la hipótesis del producto que teníamos.

Catálogo de Pivotes:

Pivote de segmento de consumidores

Cambio en el target de consumidor de B2B (Business-to-Business) a B2c (Business-to-

Consumer) o viceversa.

Pivote de necesidad de consumidor

Cuando la necesidad que resuelve el producto no es lo suficientemente importante para

nuestro consumidor, hay que buscar otra.

Pivote de acercamiento (Zoom In)

Una funcionalidad concreta se convierte en el producto en sí.

Pivote de alejamiento (Zoom Out)

Lo opuesto al Zoom in, necesitamos ampliar el grado de funcionalidades a ofrecer en

nuestro producto.

Pivote de arquitectura de negocio

Cambiar de negocio con alto margen de beneficio y bajo volumen de ventas a Bajo
Margen y alto volumen, o viceversa.

Pivote de captura de valor

Cambio en el modelo de negocio.

 Pivote de motor de crecimiento

Cambio en el proceso de adquisición de nuevos usuarios / consumidores.

Hay tres tipos:
Motor de crecimiento viral: Crecer a través de nuestros propios usuarios.
Motor de crecimiento Pegajoso: Crecer reteniendo usuarios.
Motor de crecimiento Remunerado: Crecer pagando.

Pivote de canal

Cambio en el canal de distribución.

Pivote de Tecnología

Cambio en la infraestructura tecnológica de la organización, sólo recomendable para

organizaciones consolidadas.

Sin una hipótesis clara no se puede percibir el fracaso. Y el fracaso es necesario

percibirlo para poder hacer un cambio de dirección, en vez de seguir una ruta muerta
sin saberlo.
8. Lean UX
La experiencia del usuario con el producto es una materia de estudio en sí misma.
Existen múltiples herramientas para investigar y diseñar una experiencia de usuario
(UX) satisfactoria, el desafío está en no separar esta parte del proceso de la
construcción en sí misma. Para eso tenemos el llamado Lean UX3 .

Lean UX se asienta en tres pilares:

● Design Thinking: centrado en las soluciones a las necesidades de los usuarios

que, reitera una y otra vez perfeccionando el producto en cada iteración. Es
una manera de trabajar que alienta la colaboración en el equipo y considera
el producto desde una perspectiva holística y abarcadora.
● Marcos de trabajo agiles: que tratan de entregar de forma rápida y regular
valor a los clientes y aprovechar el aprendizaje que se obtiene de estas
entregas para ajustar el producto.
● Método Lean Startup: que utiliza un ciclo de feedback denominado "crear-
medir-aprender" y una filosofía que se aplica directamente al diseño de
productos en Lean UX.

Los principios en los que se basa Lean UX son:

● Equipos multifuncionales para evitar el desarrollo en cascada (proceso big

bang de desarrollo, se diseña todo, luego se desarrolla todo, se testea todo y
se implementa todo…no van bien con entorno complejos)..
● Equipos pequeños, dedicados, co-ubicados para fomentar la comunicación y
concentración; pero como no siempre es posible, también hay opciones
virtuales.
● Progreso igual a resultados, no a entregas de documentación.
● Equipos centrados en los problemas.
● Eliminación del desperdicio, es decir, de todo aquello que no contribuye a
conseguir el objetivo final.
● Batches o Lotes pequeños, evitar crear muchas ideas de diseño sin probar ni
implementar alguna.
● Descubrimiento continuo de lo que los usuarios están haciendo con nuestro
producto y por qué lo están haciendo.

3 Lean UX: Applying Lean Principles to Improve User Experience. Autores: Jeff Gothelf and Josh Seiden
 ● GOOB (Getting Out Of the Building), porque el éxito o el fracaso de nuestros
productos no depende de las decisiones del equipo de desarrollo, sino de los
usuarios.
● Entendimiento común, es decir, el conocimiento colectivo del equipo sobre el
producto y los usuarios.
● Evitar las estrellas, gurús y ninjas que rompen la cohesión del grupo y reducen
la colaboración.
● Exteriorización del trabajo, es decir, exponer el trabajo a compañeros,
colegas y clientes.
● Hacer en lugar de analizar.
● Aprendizaje en lugar de crecimiento: asegurarnos de que una idea funciona
antes de hacerla crecer.
● Permiso para equivocarse, porque los fallos conducen al perfeccionamiento.
● Escapar de los negocios basados en entregables.

Proceso

Proceso Lean UX. Fuente: Lean UX, Jeff Gothelf, 2013

Visión, macro y resultados

Reorganizar el trabajo del equipo para que se centre en obtener resultados (no en
desarrollar funciones), y en el proceso de declaración de resultados.

Se sustituyen los requerimientos por suposiciones, y a partir de ellas creamos y

probamos hipótesis. La herramienta básica es por tanto la declaración de hipótesis,
que tiene como elementos básicos: las suposiciones, los resultados, los personajes y
las funciones.
Comenzamos con la declaración del problema, después examinamos las suposiciones
implícitas en él y las transformamos en hipótesis. Explica cómo escribir las
declaraciones para que se capten las funciones, la audiencia y los objetivos previstos,
suficientemente específicos para poder probarlos; y proporciona ejemplos y
plantillas.

La creación de personas se realiza en pocas horas, en una sesión de brainstorming en

la que participa todo el equipo y a medida que la investigación avanza y se aprende
más sobre los usuarios, se va ajustando la definición.
9. Testing A/B
También denominada en algunas bibliografías como split testing o bucket testing,
consiste en comparar dos versiones de un mismo producto para determinar cuál tiene
un mejor desempeño para ciertas características. Esto permite hacer experimentos
donde 2 o más alternativas son otorgadas al azar a los usuarios para analizar los
resultados con herramientas analíticas y sacar conclusiones de acuerdo a cómo se
comportan. El uso más clásico es en los e-commerce para aumentar la conversión o
mejorar alguna otra métrica, las cuales se controlan por ejemplo con Google
Analytics y se les puede dar un seguimiento por una cantidad de horas o días y en
consecuencia avanzar con el cambio y seguir iterando para encontrar una versión
mejor o descartar la idea.

Esta manera de validar los cambios elimina los supuestos para tomar decisiones de
optimización orientadas por datos (data-driven) y permite debatir en torno a ellos y
asegurarnos que los cambios que se realicen tengan un impacto positivo al expandirse
a toda la población de usuarios.

Uno de los ejemplos más comunes es agregar un botón en una página web, en la
página de “Control” está en una posición y en la de “Variación” en otra. Luego de
un día ya se pueden ver resultados. La cantidad de personas que hicieron clics en
cada botón. Esto ayuda a decidir cuál es la mejor ubicación para que lo vean los
usuarios.

4 Imagen: Optimizely.
 Algunos recomiendan no implementar múltiples A/B test sobre las
mismas operaciones, en la práctica esto no es una restricción
completamente mientras se pueda identificar con claridad cada resultado.

Implementación Azul-Verde (Blue-Green deployment)

La implementación en el ambiente productivo es uno de los grandes hitos por lo que

pasa todo nuevo desarrollo. En los casos de estar tocando un producto operativo
puede agregar la complejidad de necesitar reducir al mínimo el tiempo en que no
está disponible para los usuarios. Considerando que muchas aplicaciones se esperan
funcionen 24x7 esto lo vuelve un problema de difícil solución.

La implementación Azul-verde busca solucionar este problema teniendo dos

ambientes de las mismas características que intercambian el rol productivo. Para
pensarlo con un ejemplo, podría verse que en un momento el llamado ambiente
“Azul” está funcionando en producción y la nueva versión en la que estamos
trabajando por un nuevo release es el “Verde”, una vez decididos a disponibilizar la
versión a los usuarios se realiza el cambio para que las nuevas solicitudes sean
redireccionadas a este ambiente pasando a ser el productivo y el “Azul” pasará a
quedar ocioso. Si bien no se reduce a cero el tiempo de indisponibilidad por el tiempo
que puede tomar la configuración del re direccionamiento, este queda
extremadamente reducido.

Como puede resultar obvio esto nos deja una posibilidad muy simple para realizar
una vuelta atrás (rollback) en caso de problemas con la nueva versión. En algunos
casos incluso se dejan espejados momentáneamente para eliminar posibilidad de
pérdidas y/o agilizar el rollback.
 5

Una vez que se está conforme con la nueva versión, se disponibiliza la nueva versión
productiva en el otro ambiente y queda disponible para ser utilizado como ambiente
pre productivo para poder realizar en el próximo release el mismo proceso de cambio
de “Verde” a “Azul”.

La realización de este ciclo de cambio constante entre ambiente productivo y pre

productivo tiene como ventaja el mantener aceitado el proceso de recuperación de
ambientes en caso de problemas, algo que si bien muchos tienen un ambiente pre
productivo suelen no practicar este método de manera periódica.

La manera de implementarlo varía en las organizaciones (hablando principalmente

de productos de software), si bien la implementación más completa es utilizar
entornos completamente independientes, (base de datos, hardware, etc.) que se re
direccionan desde el DNS. Algunos tienen versiones intermedias como utilizar la
misma base de datos (dependiendo de la magnitud del cambio esta opción puede no
ser viable en algunas ocasiones), realizar el re direccionamiento desde el webserver,
tener instancias en el mismo servidor, etc.

Esta práctica es particularmente utilizada en ambientes de entrega continua

(continuous delivery) y con la disponibilidad de la tecnología actual (servidores en la
nube, procesos automáticos de deploy, etc) se simplifica su uso.

5 Fuente de la Imagen: Martin Fowler.

10. Canary Release & Rolling Deployment
Canary Release o también llamado Canary Deployment, esta técnica de
implementación busca reducir el riesgo en la implementación de nuevas versiones
de producto a través de una implementación acotada a un pequeño grupo de usuarios
que nos sirva para comprobar el correcto funcionamiento. Luego progresivamente
incorporar segmentos mayores hasta la implementación total.

Similar a la implementación Azul/Verde se comienza a "deployar" la nueva versión

en una parte de la infraestructura en donde no se direccionan usuarios.

Este tipo de implementación es muy común aunque no se la llame de esta manera

en todas las organizaciones. La selección de los primeros usuarios de prueba puede
ser variada, comúnmente se selecciona un grupo de usuarios internos, los cuales
pueden ser empleados y conocidos de ellos que están al tanto de los cambios y
reportan en detalle el comportamiento, otros optan por un público al azar y evaluar
los datos que ellos generan, así como también puede optarse por segmentos
regionales, demográficos, etc.

Este tipo de implementación facilita el obtener validación en entorno productivo del

comportamiento de la nueva versión con métricas y datos de los usuarios,
manteniendo la posibilidad de deshacer los cambios (rollback) muy fácilmente.

Un ejemplo muy conocido que utiliza este método de implementación es Facebook,

haciendo visibles los cambios a usuarios internos manteniendo activas todas las
aplicaciones de medición para evaluar el comportamiento.

A diferencia de la implantación de tipo Azul-Verde, en este caso no requerimos dos

ambientes espejados para hacer de producción y preproducción alternativamente,
lo cual evita esta redundancia y costo a través del uso de la misma infraestructura.

Con el A/B testing buscamos validar hipótesis para realizar cambios, mientras que
con la implementación de Canary Release ya hicimos el cambio y estamos probando
la estabilidad en producción y poder deshacerlo fácilmente.

Implementación progresiva (Rolling deployment)

En este tipo de implementaciones no tenemos ambientes replicados, sino que el
ambiente productivo está compuesto por nodos o instancias más chicas que lo
conforman y se reparten la carga (es muy común que las empresas tengan estos
equipos conectados un balanceador de carga para distribuirla de manera equitativa),
entonces al momento de implementar una nueva versión, se lo va realizando
progresivamente de un servidor a la vez, pudiendo evaluar el comportamiento a
medida que se incorporan nuevos nodos.

Este método permite un rollback, una vuelta atrás muy simple ya que es dejar de
usar momentáneamente los nodos con la nueva versión e instalar de nuevo en ellos
la anterior. Como contra los cambios que haya en la base de datos no son fáciles de
revertir, por esto se recomienda evitarlos de ser posible.
11. Concierge
O también conocida como conserje, es una técnica de experimentación para validar
hipótesis sobre una solución todavía no desarrollada. Se basa en crear una
experiencia temporal para entregar valor al usuario de forma manual. Con personas
como “motor” en vez de usar tecnología.

Esta técnica es:

● Es muy popular por su bajo costo

● El tiempo puesto en funcionamiento es relativamente bajo o medio
● El nivel de evidencia que entrega es muy certero
● El tiempo de ejecutarla no es mucho
● Es ideal para entender el valor de un nuevo producto característica
● No sirve para analizar el impacto de escalar una solución a muchos más
usuarios.

Preparación, Ejecución y Testeo de la Hipótesis:

● Planificar el periodo de experimentación

● Planificar cómo resolver el producto manualmente
● Planificar cómo recolectar los datos del experimento
● Planificar a cuantos usuarios va a impactar el experimento
● Planificar cómo seguir hacer un cambio temporal en el circuito de trabajo
habitual
● Planificar cómo revertir los cambios hechos.
● Ejecutar el experimento, llevar a cabo las corridas manuales mientras se toma
datos relevantes.
● Durante la ejecución revisar los datos para ver si hay alguna condición que
surja e implique un ajuste del experimento o la suspensión de este.
● Realizar entrevista a los usuarios y a las personas que participaron del proceso
para obtener información cualitativa.
● Al finalizar el periodo de experimentación analizar los datos, definir si la
hipótesis es válida o inválida, y como continuar.
● Hacer una retrospectiva para mejorar la forma de realizar Concierge.
Les vamos a presentar un caso real de aplicación de Concierge

Situación Real: Se tenía información que muchos usuarios de tarjeta de crédito

perdían la tarjeta y luego la volvían a encontrar. Pero mientras la tenían perdida por
las dudas avisaban a su entidad emisora (Visa/Mastercard/otras) y la daban de baja
para prevenirse por si alguien se la había robado. Luego de esta baja, se generaba
un costo a la empresa que realizaba una impresión de tarjeta y un nuevo envío de la
tarjeta. Para el usuario era una incomodidad porque se quedaba temporalmente sin
tarjeta.

Solución definitiva: permitir que se bloquee la tarjeta temporalmente, y luego que

el usuario la pueda desbloquear. Esto por medio de su aplicación bancaria.

Uso de Concierge: Para evitar hacer esta construcción tecnológica costosa, sin la
certeza de que va a aportar valor a la empresa y el cliente, se definió dar a un grupo
limitado de personas la posibilidad de bloquear la tarjeta por teléfono y luego volver
a llamar para desbloquearla si la encontraban. Esto no era un bloqueo o baja real,
sino que, se marcaba la tarjeta para chequeo de datos, es un proceso que cuando
alguien quiere hacer una compra se le pide una serie de datos personales para
comprobar la identidad. Con esto evitaban que hiciera una compra alguien que no
fuera el titular. En base a esto anotaba cuantas personas de las que bloquearon la
tarjeta encontraban la tarjeta y volvían a llamar para desbloquearla, o después de
72hs se avisaba y si no la encontraban se daban de baja. Este experimento tuvo el
resultado que un 35% de los usuarios encontraban la tarjeta en menos de 48hs. Con
esta validación de la hipótesis, y con menos incertidumbre, esto justificó a hacer
esta característica del producto tarjeta, que fue un desarrollo hace varios meses.
12. Mystery Shopper
El MS o Cliente Misterioso, es una técnica para entender cuál es la experiencia de
usuario actual. Esta se puede usar para entender las problemáticas en forma
cualitativa, viviendo el proceso de punta a punta.

Objetivo: detectar los puntos fuertes y débiles de un servicio (producto) u

organización desde el punto de vista de los usuarios.

¿Cómo funciona?

Una persona o un grupo de personas, mide el rendimiento de un servicio, llegando a

la empresa como un cliente más. Desde este lugar evalúa la calidad del servicio, sin
nunca decir que está haciendo una investigación. El que el MS sea descubierto altera
las siguientes mediciones. La gracia está en que lo traten como un cliente más.

¿Beneficios?

● Permite evaluar la calidad de un servicio, producto o empresa

● Sirve para evaluar la competencia
● Sirve para benchmarking
● Detecta oportunidades de mejora
● Verifica el cumplimiento de procesos y pautas de atención.

¿Cuándo usarlo?

● Para comprender el contexto

● Para comprar con la competencia
● Luego de la implementación de un servicio
● Para conocer los usuarios target en su medio
● Para conocer el problema a resolver de cerca
● Para ver lo que los usuarios no reclaman, pero hay oportunidad de mejora
● Para comparar su solución con las de la competencia
¿Cuándo no usarlo?
● Cuando no tengo idea del problema, el hacer esto ayudará a detectar
problemas, pero tal vez el investigador no sea el usuario target y no detecte
los mismos problemas. Si lo utiliza después de entrevistas a usuarios, les
servirá para entender más lo recolectado en las entrevistas
● Para pensar ideas directamente desde lo que tiene la competencia, primero
entender la problemática, el copiar sin entender puede ser un gran
desperdicio

Esta técnica requiere poco esfuerzo, rápida, muy efectiva para conocer un servicio.

Un caso real, se suele usar esta técnica en locales, que dan servicios idénticos en
distintas sucursales para entender el estándar del servicio actual. Empresas que
suele usarlo: Carrefour, Mac Donalds, Los Bancos, las Fintechs, entre otras.

Otro caso muy interesante es cuando uno inicia como Product Manager, puede hacer
una recorrida para la competencia simplemente para saber cómo es el mercado
nuevo que está ingresando.

Damos por descontado que hizo esto para conocer su producto.

El conocimiento de los canales de distribución del producto, también hacen a la

experiencia del producto. Un excelente producto puede ser un fracaso
exclusivamente por sus canales de venta o distribución.

En productos digitales también se puede utilizar en los canales alternativos “realizar

un reclamo”, analizar el tiempo de respuesta y las respuestas.
13. Feature Stub
Es una técnica para averiguar qué interés hay de los usuarios sobre una nueva
característica. Imagínese que quieren saber rápidamente y a muy bajo costo si los
usuario usarían tal funcionalidad. Si se realiza de la forma tradicional esta respuesta
se tendrá luego de haber hecho todo el desarrollo y se verá después cuántos usuarios
usan esta funcionalidad. La gran contra de esta hacerlo del método tradicional es
que hay muchas situaciones, que pese a haber entendido la necesidad, simplemente
los usuarios ni siquiera hacen click en la nueva funcionalidad. Y esto implica en
muchos casos miles o millones tirados a la basura. Además de tirar a la basura mucho
tiempo que podría haber sido utilizado para algo útil.

Una de las implementaciones más simple de estos es agregar un botón o un link a la

nueva funcionalidad antes de que ésta fuera desarrollada. Se estará pensando qué
pasa luego del click… esto son las posibilidades:

● Avisar que no está disponible por el momento la característica.

● Dar un mensaje de error ( no recomendada por nosotros, pero se usa)

● Avisar que participó un censo de interés sobre la funcionalidad, que le avisaran

si esta es desarrollada.

● Otras variantes

Las cualidades de esto son:

● Mínimo esfuerzo a desarrollar

● Muy económico

● Fuerte evidencia de interés de los usuarios

● Poco tiempo de ejecución.

● Poco tiempo de preparación

Los puntos a tener en cuenta para esto son:

 ● Poder medir la cantidad de usuarios que hacen click

● Entender que tipos de usuarios hicieron clic y cuáles no. Esto para saber si los
usuarios interesados son los usuarios target.

● Preferentemente definir un grupo de usuarios para hacer el experimento

● Definir un tiempo para el experimento.

● Avisar a los sectores de soporte por si hay reclamos debido a esto.

● Medir la satisfacción de los que participaron en el experimento, cómo les

impactó.

● Otra opción en el mensaje posterior al click, sumar contenido útil de cómo

resolver hoy su necesidad

● Opcional, dar algún tipo de gratificación por su participación

● Opcional, invitarlo a participar del piloto de funcionalidad en el caso que se

realice

Algunas de los riesgos a tener en cuenta sobre su implementación

● No usar esto sobre una funcionalidad existente

● Medir el impacto que genera el mensaje de respuesta luego de tocar el botón,

para evitar una mala experiencia por esto

● Confundir lo deseable que es la característica nueva con la certeza del éxito

de la solución a implementar. Una solución puede ser muy deseada pero si su
implementación, su ejecución, si la calidad del producto no es la esperada se
puede dejar de utilizar en el momento. Por eso, que sea deseada nos es
suficiente para el éxito.

● Si el producto actualmente en esa zona no tiene usuarios activos, tampoco lo

tendrá la característica nueva. Esto es primordial.

● Un riesgo común es abusar de esto y tener una aplicación que lleve a todos
lugares sin característica detrás. Los usuarios tomarán esto como una mala
experiencia y generaría un efecto negativo en otras características, en todo
el producto o en la marca en general.
Caso real ventas: Para realizar nuevos productos varias empresas usan esta
estrategia antes de desarrollarlos o comercializarlos. Si detectan un interés del
público por este producto o servicio buscan lo necesario para tenerlo o brindarlo.

Caso real aplicación: Para detectar las necesidades de usuarios internos sobre una
funcionalidad, utilizan esto internamente para cuantos usuarios hacen click en
esto. Esta información la utilizan para priorizar los productos a realizar.
14. Conclusiones
Hay muchas herramientas, marcos de trabajo y técnicas. Ninguna de estas es de
valor sin tener la claridad de qué es lo importante en el momento de desarrollo
de producto en que se encuentra. Antes de utilizar una de estas, tenga claridad
respecto del propósito que tiene, si agrega algo que no sabe. para qué es, o si
sólo aumenta la burocracia.
Bibliografía utilizada y sugerida
Libros y otros manuscritos:
● Cagan, M. (2017). INSPIRED. Wiley.

● Gothelf, J., & Seiden, J. (2017). Sense and Respond. Reed Business
Education.

● Humble, J., Molesky, J., & O’Reilly, B. (2014). Lean Enterprise. Van Duuren
Media.

● Seiden, J. (2019). Outcomes Over Output. Independently Published.

● Perri, M. (2018). Escaping the Build Trap. Van Duuren Media.

● Banfield, R., Eriksson, M., & Walkingshaw, N. (2017). Product Leadership.

Van Duuren Media.

● Pichler, R. (2016). Strategize. Pichler Consulting.

● Blank, S. (2020). The Four Steps to the Epiphany. Wiley.

● Gothelf, J., & Seiden, J. (2013). Lean UX. Van Duuren Media.

● Olsen, D. (2015). The Lean Product Playbook. Wiley.

● Pichler, R. (2010). Agile Product Management with Scrum. Addison-Wesley.

● Doerr, J., & Page, L. (2018). Measure What Matters. Van Haren Publishing.
● Ries, E. (2011). The Lean Startup. Crown.

● Patton, J., & Economy, P. (2014). User Story Mapping. O’Reilly.

● Cohn, M. (2004). User Stories Applied. Addison-Wesley.

● Wodtke, C. R. (2015). Radical Focus. Van Duuren Media.