5/02/2007

Tareas de un Product Manager (I)

La generación de valor por parte de un Gestor de Producto viene determinada por la destreza que tenga en diferentes áreas, con diferentes tareas para cada una de ellas.

No he tenido mucho éxito en la web a la hora de encontrar definiciones adecuadas de esas tareas (aunque este enlace y éste me han sido bastante útiles), así que, basándome en mi breve experiencia en este ámbito (por lo que estoy viendo en mi empresa, pero también en otras), voy a atreverme a intentar numerar las que, según mi entender, son las más importantes en una empresa de producto. Antes de empezar, he de dejar claro que lo que yo entiendo por Gestor de Producto tiene más que ver con la parte técnica, dejando al "Product Marketing Manager" la tarea de la mercadotécnica; aún así, algunos de los puntos se solaparían claramente.

1. Comprender perfectamente la arquitectura y funcionalidad del producto. Parece una obviedad, pero algunos paquetes de software son realmente complejos, y entender cómo funcionan, y por dónde pueden crecer es algo difícil y que exige tiempo y esfuerzo.
2. Ser capaz de conceptualizar el producto. ¿Cómo le contarías lo que hace el producto a un niño de 9 años? ¿Y a un director técnico de una compañía? ¿Y a un desarrollador? ¿Y a tus padres? Conceptualizar el producto es como subirlo a una escalera; a partir de ahí, es fácil volver a bajarlo por un lado o por otro, dependiendo de quién lo necesite.
3. Escuchar... A todo el mundo. A la gente de ventas, que está recibiendo retroalimentación constante de clientes TODOS los días. A la gente de marketing, que cada día inventa una forma nueva de mostrar el producto, a los competidores, que son gente tan válida como tú (como mínimo), y cuyos movimientos, bajo ningún aspecto, pueden ser olvidados; a las herramientas integrables en el ecosistema empresarial, pues también dan pistas acerca de hacia dónde deber ir tu producto.
4. ... pero con cuidado. Al mismo tiempo, no hay que dejarse llevar por las prisas del comercial, o por las ideas ingeniosas, pero lejanas de la gente de marketing, o por ideas interesantes de los competidores pero que no ayudarían en tu arquitectura actual, ... Para mí esa es una parte muy delicada.
5. Punto de contacto entre ventas, marketing, servicios profesionales y desarrollo. En las organizaciones en las que Product Management está diferenciado o de marketing o de desarrollo de producto, se convierte en una pieza fundamental en el esquema de comunicación de información. Al final, es quien escucha a la gente que "mira al exterior", y se comunica con los tecnólogos que desarrollan el producto. Eso implica una serie de habilidades de comunicación muy importantes: entender los "dialectos" de cada mundo, ser capaz de comunicar ideas complejas de manera simple, o de convertir una petición genérica en una serie de requisitos concretos. Mi opinión personal es que eso sólo se consigue con experiencia previa en la parte de desarrollo: creo más en el "bottom-up" (desarrolla-diseña-gestiona equipos-comprende el modelo de negocio y las capacidades de ventas y marketing => comunícalo a los equipos técnicos) que el top-down (perfiles de marketing y ventas que "bajan" al nivel técnico), aunque es cierto que he visto muy malos ejemplos de lo primero, y muy buenos ejemplos de lo segundo... aunque a cuentagotas...
6. Ser capaz de manejar el producto. Y no es ninguna tontería. Algunos gestores de producto tendrán suficiente con poder enseñar demos básicas, mientras que otros deberán llegar más lejos. No creo que un gestor de producto deba saber los valores de todos los parámetros de configuración, o acceder al CVS para comprobar en qué línea está fallando (aunque nunca viene mal :) ), pero bajo ninguna circunstancia se puede quedar en las páginas de diseño... HAY QUE MOJARSE PARA ENTENDER LAS NECESIDADES DE CLIENTES Y DESARROLLADORES.


Continuará...

4/30/2007

La Web 2.0 o cómo separar el grano de la paja

