Cómo elegir herramientas que tu equipo de producto realmente usará

Lee la transcripción:

Estamos probando transcribir nuestros podcasts usando un programa de software. Por favor disculpa cualquier error ya que el bot no es 100% preciso todo el tiempo.

Hannah Clark: Rápido, sin contar, ¿puedes decirme cuántos accesos/usuarios (logins) utilizas actualmente en el trabajo cada semana? Si no lo sabes, pon pausa e intenta contarlos. Apostaría a que el número te sorprende. De hecho, un informe de CloudZero de 2024 encontró que el empleado promedio utiliza 36 servicios en la nube al día, y los equipos de ingeniería usan el doble.

Una locura, ¿cierto? Y aquí tienes otra cosa loca que probablemente no te sorprenda. Según el estudio de CloudZero de 2023, más del 53% de las licencias de SaaS no se usan. En otras palabras, a pesar de la necesidad constante de las organizaciones por herramientas que respalden nuestras operaciones únicas, estamos derrochando mucho dinero en herramientas que, por la razón que sea, simplemente no encajan.

Mi invitado de hoy es Moshe Mikanovsky, fundador y principal coach de producto en Products for Good y co-anfitrión del podcast Product for Product. Habiendo trabajado en producto e ingeniería de software desde 1989, Moshe se ha enfocado en los últimos años en ayudar a los equipos de producto a tomar mejores decisiones sobre las herramientas que eligen implementar.

Cabe mencionar que Moshe ha desarrollado un marco integral para ayudar a las organizaciones a elegir las herramientas adecuadas según sus necesidades, incrementando así la adopción y productividad y reduciendo el gasto innecesario. Hablamos de algunos de los aspectos más destacados del marco que te pueden ayudar a escoger mejores herramientas desde hoy. Empecemos.

Bienvenido de nuevo al podcast The CPO Club. Hoy me acompaña Moshe Mikanovsky. Él es el fundador y principal coach de producto en Products for Good.

Moshe, muchísimas gracias por acompañarnos hoy.

Moshe Mikanovsky: Gracias por invitarme, Hannah.

Hannah Clark: Empecemos como siempre. ¿Puedes contarnos un poco sobre tu trayectoria y cómo llegaste al lugar donde estás hoy?

Moshe Mikanovsky: Sí, empecé como desarrollador de software hace muchos años. Durante los primeros 20 años de mi carrera trabajé en el área de ingeniería. Tuve la suerte de trabajar para organizaciones pequeñas. O en el campo, trabajando directamente con clientes y usuarios. Así que creo que ahí desarrollé parte de mi empatía hacia los usuarios y lo que necesitan.

En ese entonces. Y después de 20 años decidí mudarme a la gestión de productos. Eso es lo que he estado haciendo los últimos 14, 15 años. Realmente me encanta. Me encanta hablar sobre gestión de productos. Me encanta ayudar a otras personas a construir productos. Y ver qué hay por ahí, qué funciona, qué no funciona, aprender nuevas metodologías.

Así que todo lo relacionado con producto, es parte de lo que me motiva cada mañana.

Hannah Clark: Aquí estás en buena compañía.

Hoy vamos a hablar sobre algo que creo que le interesa a todos: las herramientas. Cómo los equipos de producto pueden tomar mejores decisiones al seleccionar herramientas para sus organizaciones. Es una preocupación crónica. Y también es un área de gran experiencia tuya. ¿Qué te inspiró a crear tu marco de selección de productos del que hablaremos pronto?

Moshe Mikanovsky: Sí. Tengo un podcast que co-anfitriono desde hace cuatro años con mi amigo Matt Green. Se llama Product for Product.

Y en el podcast básicamente cubrimos herramientas que las personas de producto usan. Siempre fue un interés de nosotros, desde distintos puntos de vista. Para Matt, cuando hizo la transición hacia gestión de productos; para mí, simplemente probando distintos productos en el pasado y eligiéndolos porque nadie más los elegía por mí, así que tenía que hacer el trabajo.

