One of my main responsibilities is to make sure things happen, but not just anything happens, to 

. I take responsibility for guiding our products to success.

A hard lesson to learn while growing in scope and caring for larger product surfaces is that you can't be everywhere at once. So, you should empower your team, remove obstacles, and give them the information they need to make good decisions. You are 

accountable for the team having the right context to make the right call

Another failure mode you might fall into and you should avoid is to keep adding things until no more things can be added. Making things is not just adding things on top of things if that makes sense. Your ultimate goal should be to 

make something that doesn't allow you space to remove anything from it

Also, don't forget that you are not managing an engineering project, something doesn't end just because it's implemented. The job is usually never done, you should be ready to iterate on the problem until the problem doesn't exist anymore. You are accountable for solving a problem, not for shipping a solution. And problems evolve over time.

One last thing is that in the process of making things happen, you should build strong partnerships, and empathize with their perspectives (colleagues, customers, etc). But you should also have your own opinion, which should be strong but flexible enough to adapt at the right time.

On making things happen

2023 has been a significant year that deserves some reflection. I've had the opportunity to work on challenging problems with incredible people, which has made this a perfect year.

As a product manager, I have been involved in shipping various exciting things in 2023. These include 

 flows, and a massive change in our infrastructure (this infrastructure change has allowed us to achieve 

hardware differentiation and improve build performance

In March 2022, I began working as a Product Manager at Vercel, which was and remains to be an awesome experience. I have been a massive fan of their work and mission for a long time. In fact, my first application while finishing college back in 2017 was to Zeit.

The first year in my new role was fantastic. I focused exclusively on the build and deploy pipeline, and we made significant progress. We achieved a 50% performance improvement in the average build time and released numerous new features.

At the beginning of 2023, my responsibilities expanded. I not only worked on the build and deploy pipeline but also took on the Vercel CLI and all the entry points for customers to create and interact with deployments in their development process.

The year started strong with a focus on the deployment process. The CLI team and I aimed to improve it for all Vercel users. Meanwhile, in the build and deploy side, we made a substantial infrastructure change to enhance flexibility, performance, and future control.

These efforts led to the release of a new 

, which helps developers understand their build outputs and infrastructure defined by their framework.

 and made initial improvements to streamline development workflows. This allowed customers to have feature parity between the CLI and the dashboard for redeploying and promoting deployments. Additional options, such as skipping the ignore build step during redeployment, were also introduced.

As a cherry on top, we implemented a development experience improvement that allows customers to 

share preview URLs while their deployments are still building

, making the process of sharing new changes more agile.

During this time, another exciting product was being developed in parallel: 

Given my background in Systems Engineering and my interest in helping people write high-quality code, this was a dream come true for me.

We started with a private beta, iterated, and reevaluated our goals. The journey was full of learnings on how to deliver the most value and have a significant impact on people with large codebases and big teams, enabling them to maintain healthier and performant codebases.

Meanwhile, I was still taking care of the infrastructure side and improving the development workflow to ensure a seamless and configuration-less integration of Vercel into existing customers' workflows. This is when we shipped the first version of the Azure DevOps extension, introduced 

, and, as usual, continued to enhance performance.

I found myself working across a broad range of products and problem domains, including infrastructure, static analysis, runs analysis, and streamlining the development workflow to require minimal configuration.

The biggest revelation I had was that it was all about iteration and enabling our customers to iterate faster. This new perspective unified all the areas I was working on: faster builds, healthier code, and fewer workarounds.

With this expanded view, I took on the role of being the product person responsible for an entire division, with the vision of making iteration faster. This new perspective helped shape and ship various initiatives, such as Conformance and Code Owners. Most importantly, it helped prioritize and make trade-offs to avoid spreading ourselves too thin and focus on the most impactful work.

As the end of the year approached, everything started falling into place, providing a satisfying close to the year.

The infrastructure changes we made allowed us to offer hardware differentiation across plans, improve performance for customers, and even provide the 

We successfully launched Conformance and Code Owners, enabling our enterprise customers to develop in a healthier and safer environment. These tools help them make changes with confidence without breaking things.

Significant changes were also made to the Vercel development cycle. Customers now have more granular control over when to build, deploy, and promote. It is now possible to pin deployments during rollbacks and 

create new deployments based on git references

, providing significant development experience improvements.

The main takeaway from 2023 is that building great products takes time, and there are no shortcuts. Sometimes, you have to wait for all the pieces to come together. If your vision is right, they will eventually align. It's important not to stress or lose sight of your immediate future while waiting for this alignment.

That said, it is also crucial to maintain a consistent shipping cadence and iteration speed. Just because things take time doesn't mean you should hide away for months and reappear with a finished product.

For me, my focus now is on closing out Q4, iterating on the released products, and I've also developed an interest in the Interactive Compute side of things after working extensively with Build Time Compute.

What a year, huh?

Cuántas veces has escuchado que los nombres de las variables y funciones tienen que ser en inglés? Que las funciones tienen que ser nombradas de formas específicas?

Si querés programar, programá como quieras. Para programar necesitás tener ganas de programar

. Después el contexto te hará ir adaptándote e irás viendo que es necesario para desarrollarte profesionalmente si así lo querés.

Una vez que arranques a trabajar te vas a encontrar codebases con sus propias estructuras y reglas...vas a tener que escribir todo en inglés en algún momento? Seguro, es un estándar cuasi mundial. Pero que quede claro que es por razones comunicacionales, y porque el código hoy en día se escribe para que lo entiendan también otros compañeros y puedan colaborar.

Pero creeme que a la tabla de símbolos no podría importarle menos la secuencia de caracteres que decidís usar para representar ese espacio de memoria. 

Al fin y al cabo todo se basa en tokens, reglas y cómo se interpretan, mirá el ejemplo de ALGOL68 que soportaba multiples idiomas, o el mismo Scheme con sus paquetes de internacionalización. 

Es más, en un futuro ojalá se logre llevar aún más cerca del lenguaje natural la abstracción que se use para hacer aplicaciones, cosa de bajar lo más posible la barrera de entrada al desarrollo. Así como se bajó con los lenguajes de alto nivel, que son los más populares hoy en día, todavía falta un paso más.

En lenguaje natural y políglota es como espero que sea la programación en un par de años.

Si querés programar, programá

Since I switched from Engineering to Product, I've been more and more conscious of the review cycles. I feel this is due to two main reasons:

As I grow in my career I’m more aware of the importance of these reviews

Since I moved to Product, one of my main problems has been measuring what I’m doing and validating if it’s a good job or not.

On the second point I could write for a while, but let’s simplify it to the fact that when I was working as a junior engineer I was able to sit down and reflect on what tickets or features I have shipped. Once I moved to product management that was a harder attribution to make.

Anyways, here are a couple of tips that so far have been giving me good results across the years, let’s dive into it!

Performance reviews are a continuous process

I think a common mistake is to take the performance review as a one-in-a-year event. It’s not, you should be reflecting on your work and asking for feedback all the time. It can be in a more or less formal way, but your performance review should bring no big surprises.

Something I always like to do is to collect data across the whole year, so when this talk focused on performance arrives, I can simply take that information and give it the required format. I would strongly recommend you to sit down once a week and write some bullet points on what did you achieve this week.

These bullet points can contain data, and you can track certain metrics and how they evolve week to week, but I also encourage you to keep testimonials on how something you did improve someone’s life. Mainly as a product manager this kind of feedback is important to keep it close.

Also, don’t forget to track the positive impact on your team's health and mechanics, and remarkable interactions or show-offs from your soft skills.

You know better than no one else what are you proud of, and what you’d like to improve. Be sure to be clear on it, and take ownership of how you tell your story. There will be things that you’ve probably overlooked, and your manager and peers will remark on them, but the main narrative on what and why you’ve done what you’ve done across the year should be owned by you.

Make clear what are your motivators, where was your focus, and what results you see on those focus points. Also, be aware of what can be done better and, if possible, how you’ve learned from your experience and avoided certain mistakes to happen again.

This will allow you to also highlight things that might be overlooked by your manager. Little improvements that helped to sign a deal, process improvements that have improved the team’s morale and effectiveness. Things you might feel proud of, but might escape your manager’s eye.

Set your success path and be open about it

Your manager will always want to help you to achieve your goals, you should be open about what your success path looks like. Do you want to be promoted? Be open and clear about it, and if you have an expected timeline, then be clear about that too.

This way, you can plan backwards with your manager on what needs to happen in the next years for you to be in the place you want to be. And your manager can fight for your goal when necessary.

Also, your manager can give you a real assessment of how feasible is something like that happening, and align expectations on both sides on what could happen if not achieved or bargain in new objectives.

On performance reviews

Al arrancar en una nueva empresa, o arrancar un nuevo rol dentro de producto muchas veces te podés sentir abrumado. Hay mucha información que absorber, y uno siempre quiere arrancar con el pie derecho, demostrando que puede hacerse cargo de todo y más.

Pero hay que tener cuidado con no estar seteando el escenario perfecto para que todo salga mal. Es importante preparar una base sólida que soporte lo que viene después, y para eso hay que aprovechar los primeros meses para generarla.

En los últimos años pasé por 3 roles distintos de producto, y acá dejo cinco cosas que te pueden ayudar a solidificar esa base inicial.

Sentate con la persona a la que reportás, y pedile de armar un plan. Es importante que el plan lo armen juntos e incluya milestones mesurables. Idealmente con checkpoints a los 30, 60, y 90 días.

De esta manera te ahorrás cualquier mal entendido a futuro, y también tenés un par de objetivos a cumplir. Es importante tener ese foco durante el primer período que quizás no tengas la visión estratégica de la empresa para realmente discernir dónde es mejor que pongas tu tiempo.

Otra cosa a la que te ayuda esto es a entender los tiempos de la compañía, no todos los lugares trabajan al mismo ritmo y es importante que en un rol como el de Product Manager, por ejemplo, sepas cómo navegar las políticas y tiempos de la empresa.

Cosa importante si las hay, conocer a tu equipo. Y por conocer a tu equipo quiero decir conocer a cada desarrollador, manager, diseñador, product manager, etc. que pueda formar parte de tu equipo directo.

Algo que va a definir cómo te desarrollás en el rol va a ser la confianza en tu equipo, y la confianza de tu equipo hacia vos. Es importante que pases tiempo generando ese lazo y entendiendo cómo funciona cada persona.

Vas a ver que hay personalidades que les gusta involucrarse en los problemas desde etapas tempranas, de investigación y diseño; mientras que otras personas se sienten más cómodas involucrándose más tarde. El saber cómo mantener al equipo motivado, y trabajando en cosas que los entusiasma va a ser vital para tu futuro.

Este también es un buen momento para conocer sus frustraciones, y qué esperan de vos. Ver qué creen que funciona bien, y dónde se podrían mejorar cosas.

Puede sonar a obviedad, pero es importante que realmente te tomes el tiempo de conocer el producto. Y me refiero a sentarte y usarlo de punta a punta, leer documentación, entender por qué se han tomado decisiones.

También entender el valor estratégico de cada parte, y cuál es el foco actual. Es importante que te sientas cómodo hablando de la estrategia de la empresa, y que puedas entender por qué es importante cada iniciativa en el que se trabaja.

Mantener la coherencia, alineamiento, y valor estratégico a través de distintos équpos y distintas partes del producto es fundamental para una persona trabajando en producto, es importante que te tomes tu tiempo en internalizar la estrategia que guía el desarrollo del producto.

Acá podés aprovechar a conocer también las métricas más importantes que guían el desarrollo del producto, y cuál es la posición en el mercado frente a la competencia.

Intentá conocer a la mayor gente que puedas en las primeras semanas, como recomendación personal te diría que programes reuniones cortas con cualquier persona que podría ser mínimamente relevante para tu rol, e incluso con personas que no lo sean.

Cuando estoy en esas reuniones de conocer a alguien nuevo de la empresa, siempre intento contestar una pregunta que considero clave: 

qué preguntas puede responderme esta persona en el futuro?

Esta ha sido la manera más efectiva que he encontrado para poder armarme rápido un mapa mental y saber a quién recurrir en cada caso en el futuro, ya que los primeros meses vas a tener más preguntas que respuestas.

Si podés hablar directamente con un par de usuarios, es lo ideal. Preguntale a  la gente de ventas, o de servicio al cliente si te podés conectar como oyente en alguna reunión con un usuario, o a tus compañeros de producto a ver si hay alguna ronda de entrevista a usuarios próxima que puedas sumarte.

También intentá consumir toda la documentación que haya sobre los problemas de los usuarios, tanto que han tenido, como que tienen actualmente. Y dentro de eso fijate qué está más cercano a la parte del producto que vas a estar más en contacto.

Tomate tu tiempo, y no te presiones a estar delivereando features o proponer cambios radicales en tus primeros meses. Es importante que te des un espacio para entender bien la estrategia, las dinámicas, y los problemas.

Lo importante es que estén claras las expectativas, tanto para vos, como para tu manager, y generar una base que te permita después ejecutar el rol lo mejor posible. 

Arrancando en un nuevo rol de producto

When developing products, it's important to make them follow a narrative. It's part of your job as a Product Person to make it happen. You should spend time sitting down and writing the whole picture, and how these new improvements will help your users.

If you can't tell a story with your product, then you might be falling into the build trap, when you are just building for the sake of building. You should be advocating for coherence and cohesion across your product, making every new piece feel so natural that customers can't believe it was not there before.

These stories should be created before any implementation work is done, and should be one of the first steps after you consider something that might be valuable. It's a great place where to get early feedback and key strategic alignment from relevant folks.

A good story should be independent of the technical solution itself, it should convey the value provided, and ease communication across multiple stakeholders.

The narrative goal is to help all of those stakeholders to align and understand the impact of solving this problem, and the newly open possibilities. By enabling everybody to take action and provide feedback, you are targeting a broader audience than the team working on it.

It also helps you to avoid becoming a machine that ships isolated features. Making multiple narratives with different scopes is helpful in keeping alignment and consistency. It provides everybody with an understanding of why something has been prioritized and how it fits the global strategy. 

In the end, your product should be one big story that can be inspected into multiple smaller narratives that makes sense in themselves and together create an even better story.

You should be writing more stories

This is one of the hardest pills to swallow. You are not the user, as simple as that. Even when you think you know a lot of stuff about your user, even when you've spent hours talking with the users, watching the users use your product, and learning about their problems...you are not the user.

This is a mistake that happens a lot within organizations, people start to think they can think, feel, and act like a user. But that's usually (99% of the time) not the case.

You know too much about your product, and you are probably using it in a way no other user would use it. It's really hard to play the user role, you should focus on empathizing with the user rather than trying to take their role.

Sometimes we think we are the user, and we think we know what the user wants, but what we are actually doing is building what we are missing when using the product.

I can give an example of this, I used to work developing an app where you were able to open registers for customers and fill their details in different categories depending on their stage in the funnel. In addition, you would have a notes section that was global to the customer regardless of their stage.

As someone using the app without being the actual user, that notes section was annoying, it was taking about 20% of the screen so we were closing it all the time. 

One day, we had a complaint about the UI becoming too cluttered, we didn't get it, I mean, we were using it and it was quite nice. Until I went to see how one of our users was using our product, they were using it in way smaller screens than us, and with the notes section open all the time as they rely heavily on note taking during calls to then populate other fields. 

We thought we were the users, and we optimized for ourselves. This is a common mistake I've seen around a lot.

As a rule of thumb, you should be always talking more with your users. And you should also probably not call them users. It doesn't matter if you are already talking with them on a regular basis, you can always talk more with them

Talking with them helps you understand their pain points, helps you to prioritize better, and helps you discover things from your product. If you have the chance to talk with them on a regular basis, and you are lucky they actually want to talk with you, don't underestimate this powerful tool.

I would encourage you to even have pretty open calls and just sit there observing how they interact with your product. Checking how they access different screens, how they perform different actions, etc. 

You don't need to have a specific topic to just talk with them, it's great when you have it, but it's also great when you don't and you are just open to learning something new, and discovering how your product is being used.

You should be putting stuff in front of them as quick as possible, and oiling feedback channels. As soon as you can validate, or even better discard, an idea the best.

Your users should be part of your development cycle, they should be involved and their input should be taken into consideration. As simple as it seems to be, you can really improve the impact of your product by focusing on what is really important for them. Or even better, you can save yourself from building the wrong product.

The earlier you get the feedback from the users, the easier it would be to pivot and restructure wrong assumptions.

A final note is also to be aware that it's also your job to filter away noise from the users' feedback. Be smart about what you take, and don't be fooled by two users complaining louder than one thousand users being happy.

It's important you find the balance between user feedback, your product vision and strategy, and the data supporting you when making decisions.

You are not the user

I've been working as a Product Manager for products with a huge technical load for a while, and I love it. First for the backend and Public APIs at 

, and now taking care of Build and Deploy pipes at 

One big challenge that you usually face when working with this kind of product is how you communicate your work, vision, and even projects with people who are not fully embedded in the team or the technology behind those products. 

I've always liked the idea, that when communicating about your product, you should think about what are you enabling with this message. Always 

communicate with the end goal of enabling your receptor to do something they couldn't do before

Translating the enablement philosophy to communicating with colleagues, the main goal is usually enabling them to help with the development of the product. Finding new angles, new use cases, or invalidating assumptions.

But something you can't neglect is that not all stakeholders are technical enough to feel comfortable engaging in those discussions unless you put your part in including them. Sometimes 

you can be losing great resources just because your communication is excluding certain folks

 and working against your product's success.  

This one might sound trivial, but always focus on what's the value for the customer when communicating recent changes, or current projects. Try to not fall into deep technical details, you can add it for whoever is interested, but to the broader audience try to keep it focused on their day-to-day vocabulary and metrics.

It's easier to understand that you'll be working on reducing the time to connect to a call, rather than on making the service 

Tying your communication to the value perceived by the customer

 is generally the best way to communicate with a broader audience.

This can help a lot to open communication about for example, how relevant is that work for your user base, if there is some dealignment between organizations on what are we focusing on, or even enable a customer success folk to update a customer having issues with the time to connect to a call that an update is coming.

you should advocate for making your efforts tangible

. Try to communicate specific examples, and avoid being vague. It's really nice having a concrete specific example instead of an abstract explanation.

What do I mean? For example, if you are improving the building time, besides communicating that it has been improved and the order of magnitude. It's always a good touch to go with specific numbers on how much it affected particular customers.

It's easier to empathize with a specific user you've been following their pain, and seeing how much easier their life will be. It also opens the door to better and more compelling communication with your customers.

Something I'd like to close with is that this is a bi-directional relationship, you should also do the same the other way around. You must always be clear with your more technical folks, on what is the value for the customers when they work on something.

Mapping your current work into customers' value is a key factor to keep the team focused, you should do it frequently. Ideally, 

your development culture should be heavily focused on the customers

. With empowered engineers who can make decisions based on improving customers' life.

Communicating technical stuff with broader audiences

Time to market is really important when developing a new product, or feature. Delaying your release usually brings more pain than shipping something not fully refined, and iterating over it.

That's why most successful teams usually ship fast, but then iterate even faster. The key here is on shipping the right thing initially, which will gain you the market so then you can iterate on actual users' feedback.

How do you define something as shippable?

One of the main problems when trying to ship fast is how you flag something as shippable. You can easily fall into a pit of reiterating internally and never ship anything.

Everything starts with the problem definition, you need to be able to define your problem in a way that it's easy to say when it's solved. Ideally, you should define it in a way that you can check boxes and once all boxes are checked, then the problem is solved.

When defining the problem, and what needs to happen in order to have it solved, you need to abstract yourself from the solution. Think about what the users should/shouldn't be able to do. And don't be afraid on being too strict on what means to have the problem solved.

It's important that everyone is on the same page regarding when something can be shipped. This means getting everybody's buy-in on the problem definition, that's why usually the crafting of this list that determines a problem being solved is a collaborative effort across different teams.

It's equally important to have a clear vision and next steps, even when everybody agrees on what needs to be done to ship, it must be clear if there will be next steps, and their priority.

Define what you wanna get from shipping now

When shipping, you must also have certainty on what's your goal. Beyond solving the initial problem, is there something else you want to clear out? It can change from ship to ship.

You might want to test an assumption, check usage data, or even learn how users interact with certain kinds of features to define monetization or challenge your current roadmap.

By having this clear, you can also get a reduced set of users you want to ship first to. Here's the time to play with some smart rollouts trying to minimize the risk, while maximizing the learning when shipping something that you don't have full certainty about.

Being ready to iterate is important, that's why you need to have clear feedback channels for your users. Also, you need to follow closely all the feedback from your users, and take it as input when iterating.

Something that should be always clear is what's the value of the initial ship, and how it solves a problem. You need to overline its value and make clear that future iterations will add on top of it. But also be ready to rescope some stuff that maybe was not well defined or is not actually solving the problem.

Don't forget to also set up monitoring where you can keep track of vitals, it's important to track relevant information that will also be valuable input for future iterations. These metrics should be related to the problem, and not to the usage of your solution.

Shipping faster 🚢

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.

Blog