Hace dos semanas tuve la oportunidad de asistir a uno de los eventos más importantes en esto de la web: la Web 2.0 Expo, una de las conferencias de O'Reilly, el "inventor" del rollo éste de la 2.0. Mi posición con respecto a lo de la web 2.0 es que la gente se lía demasiado en discusiones sin sentido: que si esto no es Web 2.0, que si sí, ... Yo lo que veo es que técnicamente el avance ha sido pequeño (lo de AJAX existe desde hace años... nosotros mismos en el 2001 ya hicimos una aplicación que ahora sería un AJAX como la copa de un pino, permitiendo que una barra de tareas en Internet Explorer se comunicase asíncronamente con un servidor para enviar información de utilización de información estructurada del usuario (e.g. rellenado de formularios) para que el servidor socializase esa información (así, otro usuario podría rellenar un formulario automáticamente aunque nunca lo hubiese visto en su vida y aunque los campos no fuesen "semánticamente evidentes"); sin embargo, el cambio de concepto sí ha sido más radical, hacia la parte colaborativa; tampoco nuevo (Amazon, eBay, ... son empresas "1.0"), pero mucho más abierto.

Así que, para concretar: para mí la Web2.0 Expo era el espacio que me permitía saber qué se está haciendo y, con suerte, hacia dónde se va. Ni más ni menos.

¿Y qué encontré? Pues, como dice mi título, un poco de todo.

El grano:
  • Jeff Bezos mostrando cómo una empresa como Amazon puede realizar introspección para entender cuál es su potencial, y darse cuenta que, aparte de vender libros, es una de las infraestructuras sw y hw más potentes en la actualidad. Una de sus líneas ahora es vender "ancho de banda" y "espacio" para las operaciones computacionales que no tienen cabida en tus propias máquinas (algoritmos complejos, almacenamiento masivo, ...). ¿Precio? Miradlo, miradlo.


  • John Battelle con los fundadores de empresas como Digg, SixApart o Excite y JotSpot. Gente joven pero con mucha experiencia, con importantes comentarios para el futuro emprendedor. Imagino que, escuchada más de una vez, sería muy repetitiva, pero a mí me encantó escuchar diferentes puntos de vista acerca de temas como "born to be sold or not", "control de la empresa", "tamaño del equipo", ...





  • La sesión de John Musser, de ProgrammableWeb, con un "estado del arte" de las APIs de Mashups (las APIs que ahora las aplicaciones web publican para que puedan combinarse con otras). Muy bien explicado, con datos muy concretos, sí señor. Aquí hay un resumen de la misma, y aquí podéis encontrar la presentación.
  • Mi experiencia en el stand que teníamos. Primero, estábamos al lado de gente como Google, Yahoo!, Nokia, FAST, ... ; segundo: no paramos un sólo momento, gente que no paraba de preguntarnos qué hacíamos, en qué nos diferenciábamos, ... ; tercero: aunque evidentemente había de todo, esta no ha sido una conferencia de chavalitos queriendo saber si estábamos en SecondLife. Aquí hemos estado hablando con técnicos de empresas, desarrolladores de negocio, gente con problemas reales para los cuáles necesitan una solución; cuarto: la sensación de, sí, estar en el sitio adecuado en el momento adecuado.

La paja:
  • Las empresas de "social networking". De verdad, estoy empezando a ver que ésta es la parte de la Web 2.0 más parecida al crash de finales de los 90. Parece que la Web2.0 no es más que "ponga un foro, digg, o algo parecido en su web, o haga algo parecido". Ya comenté mi parecer acerca de Twitter, pero es que me encuentro con empresas cuyo único factor de innovación es añadir a lo ya existente un wiki, o un digg, o algún rollo así. Ricos se harán, no digo yo que no (ya se hicieron ricos algunos a finales de los 90 con ideas igual de patéticas), pero mi respeto no lo tienen, no.
  • El Enterprise 2.0. La sesión de más interés a priori para mí fue, sin duda, la más frustrante. Para mí Enterprise 2.0 significa salir a la web, colaborar, aprovechar lo que ahora tienes a tu alcance. Para esa sesión, significa: pon un wiki, pon un blog, pon un digg. Comprendo que todo tiene su momento, y que es ya un paso importante para cualquier empresa. Pero no me convence que eso sea Enterprise 2.0. En ese caso, sí que creo que mi empresa tiene un mensaje mucho más innovador y atractivo, lo que hemos venido a denominar "Enterprise Data Mashups" o, como eslogan algunas veces, "Bridging the Gap", aunando la información interna con la externa, sin importar el formato (estructurado, semiestructurado o no estructurado). Y mira que no suelo hablar mucho de lo que hacemos...

