Para crear mejores productos, comienza describiendo el problema
El secreto para lanzar productos exitosos es definir claramente para tu equipo el problema que están intentando resolver. Una gran descripción del problema provee esta definición y empodera el proceso de desarrollo del producto. Esto inspira y guía al equipo de diseño, hace de la evaluación mucho más simple, y provee dirección para examinar e iterar.
Pero una descripción del problema es inútil si es que no se escribe correctamente. No es un documento de requisitos del producto (PRD por sus siglas en inglés) o una especificación (spec). Una gran descripción de problema contiene al menos tres partes para asegurar que defina lo que tu cliente necesita, no lo que crees que debe ser la solución.
Las tres partes de una gran descripción de problema
Para guiar efectivamente el desarrollo de grandes funciones o características, tu descripción de problema debe siempre contener 3 elementos: el resultado que el cliente quiere conseguir, por qué quieren ese resultado, y qué es doloroso acerca del estado actual de las cosas o status quo. Revisemos cada uno con mayor detalle.
1. El resultado que el cliente quiere
El elemento central de una buena descripción de problema es una descripción clara del resultado que el cliente busca conseguir. Resultados correctamente enmarcados refieren de forma directa a necesidades del cliente, y no funciones o características específicas.
En Lexgo nuestros clientes usualmente nos piden “contratos”, refiriéndose al documento legal que se firma para realizar una determinada operación (por ejemplo vender tu producto, contratar a un empleado o crear una nueva sociedad).
“Al enfocarte en el resultado que el cliente quiere, tu equipo puede resolver el problema de forma innovadora en función del resultado buscado”
Pero cuando hablamos con nuestros clientes, nos dimos cuenta que el resultado que buscaban era poder originar ciertas relaciones o entidades, y asegurar su correcta ejecución o mantención en el tiempo. Un documento legal es una forma de conseguirlo, pero usualmente es sólo el comienzo. Al final desarrollamos una serie de flujos de trabajo legal automatizados, donde el “papel” es lo menos importante. Facilitamos el proceso para nuestros clientes, pero de una manera distinta a la usual (los abogados no suelen preocuparse - o no tienen la capacidad de hacerlo - de la ejecución de cada contrato que preparan). Es clave para conseguir esto concentrarse en el resultado que los clientes quieren, y no las funciones o características que piden.
Este espíritu se resume en una cita usualmente atribuida a Herny Ford: “If I had asked people what they wanted, they would have said faster horses.” Tus clientes hablarán de las features que quieren (caballos más rápidos) pero al enfocarte en el resultado que quieren, tu equipo puede resolver el problema de forma innovadora en función del resultado buscado.
2. Por qué quieren ese resultado
Entender por qué un cliente quiere un resultado te faculta a considerar soluciones más creativas y efectivas de las que considerarías si sólo te preocuparas del resultado.
La razón por la que nuestros clientes no quieren perder pista de sus contratos o sociedades es porque quieren administrar y hacer crecer sus negocios de forma fácil y eficiente.
Dado que conocíamos que la eficiencia en la gestión legal era la principal razón para requerir nuevos contratos, priorizamos alertas tras la firma de los mismos. Un sistema de alertas no es la parte principal de un sistema de gestión contractual, pero dado que entendíamos que el resultado deseado era darles seguimiento, desarrollamos con confianza las funcionalidades que realmente daban solución a los problemas que nuestros clientes enfrentaban. Como resultado, evitamos la larga lista de requerimientos que olvidaban el problema central.
3. Problemas con el status quo
El elemento final de una correcta descripción del problema es esclarecer qué es lo que está mal con la solución actual. Describir qué es lo más doloroso de las actuales soluciones provee foco para tu nueva solución, y crea un claro criterio a utilizar al evaluar nuevos conceptos,
“Conocer estos dolores nos ayudó a priorizar dónde gastar nuestro tiempo y clarificarnos qué es lo que nuestros clientes intentaban hacer”
Cuando hablamos con clientes que sólo querían los borradores de los contratos, inconscientemente hablaban de los complicados flujos de trabajo que debían implementar para sus equipos, así como las situaciones que solían ocurrir cuando la gestión de dicha documentación se perdía.
Conocer estos dolores nos ayudó a priorizar dónde gastar nuestro tiempo y clarificarnos qué es lo que nuestros clientes intentaban hacer. Nos dimos cuenta que podíamos ayudarles a resolver estos problemas específicos con un sistema de alertas automatizado. Esta realización nos facultó a hacer de Lexgo una herramienta mucho más útil para nuestros power-users de lo que era un par de meses atrás.
Prepararse para el éxito
Una comprensión precisa de lo que nuestros clientes encontraban doloroso acerca de la gestión contractual de su negocio nos facultó a proveer las eficiencias que Lexgo debía otorgar sin tener que convertirse en un CMS. Sólo fuimos capaces de hacerlo porque comprendimos profundamente el resultado que nuestros clientes deseaban, por qué querían dicho resultado, y qué es lo que era doloroso acerca de conseguirlo hoy.
Al comenzar con el problema y definir estos tres aspectos en tu descripción del problema, estarás preparando a tu equipo para crear productos creativos, efectivos y altamente distintivos para tus clientes.
Si te gustaría leer más columnas como esta, no dudes en registrarte para recibirlas directamente a tu correo.