Cuento 1: ¿Cuál es el rol de los equipos de producto e ingeniería?
Responsabilidades CPO/CTO, Preguntas claves al crear un producto
For English version, click here / scroll down.
En una tierra distante… Eva y Luke dirigen los esfuerzos de producto e ingenieria respectivamente en un marketplace de productos orgánicos. Eva es una experta en la distribución de alimentos frescos en Latinoamérica y Luke es un ingeniero de computación con amplia experiencia dirigiendo proyectos exitosos en la industria de telecomunicaciones y banca. Los dos traen habilidades y perspectivas al negocio complementarias🤝.
Eva encontro una oportunidad qué comparte con Luke acerca de construir una nueva funcionalidad. Luke considera que el enfoque propuesto por Eva no es el apropiada así qué discuten los pros y los contras de la misma llegando a un punto medio en donde parcialmente cada uno está conforme con el resultado😨. Desafortunadamente, Luke siente qué Eva no evaluó correctamente los pros y contras dado qué Eva carece del conocimiento técnico y la experiencia cómo él. Así qué decide llevar al equipo de ingeniería a construir el producto cómo él considera es la mejor forma de hacerlo. Como resultado, el conflicto emerge dado que el producto final no fue el acordado😡.
❓La pregunta aquí es ¿Cuál es la frontera entre producto e ingeniería? ¿Hasta dónde llega la responsabilidad del Chief Product Officer (CPO) y el Chief Technology Officer (CTO)?
🗝️Desde mi perspectiva la responsabilidad del área de producto es llevar al equipo a resolver el problema correcto y la responsabilidad del área de ingeniería es construir la solución de forma eficiente. En otras palabras, si el problema se resolvia creando un cohete🚀 y el equipo de producto le dijo al equipo de ingeniería que construyera un submarino, sería responsabilidad de producto❌. Ahora, si el equipo de producto indico qué había que construir un cohete y el cohete en su vuelo falla 💥, sería responsabilidad de ingeniería❌.
Aquí, te explico el porque ese razonamiento:
Empecemos por decir qué él éxito de un producto está en el trabajo intenso y colaborativo de las áreas de producto e ingeniería para resolver los problema de los usuarios. Yo acostumbro a decir qué los equipos de producto e ingenieria son cómo una tijera✂️. Es decir, para qué sean útiles deben funcionar cómo pareja. Ahora para qué está tijeras funcionen bien, necesitan tener un filo afilado, al cual llamaremos “el problema” y unas hojas de alta calidad qué serán “la solución”.
El problema es la chispa🔥que le da sentido al producto. Es la razón por la que el producto tiene sentido, es el dolor de muela 🦷del usuario que no lo deja dormir. Para llegar a entender si un problema es relevante es importante hacerse las siguientes preguntas.
¿Por qué el usuario compraría esto? ¿o por qué lo usaría? 🧡
En este caso nos referimos al valor. ¿Por qué este problema es relevante de resolver? ¿Por qué es importante resolverlo ahora? ¿Por qué el usuario preferiría este producto vs. las alternativas? ¿Los usuarios realmente necesitarían este producto? Un caso latinoamericano para ejemplificar este concepto es Buda.com un exchange de criptomonedas en la región qué resuelve la necesidad de enviar dinero entre EE.UU, Argentina, Colombia, Chile y Perú. Sus usuarios lo prefieren frente a las alternativas porque elimina la burocracia y el dinero está disponible en menor tiempo.
¿El usuario encontrará la forma de resolver su necesidad con esto? ✨
Aquí hablamos de usabilidad. ¿Encontrará el usuario la forma de satisfacer sus necesidades con el producto? Un caso maravillo es Waze. A pesar de no tener los mapas disponibles en sus inicios y entendiendo la necesidad de los usuarios de encontrar información precisa y actualizada sobre el tráfico. Crearon una interfaz qué le permitía a los usuarios construir el mapa habilitando el teléfono para seguir su posición en tiempo real mientras iban conduciendo y habilitar el reporte de novedades en el camino para compartirlo con otros usuarios de la red. El producto erá tan sencillo y útil, que rapidamente fue adoptado y luego comprado por Google en 1.100 millones de dolares.
¿Nuestro equipo de ingeniería puede construir esto? 🧱
Aquí abordamos la viabilidad. Vamos a decir qué queremos construir un producto qué tome información en texto y entregue respuestas al estilo Chat GPT. ¿Si tenemos un equipo adecuado de ingenieria podría utilizar la tecnología disponible y replicar algo similar?. Es probable. Ahora, ¿es posible entregar la misma calidad de respuestas?. Aquí es donde todo se pone más complejo, el entrenamiento de estos modelos toma tiempo y dinero. Seguramente una cifra de más de 9 números en USD. Depende de los recursos de tu compañía si está sería una alternativa viable o no.
¿Cómo este problema encaja con los objetivos de negocio? 💵
Ahora tendremos en cuenta la pertinencia para el negocio. Es decir, ¿construir este producto contribuye al cumplimiento general de las metas negocio?, ¿cuales son las variables qué va a impactar?, ¿cómo está iniciativa compite con las demás?, estas son algunas de las preguntas a considerar.
En cuanto a la solución las preguntas se centran en cómo construir y entregar el producto en las condiciones qué al usuario le resuelva el problema, le sea fácil de entender y cumpla las expectativas de negocio. Algunos ejemplos de ellas son:
¿Cómo deberíamos construirlo? 📐
En este aspecto, se evalúa, el propósito y los requisitos específicos de la solución, así como la compatibilidad de esta tecnología con los sistemas actuales y servicios externos, entre otras variables.
¿Cuál es el trade-off de esta solución? 🤹🏽
Es decir cuáles son esas variables a sacrificar de forma informada por el bienestar del producto. Aquí unos ejemplos:Escalabilidad vs. tiempo de desarrollo ⌛: en algunas ocasiones se puede tomar la decisión de una solución menos escalable pero más rápida de entregar para cumplir con los tiempos de entrega.
Seguridad vs. usabilidad 🔒: al aumentar las seguridad, las interacciones del usuario aumentan así como el esfuerzo cognitivo causando una experiencia con mayor fricción.
Construir vs. comprar 🛒: a veces, existen alternativas en el mercado qué pueden acelerar la entrega del producto. Sin embargo, al comprar un producto la capacidad de personalización se reduce.
Ahora, cómo lo mencione al inicio está pareja de CPO y CTO o Producto e Ingenieria son cómo una tijera✂️. Cada una de ellas no puede existir por si sola. No se puede hablar de producto sin hablar de la estrategia técnica y los aspectos de negocio, cómo no se puede hablar de la estrategia técnica sin hablar de la estrategia de producto y los aspectos de negocio…y colorín colorado, este cuento se ha terminado.
✍️Cuéntame… tu historia/pregunta, ❤️como mejorar.
Tale 1: What is the role of the product and engineering team?
In a distant place… Eva and Luke lead an organic food marketplace's product and engineering teams respectively. Eva is an expert in distributing products in Latin America and Luke is a computer science engineer with a wealth of experience leading successful projects in the banking and telecommunication industries. Both bring complementary skills and perspectives to the business🤝.
Eva found an opportunity to share with Luke about building a new feature. Luke believes Eva's solution is inappropriate, so they discuss its pros and cons. As a result, they reached a midpoint where everyone is partially satisfied with the outcome😨. Unfortunately, Luke feels that Eva does not correctly evaluate the pros and cons because she lacks a technical background and experience like his. So, he decides to lead the engineering team in building the product the way he believes is the best. As a result, conflict emerges because the final product is not what was agreed upon😡.
❓What is the boundary between product and engineering, and what are the roles and responsibilities of the Chief Product Officer (CPO) and Chief Technology Officer (CTO)?
🗝️From my perspective, the responsibility of product department is to guide the team to solve the right problem, and the responsibility of the engineering department is to construct the solution effectively. In other words, if the problem was meant to be solved by creating a rocket🚀, and the product team guided the engineering team to create a submarine, it would be the product team's responsibility❌, but if the product team specified that the solution would be solved with a rocket and rocket crashed during flight💥, then it would be engineering team’s responsibility❌.
Here, I detail my reasoning:
First, product success relies on intense and collaborative work between the product and engineering departments in order to solve user problems. I often say that the product and engineering teams are like a pair of scissors✂️, meaning that they must work together to be effective. In order for these scissors to work well, they need a sharp cutting edge which we will refer to as ‘’the problem”’ and high-quality blades which we will be “the solution”.
The problem is the fire🔥 that gives meaning to the product. It is the reason why the product makes sense, it is the user’s toothache🦷 that doesn’t let him/her sleep. To understand if the problem to be solved is relevant, it is key to ask the following questions.
Why will users buy this? why will they use it?🧡
In this case, we are talking about value. Why is this a relevant problem to solve? Why is it important to solve this now? Why would users choose this product instead of the alternatives? Do users really need this product? A successful Latin American case is Buda.com, a cryptocurrency exchange in the region that solves the need to send money between the USA, Argentina, Colombia, Chile, and Peru. Its users choose them over the alternatives because it eliminates the bureaucracy and money is available in less time.
Will the user find a way to solve their need with this?✨
Here we are talking about usability. Will the user find a way to fulfill their needs with the product? An amazing case is Waze. Despite not having maps built into the app when they were starting, they understood the user’s need for precise and updated information about traffic. They created an interface that allowed users to build their maps by enabling the GPS on their phones to follow their location in real-time while they were driving and at the same time share updates on the road with other users of the network. The product was so simple and useful that it was rapidly adopted and later purchased by Google for 1.1 billion dollars.
Is our engineering team able to build this? 🧱
Now, we are talking about viability. Let’s say we want to build a product that uses a text sentence and delivers answers like ChatGPT. if we have a proper engineering team, can we use the available technology and replicate something similar? It is possible. But, Is it possible to deliver the same quality of answers? This is where everything becomes complex, as training those models takes time and money, certainly in the 9 figures range. Then, it depends on your company if that would be an alternative or not.How does this problem fit with the business goal?💵
Here we talk about its relevance to the business. In other words, how will building this product help the organization achieve its business goals? What are the variables it will impact? How does this initiative compete with others? these are just some of the questions to consider.
When it comes to the solution, the questions center around how to build and deliver the product so the user's needs are solved in an effective and efficient way while business goals are aligned. Some examples of these include:
How should we build it?📐
In this regard, we evaluate the purpose and specific requirements of the solution, as well as the compatibility of the technology with the current and external systems, among others variables.
What is the trade-off of this solution? 🤹🏽
It is a matter of determining which variables to sacrifice in an informative way to benefit the product. Here are some examples:Scalability vs developing time ⌛: in some occasions, you may decide to use a less scalable solution but faster to meet delivery times.
Security vs usability 🔒: to increase security, user interaction increases as well as cognitive effort causing an experience with more friction.
Build vs buy 🛒: sometimes, there are alternatives in the market that can accelerate product delivery. However, buying a product reduces the customization capabilities.
Then, as I mention at the beginning the CPO and the CTO or Product and Engineering are like a pair of scissors✂️ and neither can exist by itself. We cannot talk about product without discussing technical and business strategy, just as we cannot talk about technical strategy without discussing product strategy and business aspects… and with that, the tale is told.
✍️Tell me your … your story/question, ❤️how to improve.