Siempre es interesante ver qué hay disponible. Así que eso es lo que hacemos en el podcast. Y a partir de ahí, me di cuenta, grabando distintos episodios sobre diferentes temas y productos, que existen ciertos patrones entre por qué las personas usan productos específicos, qué les gusta de ellos, qué no les gusta de ellos.

Y cosas así. Así que siempre entrevistamos usuarios de los productos, a menos que sea una startup. Entonces, no hay muchos usuarios. En ese caso llevamos al fundador, pero en la mayoría de los casos entrevistamos usuarios. Así que ya tienen visión, conocimiento sobre cómo se usa, qué funciona, qué no funciona. Y de ahí, acumulo mucha de esa lógica y cosas a considerar, que he plasmado en un solo marco que me gusta compartir.

Hannah Clark: En tu experiencia, si queremos hablar de algunos de los errores que la gente comete antes de entrar en la forma correcta de hacer las cosas o en el marco de cómo hacer las cosas, tal vez de la mejor manera para tu organización. ¿Cuáles son los errores más comunes que cometen las organizaciones de producto al elegir nuevas herramientas y qué consecuencias suelen traer esos errores?

Moshe Mikanovsky: Creo que se trata principalmente de cómo eligen las herramientas y de no buscar una mejor compatibilidad de la herramienta con su organización. Esa sería mi primera observación. Y eso tiene mucho que ver con el marco del que hablamos, pero también con el hecho de no entender realmente las herramientas antes de elegirlas. Es algo común.

Siempre nos emocionamos mucho con la herramienta nueva. La buscamos. Vemos las distintas funcionalidades que tiene. Pensamos que nos va a encajar, pero cuando empezamos a implementarla, puede que veamos que no es exactamente lo que pensábamos. O tal vez solo mirábamos la información de marketing del proveedor en su sitio web, y eso no nos cuenta toda la historia.

O las demostraciones tampoco cuentan toda la historia, o hay ciertos detalles que solo aprendemos al usarla. Así que eso veo muchas veces: no es la mejor opción para la organización y no hay suficiente entendimiento de cómo funcionará realmente el producto para ellos.

Hannah Clark: Sí, tiene sentido.

Muy bien. Repasemos tu proceso de selección. Así que la manera en la que comienza tu marco es identificando problemas, luego priorizando y haciendo una preselección, y después comparando herramientas. Así que hay bastante trabajo previo antes de siquiera llegar a la fase de comparación.

¿Por qué es tan importante este trabajo previo antes de saltar a comparar funcionalidades?

Moshe Mikanovsky: Creo que es igual que para cualquier otro producto. Intento abordar, como persona de producto con tantos años de experiencia, casi todo lo que hago como si fuera un producto. Así que hice lo mismo aquí. Intentar comprender cuál es el verdadero problema que intentamos resolver es realmente importante.

No queremos desarrollar funcionalidades para una solución que nadie usará. Lo mismo ocurre aquí: realmente no necesitamos ciertas funciones si no hay un problema que resolver al respecto. El hecho de que todos hagan algo, no significa que tú también debas hacerlo, o que la manera en que otros lo hacen encaje con tu organización.

Así que ahí es donde el trabajo previo antes de mirar funciones es entender cuáles son los problemas reales que intentas resolver, entender el trabajo que tiene que realizar tu equipo de producto. Para eso necesitas elegir esas herramientas. Y luego, ¿cuáles son las prioridades entre todas ellas?

Sabemos que a veces no podemos comprar todos los productos de inmediato. A veces incluso obtener presupuesto para un solo producto es más de lo que podemos conseguir. Por eso, priorizar cuál es realmente el problema más grande que tenemos ahora, y quizá no siempre es un problema, sino algo que nos lleva mucho tiempo, o hay demasiado desorden y necesitamos ordenarlo, o lo que sea.

