Product Briefing

A menudo recibo “preguntas del millón” para las que no tengo respuesta. “¿Dónde encuentro (cerca de este código postal, a poder ser) product managers con años de experiencia, solvencia técnica y sensibilidad comercial?, suele ser una de las más escuchadas. Otra es: “¿cómo transiciono mi empresa que ha sobrevivido a base de consultoría+licencias a ser una empresa de producto?”. Y sobre las respuestas a esta pregunta vamos a hablar hoy.

Lamentablemente, por si alguno quiere ahorrarse minutos de lectura, no hay una respuesta generalmente válida para todas las empresas que quieran pasar por este trance. Cada cultura y organización son un mundo que requieren ser entendidos en detalle en su contexto. No hay balas de plata, más allá de recordar que no hay transición sin fricción, y por tanto daños. Por tanto, think it twice. La hierba verde del vecino, el cementerio lleno de empresas de consultoría rentables que un día empezaron a soñar con la escalabilidad a coste marginal nulo y todo eso.

Así que en estas ocasiones en las que alguien se acerca preguntando :”¿cómo puedo acabar teniendo ‘una empresa de producto'”, mi respuesta (gallega, por supuesto) es: “¿por qué no empiezas escribiendo un product briefing?”.

Así que aquí viene una aproximación rápida, con el necesario disclaimer de que uno tiene su experiencia en el fascinante mundo del SaaS B2B y para otros sectores/modelos todo probablemente sea muy diferente.

¿Qué es un “product briefing”?

Llamaremos “product briefing” (PB) a un documento que resume la estrategia y planificación detrás de un producto, con un formato y contenido dirigidos a ser consumidos por cualquier empleado o stakeholder.

Su principal objetivo es responder a cualquier pregunta derivada de:

¿Por qué es un buen uso de los recursos de la empresa el trabajar en este producto (o gran funcionalidad) de este modo en este momento?

El PB debiera mantenerse actualizado con mínimos cambios, pero sería muy mala señal necesitar a menudo cambiar el contenido (bien porque el documento se ha compartido mucho antes de tener resueltas incógnitas relevantes, bien porque la dirección de producto es demasiado inestable manteniendo las decisiones acordadas).

Las principales ventajas que se obtienen de escribir un PB son:

  1. Obliga al liderazgo de producto a sintetizar sus ideas estratégicas en un único documento.
  2. El PB nos permite compartir esta estrategia con toda la organización para alinearla hacia los objetivos.
  3. El hecho de sintetizar y compartir esta estrategia reduce en magnitudes los “conflictos políticos internos” a gestionar. Ya tú sabes.

¿Qué *no* es un Product Briefing?

Al ser principalmente un documento que recoge las decisiones estratégicas y ser de lectura transversal, deberíamos evitar sumergirnos demasiado en detalles irrelevantes para el conjunto de la organización.

En general, debiera siempre mantener la mínima información indispensable y útil para toda la organización, y enlazar a documentos más detallados cuando sea necesario.

Un PB está pensado para sintetizar la estrategia a nivel de producto. Como documentos previos a implementar diferentes funcionalidades, en Basecamp, Intercom o Drift tienen buenos ejemplos (que no dejan de tener objetivos similares pero a otra escala más táctica).


Contenido

El contenido varía por empresa/producto, pero debería estar orientado a responder a la pregunta remarcada en el punto anterior: “¿por qué es un buen uso de los recursos de la empresa el trabajar en este producto (o gran funcionalidad) de este modo en este momento?”. O mejor dicho: debería estar orientado a responder y además a convencer.

Changelog

Al principio del documento, presuponiendo que no estará en un formato como Markdown que nos permita seguir los cambios en un repositorio de código, debiéramos tener una tabla que nos muestre tanto la fecha y responsable de la última actualización del documento, así como los estados por los que ha ido pasando.

Por tanto, se recomienda añadir una tabla como la siguiente e ir actualizándola con cada cambio de estado o modificación relevante en el mismo:

FechaEditorComentario
 … … …
 … … …

Nota de Prensa

Es una buena idea para sintetizar el contenido del PB el redactar una nota de prensa anunciando el lanzamiento de los objetivos marcados, dado que en un par de párrafos podemos dar respuesta a los principales elementos de un PB (¿qué se anuncia?,¿cuándo está previsto publicarla?,¿a quién interesa?,¿qué ofrece?, ¿por qué es relevante?, etc).

Contenido estratégico

