Módulo 3: Flujo de trabajo de un proyecto Data Science
Lección 1: Metodología CRISP (CRISP – DM)
Los proyectos de análisis de datos hoy día también llamados proyectos de Data Science o Data
Analytics existen desde la década de los 90, época en que ya se buscaba encontrar
conocimiento a partir de los datos (Knowledge Discovery in Databases).
Este proceso de búsqueda de conocimiento a partir de los datos se fue normalizando en el
tiempo, hasta estandarizarse en etapas concretas que deben estar presente en todo proceso de
este tipo.
A continuación, profundizaremos respecto de las etapas del flujo de trabajo que plantea la
metodología CRISP – DM.
Pero, ¿qué es la metodología CRISP- DM?
La metodología CRISP-DM (Cross-Industry Standard Process for Data Mining o Proceso
estándar entre industrias para la minería de datos) es una metodología que plantea un proceso
secuencial y cíclico que se ha ido probando en el tiempo para orientar los trabajos de minería
de datos.
El flujo de trabajo que plantea esta metodología se encuentra compuesto de cinco etapas.
La metodología de CRISP-DM es flexible y se puede personalizar fácilmente. La secuencia de
las fases no es rígida: se permite movimiento hacia adelante y hacia atrás entre diferentes fases.
Las flechas indican las dependencias más importantes y frecuentes.
El círculo externo en la figura simboliza la naturaleza cíclica de los proyectos de análisis de
datos. El proyecto no se termina una vez que la solución se despliega. La información
descubierta durante el proceso y la solución desplegada pueden producir nuevas iteraciones del
modelo. Los procesos de análisis subsecuentes se beneficiarán de las experiencias previas.
Por ejemplo:
Si su organización intenta entender algún patrón específico sobre sus clientes, es probable que
necesite realizar un análisis de grandes cantidades de datos sin un objetivo de modelamiento
específico. En lugar de desarrollar modelos estadísticos y predictivos, su trabajo se centrará en
explorar y visualizar datos para descubrir patrones e identificar cuál puede ser la mejor estrategia
estadística para abordar el problema, dados los patrones detectados.
Sin un buen entendimiento del problema y de los datos, es muy difícil que un proyecto sea
exitoso. Muchas veces existe la tentación de partir modelando al inicio del proyecto, sin
embargo, lo más probable es que ese modelo no genere mucho valor a la empresa si es que
antes no se desarrollaron las etapas previas.
Ahora vamos a revisar cada etapa de la metodología CRISP-DM
ETAPA 1: Comprensión del negocio
En esta etapa se busca identificar, analizar y comprender el problema de negocio, lo cual es
muy importante para asegurar el éxito posterior. Puede haber muchos proyectos entretenidos
que realizar, pero debemos hacer aquel que entregue una solución y agregue valor al
proceso de negocio relacionado. Para esto, se plantean algunas preguntas que pueden
ayudar a identificar el problema u oportunidad, tales como: ¿Cuál es el dolor o molestia, la
complejidad o incomodidad del negocio que se enfrenta? o ¿Por qué se tiene que
abordar?
Luego, una vez identificado el proyecto y la oportunidad, es necesario traducirlo a un problema
de datos, en otras palabras, definir un problema de Data Science. ¿Cómo hacerlo?
1. Definir Objetivo: ¿Queremos saber cosas del pasado, presente o futuro? Es decir,
preguntarnos:
o ¿Qué ocurrió?, ¿por qué?
o ¿Qué ocurre?, ¿por qué?
o ¿Qué ocurrirá?, ¿por qué?
Dependiendo de este objetivo, el problema analítico y las técnicas utilizadas pueden ser muy
distintas, tal como se muestra en la siguiente infografía:
Veamos un ejemplo:
Supongamos que tenemos una empresa que vende productos frescos, en particular, sándwich
y platos preparados. El área de planificación de producción tiene el siguiente dilema: si se
produce mucho, lo que no se venda lamentablemente se debe desperdiciar (botar a la basura),
mientras que, si produce poco, puede quebrar stock perdiendo potenciales ventas y sus clientes
quedarán insatisfechos por no encontrar disponibilidad de productos.
Además, el jefe de planificación nos comenta que la venta depende de muchas variables y es
muy difícil anticiparse al nivel de ventas. Por ejemplo, factores que afectan son el día de la
semana, la hora, el tipo de producto, la existencia de descuentos o promociones, la estación del
año, la ocurrencia de eventos (ej. partido de Chile), la temperatura y el clima, entre otros.
Considerando lo anterior, en este caso el dolor o problema principal es la pérdida, ya sea por el
desperdicio o por los quiebres de stock y pérdida de fidelidad de clientes. Por otro lado, el equipo
de planificación necesita anticiparse a lo que ocurrirá, por lo que estamos en presencia de un
problema analítico predictivo.
2. Definir quiénes estarán involucrados en el proyecto: Con el objetivo de maximizar la
probabilidad de éxito del proyecto, es importante definir quiénes estarán involucrados en el
transcurso del proyecto.
Es muy común no incorporar a las personas que debieron estar presentes en el planteamiento
del problema, aquellas que conocen del negocio y de los datos. Las personas que en el día a
día se ven enfrentadas a este problema y que tienen mucha experiencia que podría ayudarnos
a mirar bien qué tipo de datos necesitamos y a dimensionar cuál es el verdadero problema
actual, por lo tanto, es importante considerar las áreas que se indican a continuación:
Muchas veces un proyecto puede tener buen aspecto desde el punto de vista analítico, sin
embargo, una vez desarrollado, el área técnica lo considera inviable tecnológicamente. Puede
ocurrir también que luego el área de negocios nos diga que la pregunta que responde no es tan
valiosa o que se podrían haber considerado otras variables en el modelo que al equipo analítico
no se les ocurrió. En fin, es muy importante la interacción entre estas tres áreas para
maximizar la probabilidad de éxito del proyecto.
Volviendo a nuestro ejemplo de venta de comida fresca, las personas del área de negocios
podrían indicarnos que además de las variables que consideramos, los fines de semana largos
o el final de mes, pueden ser factores importantes que un modelo debiese considerar.
3. Involucrar al usuario final de la herramienta desarrollada: Esta es una etapa crítica, pues
es necesario identificar cómo funciona la herramienta y su operación diaria, así como saber
de qué forma se puede adaptar la solución de modo que sea poco invasiva y que se pueda
incluir la herramienta en su flujo.
Finalmente, en el área de negocio, y pensando en el resultado final del proyecto, es importante
incluir a las personas que utilizarán la herramienta.
Si es que desarrollamos una herramienta muy sofisticada pero que en la práctica es muy lenta,
poco amigable o costosa de utilizar, probablemente se preferirá descartar.
Una respuesta aproximada al problema correcto vale mucho más que una respuesta exacta a
un problema aproximado (John w. Tukey, 1915- 2000, Estadístico desarrollador de la FFT,
Diagrama de la caja y bigotes.)
Lección 2. ETAPA 2: Entender/ Comprender los datos
La etapa 2 del flujo señala que una vez que ya tenemos identificado el problema de negocio,
debemos entender muy bien los datos con los que vamos a resolver el problema, para lo cual
es necesario realizar lo siguiente:
1. Identificación: Identificar la información más adecuada para resolver el problema. Si es
que se trata de entender riesgo de fraude, tal vez nos interesaría contar con historial de
fraudes, características de las personas, historias transaccionales, comportamiento de
usuarios, etc. Para el caso de predicción de demanda de productos frescos, ya
mencionamos bastantes variables como el clima, variables estacionales, etc., que
podrían ser útiles para resolver el problema.
2. Fuentes de información: ¿Desde dónde podemos obtener la información? Fuentes
internas de la empresa, fuentes externas pagadas, fuentes externas desde sitios web o
redes sociales, open data, etc. Por ejemplo, para el caso de variables climáticas, en Chile
existe información abierta a nivel de estación meteorológica que es posible descargar e
incluir en nuestros modelos. Este es el caso del sitio: meteochile.gob.cl/PortalDMC-
web/index.xhtml, en donde el link es una fuente de información.
3. Análisis de disponibilidad: Analizar el proceso de captura y de almacenamiento de
datos. Tal vez es necesario empezar a levantar la información y postergar el proyecto
para más adelante.
Esto es importante, ya que puede haber datos que hoy no están disponibles, pero que serían
muy útiles. No restringirse solo en los datos que tenemos disponibles. Pensar en qué información
me gustaría tener para el caso de predicción de demanda, dado que la estacionalidad es muy
importante, necesitaremos al menos un año de datos históricos para que nuestro modelo pueda
aprender sobre patrones estacionales. En este sentido, a medida que vayamos adquiriendo
más data, probablemente irá mejorando el desempeño predictivo de nuestros modelos.
4. Relación de las fuentes: Encontrar identificadores en las diferentes fuentes para poder
hacer cruces. Es relevante poder utilizar fuentes de datos que vamos a poder relacionar.
Por ejemplo, ¿Tenemos identificadores de personas que nos permitan fusionar sus
características con su historia y comportamiento transaccional?
5. Representación funcional de los datos: Finalmente, una vez que tenemos todos los
datos identificados debemos representar sus relaciones para poder tener un “mapa”
definido que permita hacer seguimiento desde donde se obtiene la información.
Este va a ser el diseño o nuestra arquitectura de datos que nos permitirá mantener el control
sobre nuestros datos y hacer seguimiento en el tiempo.
Lección 3. ETAPA 3: Preparación y tratamiento de los datos
Esta etapa consiste en capturar, almacenar y preparar los datos para poder hacer los análisis.
Los pasos para seguir son los siguientes:
1. Adquisición y registro: Corresponde al levantamiento de la información. Es la primera
etapa en que capturamos los datos y los almacenamos, ya sea en nuestros servidores
o en alguna solución basada en la nube (del tipo IaaS).
2. Metadatos: Se refiere a los datos de los datos. Acá etiquetamos nuestros datos para
poder tener trazabilidad (fecha de carga, origen, registros, tamaño, autor, etc.).
3. Proceso de formateo y construcción de variables: Especificar formato de números,
string (texto), fechas, etc. Construcción de variables. Por ejemplo, la cantidad de cuotas
morosas por persona, variable binaria que tome el valor 1 si es que es “fin de mes” o “fin
de semana largo”.
4. Integración de datos: una vez que levantamos los datos, debemos construir una base
de datos consolidada con toda la información disponible.
a. Representación de los datos: entender relaciones entre variables e
identificadores únicos (por ejemplo, rut para las personas o sku para los
productos).
b. Análisis de integridad: en caso de establecer relaciones, identificar claves
primarias, foráneas. Realizar análisis de duplicados.
c. Definir tipo de unión que vamos a hacer, tal como se muestra en la siguiente
infografía:
Por ejemplo, si tenemos una base de datos de transacciones que contiene el rut del cliente y
tenemos otra base con datos específicos sobre clientes y sus características, nos puede
interesar “pegarle” a la base de transacciones los datos de las características de los clientes
(ej. Edad, si es hombre o mujer, etc.).
Así, tenemos distintas opciones para unir bases de datos.
● Left join (Unión por la izquierda): A la base de datos de transacciones (izquierda) le
pegamos información sobre los clientes que hicieron transacciones.
● Right join (Unión por la derecha): A la base de datos de clientes, le pegamos información
de transacciones. Como resultado nos van a aparecer clientes registrados que no tienen
transacciones y clientes que sí tienen. Puede que haya transacciones que no se peguen
si es que el cliente no estaba registrado en la base de datos de clientes.
● Outer join (Unión completa): Nos van a aparecer todos los clientes registrados (tengan
o no transacciones) e incluso clientes no registrados que tengan transacciones.
● Inner join (Unión basada en la intersección): Nos mostrará datos sobre clientes que
estén en ambas bases de datos.
5. Calidad del dato y limpieza: La gran mayoría de las veces los datos que utilizamos
necesitan pasar por un filtro de limpieza antes de realizar los análisis. Los datos además
vienen con inconsistencias, ruido, valores duplicados, valores faltantes (en cuyos casos
podría ser necesario definir estrategias de imputación de datos faltantes o celdas
vacías), muestras desbalanceadas, outliers, por lo que a veces se requieren tareas de
normalización de datos. En este sentido, el objetivo de la limpieza es eliminar posibles
sesgos en los datos que nos puedan llevar a conclusiones equivocadas.
Por ejemplo, puede que existan fechas en que observamos que no se vendieron
unidades. En este tipo de casos es mejor consultar al cliente el por qué, ya que puede
ser que ese día no había en stock ninguna unidad del producto y por eso no hubo ventas.
Por lo tanto, sería un error considerar ese dato como un “0”, ya que en realidad no había
stock. Es muy importante lograr que los datos con los que trabajemos sean lo más
representativo posible de la realidad.
6. Construcción de variables derivadas: Construir variables a partir de las distintas tablas.
En esta etapa también se realizan transformaciones de variables para lograr maximizar la
varianza en cada variable (ejemplo: logaritmo), tal como se muestra en la siguiente
infografía:
A veces una variable puede mostrar una distribución de “cola” muy larga como en el gráfico de
la izquierda. Si aplicamos una transformación logarítmica, podemos lograr “mejorar” la
distribución y lograr más varianza, lo que es útil, por ejemplo, cuando hacemos modelos
predictivos.
7. Análisis exploratorio de datos: Es el proceso de investigación inicial que hacemos
sobre un determinado problema con el objetivo de descubrir patrones, generar insights
valiosos, testear hipótesis, verificar supuestos. Para esto utilizamos herramientas
estadísticas y visualizaciones, histogramas, estadísticas descriptivas, etc. Comprender
datos nulos, datos atípicos.
En esta parte podemos validar los conocimientos que nos traspasa el área de negocio
(por ejemplo, a fin de mes se observa un comportamiento de ventas distinto) para
evaluar cómo incorporar esos conocimientos en un modelo.
Lección 4. Etapa 4: Modelamiento y evaluación
Luego de haber identificado el problema de negocio y definido el problema de Data Science,
vamos a construir un modelo analítico, para lo cual es necesario definir las técnicas
analíticas y estadísticas que utilizaremos para el modelamiento.
Para ello, contamos con las siguientes subetapas:
1.- Identificar tipos de técnicas de modelamiento: Existen 4 grupos de técnicas y se
describen en la siguiente infografía:
En el caso del ejemplo que hemos estado analizando, se trata de un modelo de aprendizaje
supervisado de regresión. (Profundizaremos en estas tipologías en módulos posteriores).
2.- Diseño de técnicas de modelamiento: Identificar la función de costos a minimizar.
Variable dependiente, tipo de algoritmo para minimizar.
3.- Diseño de técnicas de evaluación: Existen muchas métricas de evaluación, algunas de
ellas son: AUCROC, KS, MSE. El criterio debe ser claro y único, no cualquiera. Tiene que hacer
sentido con el modelo y con el problema que estamos resolviendo. En esta parte, es muy
importante incorporar al área de negocio. Por ejemplo, en el caso de venta de productos frescos
uno podría pensar que el objetivo es maximizar el margen directo. Esto nos podría traer como
resultado tener poco desperdicio y algún nivel de quiebres de stock. Sin embargo, el área de
negocio puede tener otras restricciones, como no tolerar que existan quiebres de stock porque
valora mucho la experiencia de su cliente final. En ese sentido, nuestra evaluación debe
considerar este punto y no solo maximizar el margen.
4.- Entrenamiento: Metodología de separación de muestras. Queremos que el modelo
aprenda, no que memorice, por lo tanto, tenemos que tomar las precauciones para evitar
problemas de Overfitting (efecto de sobreentrenar un algoritmo de aprendizaje con ciertos datos
para los que se conoce el resultado deseado), que nos podría traer problemas para el
desempeño predictivo. (Profundizaremos en esto en módulos siguientes).
5.- Evaluación: La idea es evaluar el modelo en datos que el modelo nunca vio. Queremos
que el modelo aprenda y ver su real capacidad predictiva.
Es importante notar que este es un proceso cíclico. Si es que los resultados no son los
esperados, debemos volver al inicio de nuestra metodología CRISP. Volver a revisar la variable
dependiente, independiente, preguntas correctas, etc.
El modelo no es el objetivo, el objetivo es aprender y volver a comprender bien el problema,
los datos, hasta que logremos los mejores resultados posibles que nos sirvan para resolver
el problema.
Tanto en estas etapas como en la preparación de datos se toman muchas decisiones que es
necesario documentar para poder hacer seguimiento, revisión y actualización del proyecto.
Presentación de resultados
Una vez que tenemos la evaluación completada, debemos transmitir el conocimiento de lo
aprendido. Pensar en el receptor. Mostrar lo importante y no lo interesante. Mirar el problema
de negocio y ver si lo estamos resolviendo o no, a través de:
● Informes y reportes.
● Visualizaciones (mirar los datos).
● Infografías (interactivas).
● Cuadros de mando: KPI, evolución.
Lección 5: Etapa 5: Despliegue y paso a producción
En esta última etapa debemos:
1) Tomar algunas definiciones sobre la plataforma tecnológica que vamos a utilizar
para la implementación del proyecto. Para esto debemos considerar lo siguiente:
a. Diseño de arquitectura.
I. Captura de información.
II. Almacenamiento.
III. Procesamiento.
IV. Explotación del modelo.
b. Selección de componentes tecnológicos: definir el tipo de soluciones que vamos
a utilizar ya sea para el almacenamiento, análisis, escalabilidad, etc.
c. Estrategia de implantación.
d. Soluciones Cloud vs on premise (IaaS, PaaS, SaaS).
e. Desplegar el modelo en la plataforma tecnológica:
I. Integración en la arquitectura.
II. Planificación temporal.
III. Integración en aplicaciones del negocio.
2) Puesta en valor: Integrar el modelo en las operaciones.
I. Toma de decisiones.
II. Campañas periódicas.
III. Decisiones autónomas.
Todos los modelos están equivocados, pero algunos son útiles. (George Box, 1919-2013
Estadística, considerado como una de las mentes más brillantes de la estadística del siglo XX)
El modelo no tiene valor si no accionable
3) Seguimiento: Los datos pueden cambiar y el modelo puede perder capacidad analítica.
Se debe considerar el reentrenamiento. Podemos hablar de 3 formas de seguimiento:
a. Seguimiento de variables: Queremos ver si los datos que utilizamos para
entrenar nuestro modelo siguen siendo representativos de la realidad. Por
ejemplo, en el caso de una cartera de créditos, si es que entrenamos el modelo
hace algunos años y luego hubo un reestructuramiento de la cartera y hoy
tenemos una proporción mucho mayor de gente joven con poca trayectoria
laboral, probablemente nuestro modelo inicial ya no será válido y mostrará un
peor desempeño. Por lo que, es importante hacer seguimiento a la estabilidad
de las variables en el tiempo, tal como se ejemplifica en la siguiente infografía:
b. Seguimiento de resultado: Output del modelo. ¿Cambió la estabilidad del
modelo? (ejemplo: Deja de predecir una categoría).
c. Seguimiento capacidad analítica: El modelo puede ir perdiendo capacidad
predictiva.
Los modelos son objetos vivos. Puede haber muchos cambios en múltiples dimensiones y es
muy importante estar monitoreando constantemente y mantener actualizados los modelos para
que mantengan sus virtudes y estas vayan mejorando en el tiempo.
Lección 6: El Producto Mínimo Viable (MPV)
El Producto Mínimo Viable, prueba de concepto, piloto, prototipo, etc. es un concepto que
viene del desarrollo de productos. La idea es maximizar la probabilidad de éxito de un producto
o proyecto y, junto con ello, no embarcarnos en algo que podría fracasar.
Para desarrollar un Producto Mínimo Viable (MVP) buscamos el mínimo esfuerzo que
necesitamos para testear sin desarrollarlo entero y que permita ver el potencial del proyecto.
No queremos hacer un proyecto que sea más complejo de lo que se necesita.
Es así como el Lean Startup es básicamente la metodología más avanzada para el desarrollo
de productos en la actualidad. Su idea central es que, al crear productos o servicios de manera
iterativa mediante la integración constante de los comentarios de los clientes, puede reducir
el riesgo de que el producto o servicio falle (construir-medir-aprender). Una parte integral del
concepto de construir-medir-aprender es el MVP, que es esencialmente una "versión de un
nuevo producto que permite a un equipo recopilar la máxima cantidad de aprendizaje validado
sobre los clientes con el mínimo esfuerzo"
A continuación, en la infografía, se grafica la idea del MPV en el caso de validar qué tipo de
movilidad tendrá éxito o no:
Como vemos se comienza con el menor esfuerzo para probar la idea. En este caso, solo
tomamos dos ruedas y una tabla. Luego enviamos esto al mercado y recibimos comentarios
para mejorar continuamente nuestro producto al agregarle más complejidad. En este caso,
terminamos con un automóvil que integra la retroalimentación del consumidor.
La metodología es la misma que para cualquier proyecto de Data Science, utilizaremos la
metodología CRISP hasta la etapa de evaluación. Sin embargo, debemos acotar las etapas
más intensivas, ya que nos interesa analizar el potencial y no necesariamente desarrollar el
modelo más depurado posible. Podemos restringir el set de datos y hacer un desarrollo más
acotado, responder preguntas más delimitadas, de modo de lograr conocer el potencial de
este tipo de herramientas antes de hacer el desarrollo completo.
Para garantizar el éxito del MVP es muy importante hacer el proceso muy de cerca con
el cliente. Definir preguntas y entender muy bien el negocio junto con el cliente, al igual como
describimos en cada una de las etapas anteriores. Al mismo tiempo, el diseño de la
evaluación también debe ser acordado con el cliente. Se busca alinear expectativas y
objetivos para que los resultados del modelo sirvan para ver el potencial del proyecto
en la solución de la problemática actual.
Vamos a conocer 4 productos mínimos viables que fueron exitoso:
El primer caso, corresponde a cómo Dropbox abordó la cuestión de la viabilidad del mercado al
demostrar su producto en un video. Para responder a la pregunta de si los clientes querrían
usar y pagar por su solución de sincronización de archivos y para justificar el mercado ante
los inversores. Decidieron probar un nuevo mecanismo, en donde hicieron un video
explicativo y comenzaron a compartirlo con su red para ver cómo reaccionaría la gente. El
video de 3 minutos demostró la funcionalidad prevista de Dropbox y resultó en un aumento de
registros de 5000 personas a 75 000 de la noche a la mañana, todo esto en ausencia de un
producto real.
Fuente de la imagen: Dropbox.
El video explicativo de Dropbox sirvió como una brillante validación del mercado antes de tener
que invertir en la infraestructura y el desarrollo necesarios para que un producto de alta
tecnología alcanzara un nivel funcional en el mundo real. Orientó a los clientes potenciales a
través de lo que es el producto y demostró claramente cómo los ayudaría, lo que eventualmente
llevó a por qué querrían pagarle por él.
Otro caso exitoso de MVP es Spotify, el cual se lanzó en 2009 una página de destino en donde,
se centraron en la característica única que más importaba “la experiencia de transmisión de
música”, de esta manera, con las aplicaciones de escritorio, pudieron probar el mercado en la
versión beta limitada, lo que les dio tiempo para generar impulso para abordar las
preocupaciones de licencias de la industria de la música que seguramente surgirían cuando
planearan expandirse a los EE. UU
Es importante señalar que Spotify utiliza un ciclo de producto iterativo de 4 etapas: Piénselo,
Constrúyalo, Envíelo, Tweak It. De esta manera, en su etapa "Piénselo" prueba el mérito de
los MVP conceptuales, mientras que la etapa "Constrúyalo" lanza un MVP físico solo después
de que se haya probado su calidad. Las fases "Enviarlo" y "Modificarlo" aseguran la calidad a
largo plazo y la alineación del cliente al lanzar el MVP gradualmente, aprender de los
comentarios e iterar incansablemente.
Otro caso es el de Groupon, en donde Andrew Mason (fundador de Groupon) comenzó con
un sitio web llamado The Point, una plataforma para unir a las personas para lograr cosas que
no podrían hacer solas, como recaudar fondos o boicotear a un minorista. Pero el sitio no
ganaba mucho impulso, por lo que decidieron probar con otra cosa. Con el mismo dominio,
crearon un blog de WordPress personalizado llamado The Daily Groupon y comenzaron a
publicar ofertas todos los días de forma manual. Cuando alguien se inscribía en un trato en
particular, el equipo generaba un documento PDF y lo enviaba por correo electrónico usando
Apple Mail. Este sitio web simple que "crearon juntos" le mostró al equipo que este era un
mercado que valía la pena mirar con solo un MVP manual primero que los ayudó a cambiar
su oferta de lo que habían estado haciendo anteriormente.
No invirtieron tiempo en desarrollar un sistema de cupones y diseñar un nuevo sitio web. En
cambio, tomaron los recursos que tenían y los convirtieron en un MVP poco a poco para
probar la hipótesis de si las personas estarían interesadas en lo que estaban
ofreciendo. Comenzar desde un sitio web de WordPress personalizado y enviar documentos
PDF manualmente por correo electrónico a una lista de correo no es exactamente lo que
llamaría escalable, pero el MVP de Groupon logró responder esa pregunta por ellos.
Fuente de la imagen: Archive.org.
Y el último caso que revisaremos es el de Airbnb, en donde Brian Chesky y Joe Gebbia
durante el 2007 querían iniciar un negocio, pero tampoco podían pagar el alquiler de su
apartamento en San Francisco. Había una conferencia de diseño en la ciudad y decidieron
abrir su loft como alojamiento económico para los asistentes a la conferencia que habían
tenido suerte en los hoteles cercanos. Tomaron fotos de su apartamento, lo pusieron en un
sitio web simple y pronto tuvieron 3 invitados que pagaron durante la duración de la
conferencia, una mujer de Boston, un padre de Utah y otro hombre originario de la India. Esta
interacción cercana les aporto una valiosa información sobre lo que querrían los clientes
potenciales.
Este MVP ayudó a validar el mercado y demostrar que las personas estarían dispuestas a
comprar la experiencia. Con sus suposiciones iniciales respondidas, que las personas
estarían dispuestas a pagar para quedarse en la casa de otra persona en lugar de un hotel y
que no solo los recién graduados universitarios se registrarían, comenzaron Airbed And
Breakfast conocido actualmente como Airbnb.
Fuente de la imagen: TechCrunch .