A veces, sólo a veces, el desconocimiento mejora las cosas...

Sigo metiendo en este blog algunos comentarios personas relacionados con mi experiencia en la empresa.

En general, siempre he tenido una relación amor-odio con el perfil que he desempeñado en mis diferentes ocupaciones, sobre todo en los últimos años. Mi perfil técnico, aunque cercano a los departamentos de marketing y ventas, junto con mi capacidad (tras unos cuantos años de docencia) para explicar lo que hacemos en diferentes niveles de profundidad, en español e inglés (aunque esto bastante peor), ha hecho que mi carrera haya discurrido por ese punto intermedio. Pertenezco a I+D, y es lo que realmente me gusta hacer, pero la mayor parte de mi tiempo estoy dando soporte o incluso involucrándome en otras áreas. Lo bueno: creo que este perfil "todo-terreno" me ayuda a conocer mejor el por qué las empresas funcionan como funcionan, y mi bagaje es, sin duda, amplio. Lo malo: la falta de especialización me provoca problemas en algunos casos. Si paso mucho tiempo apoyando a negocio, no lo hago entendiendo mejor lo que hacemos, lo que hacen otros, leyendo papers, ...

En este post quería comentar un punto a favor de la especialización que, aunque ya había sufrido en otras ocasiones, hoy ha sido, si cabe, más claro. La estructura actual de la empresa que vende un producto suele ser, a grandes rasgos: desarrollo de producto, ingeniería, preventa y venta, más marketing. Cuando se visita a un cliente, quien lo suele realizar es la gente de venta y preventa. La gente de preventa suele ser gente técnica que conoce el producto lo suficientemente bien como para defenderlo ante un cliente. Cualquier preventa que esté leyendo esto sabrá las dificultades que implica cuando el cliente quiere llegar "muy abajo". Obviamente, si uno no ha desarrollado el producto, o no ha leído toda la documentación, o la documentación no es lo suficientemente completa, la tarea puede ser bastante compleja.

Pero ¿y al revés? De vez en cuando me toca hacer de preventa, por razones varias ;) . En mi caso, el conocimiento técnico no es óbice, ya que, sin haber desarrollado el producto, sí he participado en la concepción, documentación, discusión, ... de muchos de sus detalles. Lo que sí me ocurre es que en algunos CONOZCO DEMASIADO BIEN LA HERRAMIENTA:
  1. Sus ventajas y puntos fuertes, lo cuál me posiciona claramente en el defecto #1 de los preventas muy técnicos: "me encanta esta parte de nuestro software" (no inventado por mí, pero no recuerdo el nombre del libro en el que lo leí :( ). Creo que esta parte la llevo bastante bien, pero no siempre ha sido así.
  2. Sus desventajas y posibles problemas. Esto, para mí, es crítico, pues te lleva a infravalorar las posibilidades del producto en momentos críticos, con lo que: (1) estás nervioso, (2) no te concentras en la explicación, sino que piensas en cómo dar el siguiente paso de la manera más segura posible, (3) te limitas a tí mismo, (4) te sientes mal por infravalorar el trabajo de tanta calidad de tus compañeros... pero sin poder evitarlo :(
Hoy me ha pasado. Razones había unas cuantas, ya que no tuve tiempo material de preparar toda la demo hasta el último momento (no me tocaba a mí en principio, y menos mal que había dejado algo hecho el fin de semana, "just in case"), la importancia del asunto, la necesidad de montar "unos cuantos" entornos para poder mostrar todo lo que queríamos... la cosa es que imagino que la experiencia es un grado, y que las cosas al final nunca salen "genial" o "fatal", pero me quedó un regusto amargo que creo que se soluciona de dos posibles maneras:
  1. Preparar las cosas con tiempo, realizar mútiples pruebas antes de la presentación (o lo que toque), ...
  2. No saber que las cosas pueden ir mal... aaaah, por eso me está costando tanto montar bien en bici!!!!