A nivel estratégico el PB debería, como mínimo, responder a las siguientes preguntas:

  • ¿Por qué invertimos en construir este producto? – Recordando la máxima del product managementOnly build solutions for problems that are urgent, pervasive and that the market will pay to solve”, el documento debería transmitir (y convencer) a su audiencia que el camino propuesto es el que retorna los mayores beneficios posibles, ya que cumple los principios de urgencia, generalidad y está orientado a clientes con capacidad de compra. Confío en que a vuestra edad ya sepáis que una empresa es lo que puede llegar a ser rentable gracias a producir, y no el envoltorio que necesitamos para poner un producto en el mercado. Que no es lo mismo, ni parecido.
  • ¿Qué necesidades resuelve? – En lugar de orientar el contenido a mostrar las principales funcionalidades, deberíamos orientarlo a detallar los principales problemas que tendría que resolver.
  • ¿Qué no hace este producto? ¿Qué hemos decidido no ofrecer jamás? – En el mundo real, trabajamos con restricciones. La principal ventaja de tenerlas es que evitan revisar continuamente opciones, y ayudan mucho a posicionarnos en un mercado (o contra soluciones alternativas). Ejemplos de restricciones serían “en nuestro SaaS nunca ofreceremos una versión on-premise” o “únicamente ofreceremos una API para interactuar con nuestro servicio”.
  • ¿Cómo se alinea este trabajo con los objetivos de la empresa? – El producto desarrollado, no deja de ser un medio para conseguir los objetivos corporativos. Por tanto, hemos de concretar para qué objetivos, iniciativas o proyectos estamos invirtiendo, y cómo esperamos ayudar a conseguir esos objetivos. Quizá otro día tocará escribir sobre objetivos>iniciativas>proyectos>tareas.
  • ¿Cómo sabremos si tiene éxito? ¿Cómo definimos lo que consideramos éxito a corto/medio/largo plazo? – A la hora de iniciar cualquier actividad, hemos de definir (al menos) una métrica que nos permita visualizar el éxito o no del trabajo que vamos desarrollando, para poder tomar decisiones que cambien el rumbo, o incluso cancelarlo. Además, estas métricas pueden variar a lo largo del tiempo. Por ejemplo: si lanzamos un producto, a corto plazo puede ser un indicativo de éxito el número de clientes conseguidos, a medio plazo llegar a cierto nivel de facturación, y a largo plazo el porcentaje de mercado capturado.
  • ¿Cómo nos posicionamos en el mercado? – En el apartado siguiente se detallará este punto, pero convendría tener concretado el posicionamiento estratégico en el mercado: a cuál nos dirigimos, cómo lo satisfacemos, cómo lo distribuimos, etc.

Contenido práctico

A nivel más práctico el PB debería cubrir (al menos) los siguientes puntos:

KPIs

  • Listado de las métricas más relevantes que se monitorizarán. En cada una de ellas, detallar los segmentos y objetivos actuales acordados (si los hubiera).

Al ser el PB un documento relativamente estático, tiene mucho sentido aquí enlazar a otro documento (como por ejemplo el plan de instrumentación) para acceder a todos los detalles detrás de las mismas.

Marketing

  • Definición del mercado y los segmentos a los que nos dirigimos . Recordad aquí que el que segmenta el mercado por variables demográficas y no por necesidades es un parguela.
  • Entorno competitivo (solo para empresas de un único producto), e idealmente un análisis resumido de las 5 fuerzas de Porter.
  • Comparativa contra competidores
    • Listado de empresas consideradas competencia directa y análisis de los principales puntos que se resaltarán contra ellos.
    • Enlace a un análisis detallado comparando funcionalidad.

Personas y casos de uso:

  • Listado de personas que vayan a usar el producto unido a lo que esperan conseguir/satisfacer con el mismo. Para cada una de estas personas, debiéramos responder: ¿qué usaba hasta ahora?, ¿cómo se le manifestaba el dolor?, ¿cuál es nuestra competencia directa?.
  • Listado de personas que no vayan a usar el producto, pero cuyos requisitos hemos de incorporar al mismo.
    • Por ejemplo, es posible que un producto digital no lo vaya a usar el CISO de una organización, pero su aprobación en base a ciertas funcionalidades del producto es crítica para poder ser usado.

Listado de principales necesidades que solventará el producto

  • Intencionadamente, no es una lista de funcionalidades, sino de necesidades (dado que la funcionalidad será detallada más adelante por los diferentes equipos que trabajen en la misma).

Por ejemplo, una necesidad por solventar podría ser “el poder exportar datos” del producto porque el cliente tiene la necesidad de importarlos a otra solución. Si hoy decidiésemos que la funcionalidad es “Exportar a CSV” estaríamos obviando otras quizá también necesarias como “Actualizar Google Sheets”.

Roadmap sugerido

  • Principales necesidades que solventará, en un escenario temporal estimado.
  • Enlace al roadmap detallado que se comparte internamente con la organización.

Principales dependencias del proyecto

  • Tanto internas como externas (si fuese necesario).

Aquí hablaríamos de coordinar el trabajo de diferentes equipos internos, si alguna parte del trabajo podría llegar a ser un bloqueo (y a priori que alternativas se plantean), etc.

Resumen y enlace a los diferentes planes:

  • Plan de desarrollo
  • Plan de lanzamiento
  • Plan comercial

Concluyendo

Como he dicho arriba, cada empresa es un mundo y manteniendo el objetivo de sintetizar y compartir las ideas del liderazgo de producto utilizando un documento que permita convencer a la organización de que se están tomando decisiones meditadas (y ojalá acertadas).

Para mí, la mejor prueba de que se tiene una cultura de producto sana y alineada (o de que un Product Manager está haciendo correctamente su trabajo) es cuando no hay reparos en decir “no” a una petición. Si un lead o cliente importante, (o hasta un equipo de desarrollo), solicita incluir algo en el roadmap y no hay reparos en negarse porque todos tenemos claro que “no sería un buen uso de los recursos el trabajar en eso ahora”, señal de que vamos por el buen camino. Y ojalá lo veamos.