un artículo sobre mi transición de ingeniería a producto

. A partir de los comentarios y mensajes de ese artículo, hoy vamos a hablar un poco de qué hace un product manager.

Cabe aclarar que esto es una introducción sin entrar en mucho detalle. Si te interesa charlar más a fondo, no dudes en mandarme un mensaje!

Bueno, para empezar es un contribuidor individual. Qué significa esto? Que un product manager no tiene personas a cargo de manera directa. Como product manager se genera un liderazgo por influencia y no por autoridad.

También vale la pena aclarar que no es necesario tener un perfil técnico para ser un product manager. Hay product managers de todos los perfiles que puedas imaginar, generalmente depende más que nada del dominio en el que trabajen, ya que como product manager tenés que ser un experto en el mismo.

El foco del product manager va a estar más en la estrategia y en que los equipos estén trabajando en el problema indicado, no tanto en el crear las soluciones. Como product manager tenés que estar obsesionado con el problema, y no con una solución.

Un product manager pasa la mayor parte de su tiempo definiendo en qué se debe trabajar y por qué se debe trabajar en ello. Y para hacer esto necesita principalmente de dos cosas:

Hablar con personas que usen el producto para conocer sus problemas y así poder encontrar oportunidades

Analizar información de todo tipo para poder sacar conclusiones y priorizar acorde

También algo no menor es que como product manager no se debe perder de vista el negocio, el decidir en qué trabajar y por qué trabajar en eso tiene que poner en la balanza también el tiempo que se tarda en recuperar por ejemplo la inversión en solucionar un problema.

Otra responsabilidad importante ligada a lo anterior es reforzar el foco y refinar la estrategia de los equipos. Qué quiere decir esto? Ser claro con toda la organización en qué se va a trabajar y las razones para hacerlo, poder justificarlo, y de esta manera permitir a los equipos trabajar en un foco concreto con un marco que les permita autonomía.

Es vital que los equipos estén de acuerdo en que el problema que se va a atacar es el indicado, y que puedan tener el espacio necesario para resolverlo con el menor ruido e intervenciones posibles.

Y finalmente, también es parte del rol el funcionar como pegamento. El rol varía mucho de equipo a equipo, y empresa a empresa. Las responsabilidades también. Lo importante es ser claros en qué es responsabilidad de uno, y qué es responsabilidad de otro.

Algo que siempre es recomendable es sentarse con contrapartes de ingeniería, diseño, marketing, u otros equipos relevantes y dejar en claro qué espera uno del otro. En mi caso que siempre trabajo con productos tecnológicos es muy importante la relación con los managers de equipos de ingeniería, y con los desarrolladores. Nunca hay que dar nada por supuesto, e iterar en las dinámicas de trabajo.

Entrar a producto siempre es difícil, es un rol relativamente moderno y poco definido si lo comparamos con roles dentro de ingeniería y diseño por ejemplo. Esto va mejorando, pero todavía sigue siendo no trivial.

Mi recomendación siempre es hacer una transición interna, esto te da la ventaja de ya conocer el espacio de problemas y ciertas dinámicas internas. Si realmente tenés ganas de hacer una transición interna, mi mejor consejo es que empieces a tomar responsabilidades de producto desde tu rol actual, y ser claro con tu manager de tus expectativas.

Si esto no parece una opción viable, últimamente han aparecido muchos programas de Associate Product Manager (APM), principalmente en grandes compañías tecnológicas. Estos programas lo que tienen de bueno es un camino ya diseñado con mentorías y gente acompañandote en el proceso de entender este nuevo rol de una manera más incremental.

Product manager en general es un rol que todavía se está definiendo, y varía mucho de empresa a empresa pero hay ciertas cosas en común, pero lo importante es siempre mantener el foco en el problema, y adapatarse a lo que necesite tu equipo.

Qué hace un product manager?

Para dar un poco de contexto, mi nombre es Mariano, trabajo como Senior Product Manager en 

Este artículo es un artículo personal, sobre mi transición de ingeniería a producto, y dentro de producto desde el primer rol hasta encontrar un nicho donde me sintiera cómodo. 

Decido hacerlo en español ya que en su momento me costó encontrar historias en español sobre esto, e invito a cualquiera que esté interesado en producto a mandarme un mensaje. Siempre estoy abierto para hablar sobre producto, ingeniería, y diseño.

