Los 3 pasos para entregar la mejor experiencia de producto

Crear productos muy buenos es difícil. Crear productos y features que los usuarios amen de manera constante es aún más difícil. En Dropbox, nuestro foco siempre es que nuestros usuarios tengan una muy buena experiencia de producto al utilizar la plataforma. Queremos brindarles una experiencia que les facilite la vida y que les permita realizar su trabajo de la mejor manera.

¿Puede un proceso de producto guiarnos para lograr estos resultados? En Dropbox nos hemos estado preguntando esto por un buen tiempo. La respuesta fue un proceso para producir productos, features e incluso otros procesos respondiendo estas preguntas:

• ¿Por qué?
• ¿Cómo?
• ¿Qué?

Responder estas preguntas, en ese orden, ha sido vital para la construcción de nuestros productos en Dropbox. Primero, identificamos oportunidades relevantes, segundo, exploramos soluciones y con eso creamos productos que nuestros clientes admiren asi nace la experiencia de producto.

El valor de este proceso va más allá de solo crear productos digitales. Como autor y orador, Simon Sinek describe en su TED talk, que los líderes y compañías más innovadoras también utilizan un proceso de 3 pasos muy similar. Hay un patrón común en el proceso: siempre se comienza con el por qué, luego el cómo y sólo después de eso, se empieza a trabajar el qué.

¿Por qué es importante la experiencia de producto? ¿Por qué lo tenemos que hacer?

En Dropbox, siempre comenzamos el proceso de desarrollo de un producto con el por qué, este paso lo consideramos el más importante. Comenzar con el por qué involucra preguntarse por qué un problema es importante y por qué se debe resolver ahora. Hacer este proceso de manera explícita nos permite realmente trabajar en problemas que verdaderamente importan. En la fase del por qué, buscamos responder este tipo de preguntas:

• ¿Quiénes son los usuarios?
• ¿Qué problemas tienen actualmente?
• ¿Cuáles son los problemas para Dropbox?
• ¿Por qué es importante esto ahora?
• ¿Cuál es el tamaño de la oportunidad?
• 
  

En esta etapa nos enfocamos en entender el problema y es casi como una regla, no incluimos nada relacionado a una potencial solución. Responder las preguntas mencionadas arriba puede involucrar otros esfuerzos, como realizar un estudio para conocer a nuestros usuarios y un análisis de la competencia. El principal objetivo de esta etapa es obtener una serie de hipótesis relacionadas a la oportunidad y una potencial ruta al éxito. Dentro de Dropbox, le llamamos la fase cero del proyecto.

A través de los años hemos identificado los principales beneficios de arrancar con la fase del por qué.

• Alineamiento: Una vez que las preguntas mencionadas anteriormente se responden, por lo general, las revisamos junto con las personas involucradas en el proyecto. Por ejemplo, en una integración entre Dropbox-Gmail,  mientras definíamos el  por qué, fuimos capaces de articular una serie de hipótesis que definen el éxito del proyecto y el grupo de métricas que validará cada hipótesis. La revisión sirvió para alinear a los líderes y principales stakeholders en cómo se vería el proyecto si este fuese exitoso y a desarrollar una mirada conjunta del problema.
• Entendimiento claro del usuario: En Dropbox, comenzamos con el “por qué” para desarrollar nuestros propios productos. En nuestra plataforma interna de experimentación, responder el “por qué” fue un paso obligado para entender los diferentes user personas y articular flujos personalizados. Esto nos permitió entender los puntos débiles en cada uno de estos user persona, que antes no los teníamos identificados.
• Enfocarnos cuando hay complejidad: Mientras respondíamos el “porqué” reacondicionar o mejorar un producto en Dropbox, entendimos que el estado actual del mundo está muy fragmentado. Contestar el porqué nos ayudó a enfocarnos en los power users, para priorizar y resolver asuntos en áreas específicas. Esto simplifica la complejidad de muchos de los proyectos.

Al mismo tiempo existen ciertos retos:

• Moverse rápido: No todo lo que se hace en Dropbox requiere una fase o un proceso rígido de revisión. Ser flexible nos permite ser ágiles y movernos rápido cuando sea necesario. Pequeños features y experimentos rápidos que testean las hipótesis, no necesitan tanto rigor como el lanzamiento de un producto grande.
• Definir el alcance y el nivel correcto de abstracción: El beneficio de preguntar “por qué”, es que deja un rato de lado al feature/producto, para enfocarse en el problema que se está tratando de solucionar.  El “por qué” tiene que estar al nivel de abstracción, que defina el alcance de los problemas que estamos tratando de resolver. Sin el alcance definido hay un riesgo latente de tratar de resolver un problema mucho mayor al que se quiere solucionar.
• 
  

¿Cómo?

Lograr una solución específica comenzando con un problema específico. Ahí radica la experiencia de producto

El siguiente paso natural después de preguntarse el “por qué”, es investigar el “cómo” podemos resolver esas oportunidades. En la fase del “cómo”, vamos desde tener claridad del problema hasta saber los enfoques específicos que hay que tomar para resolverlo. Antes de comenzar esta fase, es importante haber salido muy alineados de la fase del “por qué”. Esto evita gastar dinero y energía solucionando los problemas incorrectos.

Puede haber más de una forma de solucionar los problemas (pero no siempre). Estos diferentes enfoques, para lograr soluciones, por lo general tienen trade-offs.En la fase del “cómo”, exploramos diferentes maneras de solucionar el problema y valoramos cada una de ellas. Uno de nuestros esfuerzos en producto, fue relacionado a construir una plataforma para el equipo de Growth. Se consideraron 3 enfoques: crear in-house, apalancarnos de una solución open-source o comprar una solución.