Y con base en ese problema principal priorizar y decir, bien, esto es realmente lo primero que debemos buscar. Luego crear una especie de roadmap para elegir productos e implementarlos eventualmente.

Hannah Clark: Ok, ahora quiero hablarte un poco sobre algo que me parece interesante en tu proceso de comparación de herramientas, que es la filosofía de producto, primer criterio aquí.

Primero, ¿a qué te refieres con filosofía de producto y por qué importa? ¿En qué se diferencian realmente las filosofías y cómo afecta esto al encaje de la herramienta en una organización?

Moshe Mikanovsky: Sí, una de las cosas que noté conversando con personas, y también por mi propia experiencia y la de mi co-anfitrión Matt, es que no todos trabajamos igual, ni nos comunicamos igual ni enfatizamos lo mismo.

Y ahí entra la filosofía. Por ejemplo, algunos de nosotros queremos una sola herramienta que resuelva todo. Que tenga todas las funcionalidades necesarias, sin tener que implementar nada más. Pero sabemos que muchas veces este tipo de herramientas no son muy profundas en cada funcionalidad, más bien son amplias.

Otros prefieren tener lo mejor de lo mejor para cada problema específico que tengan. Quieren que se integre todo, pero eso añade complejidad a la solución también. Ese es un ejemplo de filosofía: ¿qué queremos como organización?

A veces es difícil de definir si no sabes cómo trabaja tu organización, quién toma las decisiones; pero es importante recabar esa información porque te ayuda a concretar una herramienta concreta o a reducir tus alternativas. Otro ejemplo de filosofía es si quieres que la herramienta sea flexible o determinista.

Algunas herramientas permiten crear cualquier flujo de trabajo y cualquier campo a medida; son muy genéricas pero flexibles. Cada organización las implementa de manera un poco diferente. Y otras herramientas en la misma categoría pueden ser muy deterministas, te dicen: solo puedes trabajar de esta manera, porque sólo la hemos construido así. No digo que una sea mejor; depende a veces de la etapa de madurez de la organización. Si aún no tienes clara la forma de hacer sprints, grooming de backlog, etc., y compras una herramienta determinista, ésta te enseñará el proceso... pero sólo de una forma, cuando hay muchas.

Quizás cuando la organización esté más madura, estará más cómoda usando una herramienta más flexible. Estos son algunos de los ítems que busco en el marco, incluso antes de mirar funcionalidades, para analizar la cultura, qué tipo de productos encajan mejor, etcétera.

Hannah Clark: Vale. Y hablando de flexibilidad, hay otro criterio por el que me gustaría preguntarte, que es el factor de la ingeniería continua necesaria. Es un tema interesante. ¿Cómo deben los equipos evaluar los recursos de ingeniería necesarios para integrar diferentes herramientas y cómo puede eso correlacionar con el éxito a largo plazo de ese producto?

Moshe Mikanovsky: Sí, esto también entra en cierta filosofía. Mi filosofía al construir productos para mi empresa o al asesorar otras empresas es que los ingenieros deberían enfocarse en el valor agregado que creamos y no reinventar la rueda con cosas que millones de desarrolladores ya han creado en el pasado.

Así que, de la misma manera, cuando agrego funcionalidades a mi producto como mensajería in-app, o analítica de producto, todas ellas existen en las herramientas actuales—por poner un ejemplo. No quiero que mis desarrolladores se preocupen por esas cosas. Prefiero que lo integren sólo una vez con una integración sencilla y se olviden de ello.

Y, luego, que yo como product manager (o quien sea fuera del equipo de ingeniería) tenga la capacidad de definir lo que necesitemos para sacar el máximo valor del producto. Pero hay herramientas dentro de la misma categoría (por ejemplo, mensajería in-app o analítica de producto) que requieren ingenieros de forma continua, porque a veces hay que definir eventos personalizados o el look and feel de los mensajes, etc.

Y para mí (esto es algo personal, no digo que esté bien o mal) eso es una pérdida de tiempo para los desarrolladores. Prefiero que trabajen en valor único para nuestra organización.