Antes de pasar a producto, como muchos, pasé por ingeniería. Mi paso fue tanto académicamente como profesionalmente. Estudié ingeniería de sistemas, y trabajé de frontend developer por un par de años.

Ya desde muy chico me gustaban las computadoras, pero nunca había programado nada. Mi primera interacción con la programación fue en la universidad de la mano de Pascal.

Durante la facultad empezó a interesarme cada vez más el por qué estaba desarrollando algo, que el desarrollarlo en sí. Me costaba programar sin una razón o aplicación real.

También me empezaron a interesar cada vez más las problemáticas de otros desarrolladores, y el crear herramientas que ayudaran a ser más eficientes a la hora de desarrollar. En ese momento nunca había escuchado del rol de producto más que el Product Owner de Scrum en las materias de metodologías ágiles.

Arranqué en Startup Boost, una empresa que hicimos entre amigos en Argentina, trabajando para empresas de afuera. En ese momento se necesitaba que alguien programe un proyecto en React, así que arranqué con React y Next.js.

Me interesé mucho en Next.js y empecé a aportar ejemplos y ser activo en la comunidad, mientras que aplicaba a trabajos fuera de Argentina para después de recibirme. 

Así fue como me llegó una propuesta de Medbelle, una startup en Alemania que había levantado una ronda seed y buscaba migrar su aplicación de Meteor a Next.js.

En esta empresa pasé un año y medio desarrollando con Next.js. Pero lo más importante fue el ganar experiencia en un rol multi-función, ya que éramos tres ingenieros sin diseñadores y con un product manager que era su primer trabajo en el área. También era mi primera vez viendo a un rol de producto en acción.

Mientras trabajaba en esta startup me pasó que cada vez me interesaba más y más el por qué trabajabamos en algo, y el influir sobre qué era en lo que había que trabajar. Hasta que un día me propusieron pasar a producto.

La realidad es que ya hacía un tiempo venía tomando responsabilidades de producto, ya que al ser un equipo tan chico el ambiente se prestaba para eso. Cada uno iba tomando responsabilidades de lo que más le interesaba.

De todas formas el pasar a producto fue una transición dura, de golpe ya no estaba en un ambiente que me era conocido. Principalmente ya no estaba seguro de cómo medir mi performance ni impacto.

El primer año fue aprender a los golpes, armar el primer roadmap, y ver cómo ese roadmap no era viable. Perderse en problemas chicos ignorando el panorama general. Construir features que no eran adoptadas porque no era lo que el usuario necesitaba.

Durante ese primer año tenía muchas ganas de dejar producto y volver a mi lugar seguro en ingeniería, yo sabía que podía programar, y sabía cómo medir mi valor dentro de ingeniería.

Después de 2 años en esta startup, ya afianzado en el rol de producto, empecé a sentir que quería algo diferente. Estaba trabajando como producto en un rol de B2B dentro de la industria de la salud, sentía que extrañaba el lado más técnico.

Me propuse volver a algo más técnico pero desde el lado de producto, ya que mi motivación seguía siendo el 

. También quería probar que los conocimientos de producto que tenía eran transferibles a otros dominios, y a otras empresas.

Así fue como tomé un rol en GoTo (ex LogMeIn) para encargarme desde producto a guiar una unificación del backend de múltiples productos, y la creación de una nueva API pública para sus servicios de colaboración.

En el paso por esta empresa me di cuenta de algunas cosas:

Había encontrado algo que me gustaba, ser product manager de productos técnicos 

Extrañaba el ritmo de trabajar en una startup, las estructuras de esta empresa no me resultaban cómodas

Me costaba trabajar en un producto que no podía empatizar con el problema que intentaba resolver

Después de esta experiencia me propuse el buscar una oportunidad en un lugar donde estuvieran resolviendo problemas que a mi realmente me interesaran y con los cuáles pudiera empatizar.

A mi desde un principio siempre me había interesado el mejorar la experiencia de los desarrolladores, y el bajar la vara de entrada a nuevos desarrolladores. Por esta razón, como dato, ya en 2017 había aplicado a Zeit sin suerte como primera opción tras terminar la universidad.