A veces no solo es evaluar un conjunto de opciones, sino entender la secuencia de la solución. De tener claro cuales son los problemas que debemos resolver primero, nacen las prioridades identificadas. En la fase del “cómo”, queremos trabajar el tener una figura relativamente clara de cómo será la solución final. En Dropbox, nos referimos a la fase del “cómo”,  como la primera fase del proyecto.

Los aspectos de esta fase incluyen:

• Explorar diferentes enfoques para resolver los problemas identificados.
• La mejor manera de resolver los problemas con el racional detrás de esas soluciones.
• Una solución preliminar con una estimación inicial del esfuerzo.
• La secuencia de la solución y sus hitos más importantes.
• Primeras ideas para validar y planes de aprendizaje.
• Riesgos asociados y cómo mitigarlos.

En la fase del “cómo”,  vamos a través de un proceso de pensamiento divergente,para explorar los diferentes espacios para las soluciones de los problemas priorizados y hacerle seguimiento con pensamientos convergentes, para obtener una solución específica que resuelva los problemas. En algunas maneras, esta secuencia de pensamientos divergentes – convergentes es parecida a  double diamond model, que es comúnmente usado para estructurar procesos creativos incluyendo el diseño de productos.

¿Qué?

Obteniendo soluciones de alto nivelpara experiencia de producto

Llegamos al tercer paso: el qué. Para cuando estemos en este punto, tenemos suficiente validación y alineamiento de los problemas que vamos a solucionary la importancia de los mismos. No existen grandes preguntas sobre el valor del problema en sí mismo o el enfoque general.

En esta fase, nos movemos de una solución de alto nivel a un enfoque mucho más orientado a una solución específica que capture los detalles. Escribimos a lo que nos referimos como requerimientos del producto. Construimos especificaciones del diseño y discutimos los detalles de la implementación técnica para la solución del producto.

El objetivo de esta fase es reducir el riesgo y las dudas asociadas al proyecto.También aumentamos la confianza y la claridad necesaria por los ingenieros y otros equipos para proceder con la implementación de la solución. Aspectos de esta fase incluyen:

• Un conjunto claro de casos de uso que forman parte del alcance de la oportunidad.
• Un grupo de aspectos adicionales o features que hagan parte de alinear cada oportunidad.
• Especificaciones del producto para casos generales y casos excepcionales .
• Prototipos bien elaborados que muestran cómo se vería la solución y trabajar en los detalles (mensajes, imágenes etc.)
• Métricas, analíticas y registro.
• Dependencias entre los equipos.
• Planes de lanzamiento con fechas claras.
• 
  

En Dropbox, la etapa de “qué” se suele desarrollar iterando al trabajar con diferentes equipos y solo a veces se revisa con los líderes.

Más allá del producto busca una experiencia de producto:

Procesos, programas y más

El proceso de las  3 etapas, por qué, cómo y qué, se extiende más allá del desarrollo del producto. Este enfoque también ha sido adoptado para construir nuevos procesos y programas.

• Programa de Product Managers para recién graduados: Aplicamos el proceso establecido, líneas arriba para construir un nuevo programa que contrata PMs directamente salidos de la universidad. La fase “por que” explora el racional y nuestra oportunidad de contratar recién egresados que sean muy buenos y unirlos al equipo de Product Management. Con la siguiente fase, exploramos diferentes aspectos del programa: estructuras gerente/mentor, rotación de proyectos, onboarding, y más.
• Calidad de la data y  buenos procesos: Asimismo, comenzamos con el “por qué” para lanzar un esfuerzo de toda la organización para mejorar la calidad de la data. Para el “cómo”, investigamos diferentes estructuras organizacionales, roles que tenían que ser contratados, y modelos RACI para procesos claves. Las diferentes revisiones de los niveles de liderazgo, nos permitieron estar alineados con la solución general de Dropbox.

‍

One size doesn’t fit all

Cambia y escala el proceso para que calce con la necesidad encontrada, clave en la experiencia de producto

Cuando comienzas a pensar en las 3 preguntas, es importante evitar forzar el mismo proceso siempre. La profundidad del análisis y el rigor en el proceso, los tiempos, y los ciclos de revisión deben estar al nivel de la complejidad y los riesgos asociados al proyecto. Estas son algunas maneras de balancear la velocidad y el rigor en estos procesos.

• El nivel de líderes involucrados varía dependiendo del nivel de riesgo y alcance del proyecto. Proyectos grandes necesitan ser aprobados en cada paso; proyectos más pequeños necesitan solo una aprobación grupal.
• Combinar responder el “por qué”  y “cómo” en una misma fase para proyectos pequeños. Incluso para proyectos pequeños y rápidos esto podría ser un one-pager.
• Revisiones, especialmente para la fase del “qué”, se pueden hacer rápidamente,  sí se  derivan directamente de la fase del “cómo”.

Como el equipo de producto ha crecido, algunos equipos han modificado el proceso de 3 fases para cumplir con sus propias metas y necesidades.Algunos equipos tienen una etapa específica de prototipado para entender rápidamente la solución antes de invertir muchos recursos en su implementación total. Los equipos de growth tienen un proceso explícito para el análisis y para el proceso de decisión de los experimentos que realizan.

Al final, el proceso de 3 fases, ¿por qué?, ¿cómo? y ¿qué? o sus diferentes versiones tienen un principal objetivo: ayudar a Dropbox a completar la misión de ayudar a sus usuarios a cumplir sus metas.

Por: Ketan Nayak, ex Product Manager de Dropbox.

Fuente: Medium.Cursos de Kurios relacionados en este artículo: Digital Product Management, Growth Strategy y Growth 101.

‍