Hannah Clark: Bien. Hablando de valores de la empresa y esos factores más únicos. Has mencionado que los factores culturales, como los valores de la empresa y los estilos de comunicación, también pueden influir en la selección de herramientas, y me parece interesante.

Me encantaría oír alguna historia de cómo eso influye realmente, cómo esos elementos menos tangibles pueden determinar qué herramientas tendrán éxito en una organización.

Moshe Mikanovsky: Sí, claro. Te puedo dar un ejemplo de un lugar donde trabajé y teníamos muchos problemas con la comunicación asíncrona. Era realmente frustrante porque trabajábamos en remoto y pensarías que el trabajo en remoto favorece la colaboración asíncrona y que no es necesario estar en reuniones todo el tiempo.

Pero teníamos que estar por defecto casi siempre en reuniones para avanzar. Y también usamos un sistema de backlog, creo que era Jira, pero enfrenta cualquier sistema de ese tipo—cuando defines los épicos quizá en un documento Confluence y tus historias con criterios de aceptación.

Esperarías que la gente lo lea, colabore en los comentarios, trabaje juntos de forma asíncrona. Pero simplemente no funcionaba. Y cada vez que alguien me decía "No vi eso" o lo sacaban sólo en las reuniones, yo pensaba: ¡pero si todo eso está documentado!

Era un problema cultural que impactaba el uso de las herramientas. A veces sentía que iba contra corriente. Tuve que hacer una sesión entera sólo para explicar qué es la comunicación asíncrona y por qué es importante. No recuerdo si incluso sirvió de algo.

Eso es a lo que me refiero: es sólo un ejemplo de cómo tu organización actúa, y una herramienta no va a arreglar eso necesariamente. Una herramienta puede ayudarte a mejorar la comunicación si pones el esfuerzo en usarla realmente. Puede ayudarte a mejorar procesos, si se adapta a la manera de trabajar de tu organización.

Normalmente no funciona al revés, aunque puede ayudar a modificar cómo funcionan las empresas. Pero primero, analizaría bien cuáles son los límites culturales y luego buscaría la herramienta adecuada para eso.

Hannah Clark: Eso tiene mucho más sentido.

Volvamos a las comparaciones de funcionalidades ahora que hablamos del trabajo previo y ciertos factores importantes antes de entrar en lo más detallado que ofrece una herramienta.

Muchos equipos van directo a comparar funcionalidades y precios cuando evalúan herramientas, lo mencionaste antes. ¿Por qué dejas estos factores para el final en tu marco de evaluación?

Moshe Mikanovsky: Principalmente porque no quiero que la gente se centre en lo que puede hacer el producto que usan, sino en los resultados que buscan conseguir.

Las funcionalidades probablemente sean lo más fácil para comparar. Los proveedores dirán que tienen tal o cual funcionalidad. Pero cuando miras en detalle (a veces publicado, a veces no; tienes que buscarlo), descubrirás si realmente es la funcionalidad que esperabas.

A veces usarán distinta terminología, o tendrán precios muy distintos por distintas funciones. Y todo está bien, pero en la mayoría de los casos depende de nosotros, como consumidores, destripar esos detalles y encontrar el producto adecuado.

De nuevo, lo más importante es que queremos una selección orientada a resultados en la implementación de herramientas, no sólo al output (salida). No se trata sólo de poder hacer esto o lo otro, y por eso una herramienta es mejor que otra.

Hannah Clark: Bien, me gustaría abordar quizá el aspecto más frustrante de implementar una nueva herramienta: lograr que todos la adopten y se pongan de acuerdo sobre cómo usarla en la organización.

Especialmente después de tanto trabajo buscando la herramienta adecuada, adaptaciones y consideraciones para asegurarte de que encaja, aún tienes que conseguir que la usen, y que la usen bien. ¿Cuáles son algunas de las estrategias clave para garantizar una adopción exitosa en toda una organización?