Así fue como terminé aplicando a Vercel, y este año sumándome como Senior Product Manager, con foco en el proceso que sucede desde que se genera un cambio en el código, hasta que los cambios se ven reflejados en los archivos desplegados (Build and Deploy). 

En mi caso el pasar de ingeniería a producto fue algo muy natural, pero a su vez también trajo muchas dudas sobre si no me convenía quedarme en ingeniería que estaba cómodo.

Como consejo a otras personas en esta situación, les diría que intenten, y que no se desanimen si al principio las cosas no salen. Sigan buscando su nicho, y su propio product-market fit dentro de la industria.

De ingeniería a producto

 about big tech not relying on multiple pre-production environments. Many people were surprised about it, but to be honest, it's not something unimaginable.

More and more teams are prioritizing iteration speed, and quick feedback cycles to improve their products. 

And one proven mechanism to do it is by getting rid of pre-production environments, in favour of better monitoring, alarming, and rollback tools.

One of the main reasons I hear is to avoid bugs going into production, they hope to catch them earlier in the funnel. By doing that, you avoid disrupting your users' experience due to a bug.

Another reason frequently heard, is to ensure the stability of production, you don't want to have an unstable production environment. With a pre-production environment, you can really be sure that after you promote, things will remain in good shape.

In the end, it's all about confidence. Confidence that the changes you are implementing won't have any undesired side effects on your users, degrading their interactions with your app.

But in order to achieve that confidence, you are introducing new costs into your pipeline. Costs that will also affect your users.

Besides the obvious costs you'll incur such as maintaining the infrastructure you'll need to have those multiple environments. You'll be also taking a hit on iteration speed.

Every change will take longer to be in the hands of your users, which means you are increasing the time it takes for a user to perceive value, give feedback, and use that feedback to iterate on your product.

If you are following me, you can do the maths. All this extra time will start adding up in each iteration. Making you, probably, iterate considerably slower.

Nowadays, iteration speed and faster feedback cycles are keys to successful product development. A clear example of it is Figma, a really vibrant product that iterated at a really nice pace while hearing their community.

One way to make massive gains in iteration speed is by deprecating most of the pre-production environment.

When you think about disabling pre-production environments, you might feel like it will come at the cost of quality. But that's not necessarily true.

You can speed your iteration speed and keep the quality by having the right setup. The key parts to doing it are:

