“Start with Why” in product development

Basado en la teoría propuesta por Simon Sinek y luego de seguir un poco a los equipos de producto de algunos grandes, más mi experiencia desarrollando productos web, esta es mi propuesta para un framework de trabajo en el diseño y desarrollo de este tipo de productos. Cada producto o feature nuevo debería pasar por un proceso de 6 pasos dividido en tres grandes etapas (Why, How, What).

I. WHY

1. Objetivo del producto.

Este objetivo debe estar estrechamente alineado con el objetivo (o negocio) principal de la compañía. Si este es “obtener más pageviews” porque los clientes son anunciantes que pagan por visibilidad, el objetivo de cada producto o feature debe apuntar directamente a servir este objetivo principal. Además, recordemos que los objetivos siempre son un verbo. Mas, este objetivo junto con los cuatro sub puntos siguientes son la minuta de la reunión inicial del proyecto.

  • Cómo se mide: Cual será el indicador y la herramienta que medirá el éxito de este objetivo.
  • En cuánto tiempo se mide: Cuál es la fecha límite para obtener resultados con el nuevo desarrollo.
  • Mejor escenario: Cuál es el mayor beneficio esperable para este producto. Con esto claro sabemos donde apuntar, aunque no lo logremos tal como lo visualizamos.
  • Peor escenario: Con esto podemos intentar anticipar los impactos de un fracaso. Incluso, si los riesgos son muchísimo más altos que los beneficios, este es un buen momento dentro del diseño para descartar la materialización de este.

II. HOW

2. User Story (User Flow)

Este es el momento para la imaginación, donde recreamos toda la historia o recorrido de los usuarios por nuestra aplicación o servicio. Para esto se puede escribir un guión, hacer dibujos o diagramas de flujo. Estos últimos son especialmente buenos para que también sirvan de guía a los backend en cómo fluyen los datos.

No importa el método, lo significativo es poder entender completamente los caminos que seguirá el usuario al interactuar con nuestro producto: Cómo llega a él, cómo navega (describiendo todos los posibles caminos) y cuál será el punto de salida.

Estas historias DEBEN buscar cumplir el objetivo trazado y nos permiten delimitar el listado de features en las siguientes etapas, ya que todos los features deben estar al servicio de esta experiencia de usuario.

En resumen, podríamos decir que este paso nos permite aterrizar un poco más las ideas que los diferentes miembros del equipo tienen respecto a cómo cumplir el objetivo. Además, estos deberían llegar a las sesiones de trabajo con propuestas para optimizar los tiempos de planificación.

III. WHAT

3. Mockups de baja fidelidad

Las propuestas pueden esbozarse en sesiones de trabajo o ser pre diseñadas por un integrante del equipo, pero lo importante es que sean sencillas y agreguen la menor cantidad de características nuevas, para no disipar los esfuerzos y no perder el foco en los objetivos, así como tampoco perder la factibilidad de medición.

4. Listado de features

Basados en los mockups, se hace un listado de absolutamente todas las tareas que implique este desarrollo, incluyendo el backend y el frontend. Si estamos diseñando una landing page y esta tendrá un menú con 3 botones a X links, eso debe ser detallado pues este es el momento en que se limita el trabajo y se estiman los esfuerzos (tiempo/costos). Un desarrollador programando algo que no se alinea a nuestros objetivos es tiempo y dinero perdidos, además de que distorsiona las mediciones de cumplimiento de objetivos.

Esta etapa es también un momento para hacer una pausa y mirar el paso número 1, donde debemos ver si estamos ajustados con los tiempos establecidos a priori al momento de establecer el objetivo. Si los tiempos se exceden, los features deben ser “recortados”.

También es un excelente momento para replantearse el posible mejor y peor escenario y evaluar si estuvo bien planteado en la primera etapa.

5. Desarrollo del Look & Feel en el mismo frontend y backend

Ambas labores funcionan muchísimo mejor cuando se trabajan en paralelo. Si se convierte el desarrollo en un sistema lineal se pierde tiempo en el calce de los equipos (backend o frontend) cuando se pasan el proyecto de uno a otro. Además mantiene al equipo alineado con los objetivos y motivaciones principales en un mismo “momentum”.

Se deben establecer canales de feedback centralizados que eviten reuniones centradas en la forma. Si el equipo está alineado en el listado de features y en los objetivos, no debería haber grandes cambios ni replanteamiento de los requerimientos.

6. Q&A e implementación de sistemas de medidas.

Terminado el desarrollo se debe probar la herramienta, para:

  • Solucionar posibles bugs.
  • Revisar y corregir el lenguaje.
  • Chequear que se está cumpliendo la historia de nuestro mockup con el flujo que fue diseñado.

También es el momento para implementar los sistemas de medición y dejarlos configurados para el momento del lanzamiento del producto.

Este es el primer draft de esta metodología. Es un framework que busca que cualquier equipo puede utilizar rellenando cada paso para agilizar y optimizar el desarrollo de productos digitales dentro de una compañía.

Show your support

Clapping shows how much you appreciated Felipe Funes’s story.