Moshe Mikanovsky: La primera es seleccionar la herramienta correcta, o al menos la menos inadecuada que puedas encontrar, porque siempre habrá algún problema. La segunda, el proceso de selección: puede ser complicado. Depende de quién lo lidera, la gobernanza y la propiedad de ese proceso.

Puedes tener detractores incluso en esa fase. Ahora mismo no tengo una recomendación concreta, es algo en lo que sigo pensando y probablemente amplíe el marco en el futuro. Porque si hay demasiadas personas en el proceso de selección, puede tardar mucho; y segundo, ¿hay consentimiento o hay consenso? Es otro tema cultural. Y luego, ¿quién es el dueño de la herramienta? No sólo en la selección o implantación, sino en el día a día. Históricamente, IT poseía las herramientas porque era software que había que instalar, pero luego no se preocupaban realmente de si se implementaba o no con éxito; así que siempre necesitabas un patrocinador que la implementara. Así que la propiedad es importante.

Hoy en día, con product ops podría ser más sencillo para algunas organizaciones, porque veo que encaja muy bien en ese área, sobre todo si quieres estandarizarlo en toda la organización. Así pueden conocer bien las necesidades de los distintos equipos, detectar diferencias entre ellos, y las dificultades que existen para implementarlas y realmente usarlas. Porque pueden ser problemas de personalidad, de proyecto, muchos factores. Y como con cualquier otro producto, igual que a veces tienes que trabajar duro para que tu producto sea bien implementado en los clientes.

Y esto es para productos B2B, todos los productos que hablamos aquí son B2B. Así que si desarrollas producto B2B sabes de lo que hablo y puedes tener más empatía. Si no es así, puede que no conectes igual. No es fácil a veces.

Depende del tamaño de tu empresa, cuántos proyectos, productos, etc. Pero, en resumen, quién toma la decisión, quién es el dueño, qué gobernanza hay, cómo se aceptan las decisiones y cómo avanzan. Incluso puedes hacer iteraciones, no tienes que implementar todo de golpe.

Puedes probar cosas y luego iterar, como harías con cualquier producto.

Hannah Clark: Sí, tiene sentido. Tener un proceso de incorporación un poco más escalonado te da más acceso a tus usuarios en este caso. Así que eso es una ventaja.

Moshe, muchísimas gracias por acompañarnos hoy. Ha sido realmente informativo. Creo que ha sido muy útil porque todos en algún momento tenemos que elegir nuevas herramientas y todo el proceso puede ser un viaje. Así que realmente apreciamos tu orientación. ¿Dónde puede la gente aprender más sobre este marco de selección de productos que has desarrollado y conectar contigo online?

Moshe Mikanovsky: Sí, primero, un placer y gracias por invitarme. Todos pueden conectar conmigo en LinkedIn. Me pueden encontrar por mi apellido, Mikanovsky, y mi web es productsforgood.co. Tengo el marco publicado como tablero Miroverse, enlazado en mi web bajo recursos.

Pero también te pasaré el enlace para que puedas ponerlo en la descripción del episodio. Encantadísimo de compartirlo con todo el mundo. Lo pueden copiar y empezar a usarlo. Hay explicaciones y muchos recursos dentro del marco, como Airtable, una lista de productos con cierta categorización.

Sigue siendo un trabajo en proceso porque siempre encuentro productos nuevos, así que si falta algo, por favor, contactadme en LinkedIn, ¡me encantaría saber de todos!

Hannah Clark: Sí, nos encantaría compartirlo. Gracias por todos los recursos y por tu tiempo.

Moshe Mikanovsky: Un placer. Muchas gracias, Hannah.

Hannah Clark: Gracias por escucharnos. Para más consejos, guías prácticas y reseñas de herramientas, suscríbete a nuestro boletín en theproductmanager.com/subscribe. Puedes escuchar más conversaciones así suscribiéndote a The CPO Club donde sea que escuches tus podcasts.