Having a good local environment, so the team can make changes there and catch the most obvious things (local environment doesn't necessarily mean in their local machine, it can be an isolated server for example)

Setting up CI/CD systems to catch obvious regressions. This must include having updated tests all the time and reinforcing the code review culture across the teams.

You have to accept the fact that bugs will happen, but it's all about how you react to them. Once you've accepted that, it will be easier to increase your iteration speed.

Getting a good system for on-call rotation, and clear runbooks on how to tackle different problems, or how to debug/rollback certain systems is important to increase the team's confidence when merging changes.

You need to take calculated risks, and you should know which kind of bugs can get slipped into production, but you also need to have mitigation plans. 

Merging into the main branch doesn't mean you are releasing it to all of your users. You must have some kind of flagging system in place to allow you to perform a smart rollout.

This way, you can also merge into production but only enable it for selected people in an internal release, and manage early access programs in a more agile way.

Also, you can be smart on how you start enabling new high-risk features, such as a huge change in how you process certain data that might lead to a regression, by regions or volumes of users.

One of the most important things is that you are required to be good at monitoring and alerting. This will give that extra confidence to your team to rollout stuff.

If you are confident in your system to detect off numbers and then the right people are alerted so rollbacks can be made with almost no friction. Then you are in a great position to start releasing under a flag and ditching pre-production environments in favour of increasing iteration speed.

You don't need to sacrifice quality in order to iterate faster

Take time into setting a proper CI/CD to increase confidence when merging new changes

Releasing behind a flag should be the rule and not the exception

Accept some bugs will slip into production, take calculated risks

It's all about iteration speed

I must say, creating a release plan beforehand has become one of the biggest improvements in my life as a product person. I used to have just a checklist with quite generic stuff like:

Check UI doesn't break for smaller devices

This list was simple, but for simple features, it would make the trick. I would use it on every single feature release but after a while, the features to be released become full products themselves and this naive list was not up to the job anymore.

One of the main flaws was the lack of project-specific information, it was a one-for-all solution. The first improvement was to start linking project-specific items.

It would include links to GitHub, Slack, documentation, etc. But would still be a simple list that tells you if everything was ready for a release. People would usually interact with it in a read-only way, or not interact at all.

This list was failing as a communication tool, it was a personal to-do list that I would check stuff, and communicate when everything was ready. More organized, yes, but still a personal list.

The breaking point was to start writing the release plan from scratch with the team. Separating the release in stages the team found useful (e.g.: internal, private beta, public beta, general availability), and giving the list some context.

What do I mean by context? A little text explaining the reasoning behind this stage, what are the goals it has, and when we expect to have it ready. It would open the door to a lot of discussions, like, why something is marked as a requirement for an internal release when it's not relevant to its goal.

The result is a release plan that is created in a collaborative way between all the stakeholders, anyone who reads it should be able to understand why it is the way it is, and also get enough context to propose changes to it.

Release plans work the best when they are live collaboration tools. When everybody understands what's the current goal, they can focus on unblocking the biggest leverages, and push back unnecessary nuisance.

Don't hesitate in setting some time apart to discuss what the goals for each release stage are, and never forget to write them down and share them broadly.

A release plan should not be a read-only checklist to be filled, it should give a sense of direction and purpose to the team, and set the expectations for the rest of the people.

Release plans...or fancy to-do lists

As a Product Manager, a big chunk of your time is destined for communication, we can go even as far as saying that one of your main outcomes is communication.

You need to communicate the strategy across multiple teams and even departments, you also need to be accountable for the current state of your product with your stakeholders. In addition to that, you need to be clear when setting expectations with your stakeholders and upper management.

With so many touchpoints sometimes it's hard to keep all the people updated on every change we have, or on the current state of the product. Sometimes this can lead to unpleasant moments and a lack of transparency for your stakeholders when for example something can't be added to the roadmap within the current quarter.

Here is when your roadmap should shine and make your life easier, your roadmap should be able to communicate:

To be honest, I prefer when roadmaps also communicate 

This can be achieved by adding a link between the feature or initiative with the strategic goal it's aligned with. I don't ask you to have a full explanation, but it would be great to have, at least a link to see the strategic alignment.

I would also recommend for internal purposes making clear within the roadmap the estimated portion of time dedicated by Product Folks to develop the specification, and then the portion of time that will be destinated for implementation by Engineering. If you have an estimated release date, it can also be here.

It's not rare that things don't go as planned. Implementation got delayed, specification is not ready by the date, the content was not provided, or a new initiative suddenly appeared on the road that needs to be tackled now (regarding the last one, be careful, this should be an exception and not the rule).

It's important that everyone can rely on the roadmap, so whenever a change occurs I would urge you to update it. Sometimes we don't do that, we rely on communication when something happened and we leave the roadmap forgotten after two weeks into the quarter, sometimes roadmaps don't even survive the week after it's presented to whoever was interested in it.

But in addition to updating the roadmap I would also recommend you to keep the previous version of it after any modification, this way you can work backwards in the future and analyze why the roadmap was modified, and even take great insights about bad patterns happening within your organization.

One of the most difficult things could be to make a change in an organization's culture, but sometimes it's worthy to be done. You need to teach your stakeholders, upper management, and whoever this roadmap is relevant to, to read it and rely on it.

A lot of meetings can be skipped by just reading the roadmap knowing it's fully updated, also a lot of requests and decisions can be supported by the roadmap. There you are bringing transparency on what's going on and why something can or can't be done.

It can also help your organization prepare for the future, for example, hirings for a specific period when it's visible the current capacity won't be enough to hit certain key targets.

Roadmaps are great communication tools when used wisely

Roadmaps should answer key questions to your stakeholders

Roadmaps are live documents that should be updated

It's important to build a culture where people can rely on the information in a roadmap

A live roadmap is your best communication tool

It’s been a year since I moved from an Engineering position to a full-time Product Manager role, and I think it’s a good time to talk about the perks and the cons of this transition.

I had the luck of being able to transition within the same company, which allowed me to speed up certain aspects of the new role, for example, I already knew who the stakeholders were, and I also had a good understanding of the product, from a tech perspective, and the internal processes.

Now, without any further delay let’s get into it and talk about the good, the bad, and the ugly aspects of it.

You understand the tech stack and its limitations

This is one of your main advantages, you’ve been probably working with the tech stack that is used in your company, or you at least have an idea of its limitations.

You can use it in your favour by being able to, for example, spot quick wins that will require minimum effort as the stack you are working with has the facilities to perform certain activities.

It also works the other way around, let’s say your digital product is a web application that as a feature, not the core of your business, allows users to do video calls. You are supporting video calls with Twilio and now there’s this idea of adding a screen-sharing functionality; you are probably already thinking about browsers that won’t be supported and analyzing if that will be a problem.

By understanding your tech stack sometimes you can have a quick assessment of feasibility and the real value of an idea in a matter of seconds.

You know what you like to see in a ticket

You’ve been on the other side, you’ve complained about the quality of tickets, you’ve praised tickets for being good, and you’ve also heard your colleagues doing the same. You know what you like/don’t like to see.

Every second you can avoid discussing a ticket just by writing the user story or the acceptance criteria clearly from the beginning, you are accelerating development and hopefully accelerating the shipping of value to your user.

Be critical of your tickets as you were critical of the tickets assigned to you as an engineer. Try to forget all the knowledge about the context of the ticket you have, and think about it as almost a self-contained ticket you should start implementing next sprint. This exercise can potentially improve your communication with Engineering a lot.

You have an idea of how much effort it takes to do something

You should deliver the highest amount of value you can, by spending the lowest amount of available resources. That's something you have probably heard from colleagues, managers, and CEOs.

Your job is not just delivering value, your job is also keeping the business alive. You should be focused on delivering value to your user, but you can't, for example, block the whole engineering team for a quarter doing something that will deliver a minimal amount of value to a reduced subset of users.

Here you have a potent weapon, if you've been working as an engineer for a couple of years, you can probably estimate in your head how difficult is it to build something. This can help you a lot in defining if it makes sense to build something or to look for a workaround, and to create a better prioritization focusing on what actually will deliver the most value while keeping your business afloat.

Managing stakeholders is one of your key responsibilities as a Product Manager, and within those stakeholders, you'll probably have an Engineering team. They'll be finding the right solutions to the problems, and after that executing and implementing them.

Never forget that your responsibility is in the WHY, and WHAT to build. Not in the HOW to build it; so you must be able to communicate well with Engineering, facilitating them to make the most informed decision when deciding on HOW to solve a problem.

To do that, it's useful the fact you can fluently speak about technologies, you also know engineering lingo, and you can use it in your favour to accelerate knowledge transfer to the team.

You need to take a step back and work as a facilitator

Sometimes you discover a problem, you instantly think about a crystal clear solution, and you get tempted to open your IDE and automatically implement it.

You need to keep yourself back and limit your actions to your actual responsibilities, there are people in your team whose actual job is to find a proper solution, and implement it.

If you think that it will take more time for you to communicate the problem than to fix it by yourself. Then it might be a warning flag about some weak points in your communication skills you can improve.

Decoupling yourself from the solution space

This might be one of the hardest things to do. You need to position yourself in the problem space, after spending a good amount of years standing in the solution space it's time to move.

One of the main obstacles to making this change is that customers and stakeholders are usually standing in the solution space. When you ask for feedback or a stakeholder has a request you'll probably receive a solution. It's your job to find out what the real problem is, define it, and then prioritize it.

As a Product Manager, you should not be handling tickets with solutions, your responsibility is to define problems, and the acceptance criteria that in case of being fulfilled ensure the problem is solved.

Value is not delivered just by adding new features to the app

Sometimes your product is not just your digital product, and sometimes value can be delivered without coding. Value can be delivered by process optimization, or by setting a parallel process to take care of it.

It's a common mistake that you try to do everything through the product, you try to keep all your stakeholders happy by providing them value through the product. You are used to probably solving any problem by developing a new feature. This can end up transforming your product into a monster. You always need to have in mind what's your product vision, and what's your core business.

Let's say your company's core business is linking final users and certified plumbers and your vision is centred on providing a simpler, faster, and smoother experience to people with some plumbing problems. As a quality measure, all the plumbers need to have a certification that should be renewed every year. How much does it fit on your product vision to develop a feature that allows plumbers to upload certifications once a year? Can it be handled externally?

You should challenge everything before adding it to your product and try to answer the question if you are building the right product. Some problems might be real problems associated with the company vision, or necessary to keep the company running safely, but that doesn't mean they should all be tackled by adding a new feature

Taking into consideration business factors

This is about the new business world opening up above your feet. Now you don't only care about giving a great experience to your user, you also need to align with business goals, and make sure to provide value in a way it ensures your company hits those goals.

Sometimes you discover a problem, or someone comes to you with a fantastic product idea that could potentially make a lot of customers happy, but you need to take into consideration way more factors to prioritize it. You can't just prioritize because you think something is great, you need to be able to justify why something is a priority.

Also, you'll find yourself working on stuff that is not that exciting, but it's really important to make it and make it right to for example hit that goal and be able to walk in a good position into that funding round.

At this point, you might be asking yourself why am I spotting it as bad. Well, end-to-end ownership is a good thing to have. But it's a double-edged sword, you've been your whole career caring about features from the moment you start thinking of a solution until they are shipped. Not anymore.

The end-to-end definition changes as soon as you move into Product, a feature is not born when you start trying to solve a problem, the feature now is born when you discover a necessity, a pain point, or an opportunity. And now you need to nurture and follow it not just until it's shipped, but until the value is actually delivered to the user, and then check that the value delivery is held across the time.

This might be one of the worse things when you move from Engineering to Product, you'll hear as a joke from experienced Product Managers on customer-facing products that every 10 features only 1 works, but behind every joke, there is some truth.

You'll find yourself working with a lot of uncertainty, generating hypotheses from insights, and trying to make some sense of data. And even working sometimes by gut feeling taking into consideration your knowledge about your users.

At the end of the day, you are trying to define the WHY and WHAT to build. You are working on diminishing the uncertainty, so your team can work with the certainty of building the right product.

It might be hard at the beginning to measure your performance and your progress. I've found it to be not as straightforward as in Engineering.

While I was in Engineering, I could see a clear career path, and measure myself by taking into consideration the problems I was able to solve, the effort I need to put into solving each problem, and from there get an idea of my performance.

In Product, your delivery is communication, and your growth can be measured by the understanding of the problem space and users. This understanding will allow you to make more informed decisions and create a better roadmap that will deliver value by committing just the right amount of resources. But measuring that is not as straightforward.

As an Engineer, should I give Product a shot?

It's something personal, and you should deeply think about it. But as a bit of advice, I would suggest you try it if you answer with a "

When you have a new feature, do you want to understand the problem it’s trying to solve?

Do you care about the impression a solution will cause the user? Are you interested in what happens with a feature after it’s released?

Are you interested in what happens with a feature after it’s released?

While developing do you spend a significant amount of time trying to empathise with the user?

From engineering to product: the good, the bad, and the ugly

This is sort of a personal story about how I switched from Engineering to Product in the last year, focusing on stuff I wish I had known about the Product side of life.

To start with, I think I should give some background info about myself. I finished my master's in Systems Engineering back in Argentina, during my time at college I was focused on software performance and programming languages, I was even applying to start a PhD and continue in the academic world.

After doing some mandatory internships to get my degree I found myself really self-involved with Frontend Development and mostly curious about 

 This leads me to pursue a career as a Frontend Engineer, but after a couple of years I realized I wanted to be even more involved in

so I ended up transitioning to full-time Product Manager.

Product Management is harder than expected

And don’t let anyone tell you differently, expectations are always high and you need to please multiple stakeholders while carrying the vision of the product. You’ll find yourself switching from really distant topics every minute, from the report about tracking issues from BI to the yearly vision with your CEO, then followed by a discussion about a feature that will be released in 2 hours. And all this can and will happen in a short period.

You’ll find yourself running from meeting to meeting, not finding time to do what you consider your time. It’s not strange to start struggling and find yourself working long hours, even working on the weekends. You need to learn how to organize yourself and organize your meetings, be prepared for every meeting, set goals and optimize them, every minute counts.

Prioritizing the sprint is important, and adding cool new features to the backlog is important, but none of this can happen if you don’t have happy stakeholders across the company, you need to be the bridge between the product and the rest of the departments. Your stakeholders need to be informed of the status of the product or about any project that involves them

When I was in Engineering my deliverable was my code, which was translated into implemented features, now my deliverable is communication. As Product Manager, you are in charge of delivering features and reinforcing the vision of the company while you build a meaningful product, the deliverable for this ends up being the communication between parts involved in building this. The reports with the reasons why you need a feature, then the reports about that feature usage, also the research that validates the effort and so forth.

Coming from an Engineering background sometimes you can underestimate the importance of the business side, that’s a mistake, it’s pretty important to understand how the business works, not just for your company, but also for your industry. You need to dedicate time to understanding why certain business decisions are done and to be able to challenge them and make your own in some cases.

There are way more things I wish I’d known in advance, most of them related to the necessity of understanding your users, and following certain processes, but I think those are the 5 most important ones.

I hope it can help someone looking for a switch in their career, and never forget that it’s never too late to switch from one side to another, or even switch back because you realized it’s not what you were expecting.

Five things I wish I’d known before switching from Engineering to Product

Sometimes when you are running some usability test is really hard to get quantitative results, and it's even harder to communicate those results in an effective way to other stakeholders. It's common that when you are running your first usability tests you just get qualitative data, and most of it is just from your analysis of participant behaviours, which is also valuable. But it's not always the most efficient way to communicate results to your coworkers.

That's why it's always useful to run your usability tests with a traffic light report close to you, but first of all, we need to know what a traffic light report is and how it'll help us to transfer information to the rest of the company.

A traffic light report is a visual way to figure out where the users are struggling in our application. The most important information it gives us is 

how hard is a specific task for our users

how hard to use is our application for each specific user

The system is pretty simple, you write down some tasks you are expecting your user to perform, for example: 

. Then you give those tasks to your users and check how easy it was for them to perform them.

If it was clear to them what to do you assign a 

 value to that task. If the participant found some difficulties but was able to perform the task with minimal/no guidance then it's a 

. On the other hand, if he required assistance or it was really difficult for them, then it's a 

You can also add for example other metrics like 

 This metric might be helpful to set the value. For example, if you have run this task several times with different groups you might have a bunch of previous results, so you can assume that a specific task requires about 5 seconds, with this information if some user takes more than 10 seconds to perform it, even if he required no assistance, you might consider him into the 

Let's say we have an online shopping application. This application has a complex signup funnel as it's trying to gather as much information as possible from the user to give specific recommendations once you signed up, and it also has a shopping tool inside where you pick a product and just buy it.

We'll create for our usability test three tasks:

Here is where you need to be smart if you just pick small tasks such as 

 it might be too descriptive to the participant and give him an extra hint, also we don't want to overwhelm them by giving them a big amount of tasks to do.

In this case, for example, we'll divide the first task into four sub-tasks. We'll also divide the other two tasks into three and two sub-tasks. It's important to know how much granularity we want to achieve from this test.

In the following image, we can see the results of the usability test from five different participants, we have it structured in an easy-to-read way, and we also get the overall result for each participant and for each task. It's important to know that some tasks that are really difficult for some participants can result really easy for another participant. Here is when your 

From this test, we can easily get the critical tasks to improve are: 

. As a common pattern, we can also see that we are struggling when the user is required to fill something, maybe it's time to rethink our forms.

These results are easily transferable to any stakeholder without any issue, as we can see the report is pretty simple and self-explanatory, you just look for the red sections to see where are the users struggling. It might be even better if we add the time to perform each task.

Sometimes we struggle to transfer results from usability tests. This is usually because we don't get quantitative results in a proper way and we rely on qualitative results from our observations.

But there are a lot of ways to get easy-to-read reports that can also add some quantitative information to our stakeholders.

Traffic light usability report —and how to communicate your test results

Imagine you are developing a web app, that web app belongs to a family of web apps that shares the same style in their visual components, which means that you are probably going to build a UI library to centralize all your components. That will give you the possibility of changing some behaviour, even the look and feel of specific components across all your applications by just modifying that library.

Now we have an issue: How do we test our library integration with the rest of the ecosystem locally without releasing a version every time we modify something? That’s a common bad practice that you’ll see at some companies, just releasing beta/minor versions to test stuff as they don’t have a local way to test the integration of the library with their apps.

Testing the individual components from your library can easily be done by using for example Storybook, but the integration with the rest of your applications is the tricky part, here is where you should use 

Blog