2023 was a fantastic year, full of shipping and personal growth

. I had my first big wins while positioning myself as a more versatile Product Manager and it set the bar high for what was to come.

Starting 2024, my goal was clear: build on the momentum of the previous year and aim even higher—and this year delivered. From taking full ownership of the compute offering at Vercel to shipping 

, a transformative leap for traditional serverless, the milestones have been amazing. I also led the development and delivery of 

, a long-awaited feature for enterprise customers, and continued evolving 

. This year wasn’t just about meeting last year’s bar. It was about raising it even higher.

My first year at Vercel, starting in March 2022, focused on improving the build and deploy pipeline, and how customers interacts with their deployments. This included achieving a 50% improvement in average build times and releasing key features such as the 

. It was a rewarding year that combined my passion for Vercel’s mission with impactful contributions to its core infrastructure and product.

In 2023, I took on larger challenges by expanding my scope and exploring greenfield areas, launching products like 

, while enhancing deployment workflows. One of the year’s highlights was a major infrastructure overhaul that 

boosted build performance and enabled hardware differentiation

, making it a standout year of innovation and collaboration.

From builds to runtime: Owning the full compute stack

Taking ownership of Vercel’s entire compute offering was a natural progression after managing the builds infrastructure and leading the creation of our compute platform with Hive. Expanding the scope to include everything that happens at runtime—Vercel Functions, Edge Functions, and Middleware—aligned perfectly with the ongoing efforts to improve the developer experience and platform performance.

This expanded focus was all about turning long-developed innovations into the new defaults. 

 had been in beta or development for some time, and my priority became ensuring they were shipped as part of the core offering. These features are no longer optional—they’re now the standard, raising the bar on what a compute platform should deliver and redefining expectations for performance, reliability, and modern web workloads.

Building Hive: Vercel’s compute platform

The major infrastructure overhaul I’ve been working on since its inception in late 2023, now known as Hive, is Vercel’s low-level, untrusted, and ephemeral compute platform, designed to power our builds. From the start, I’ve been responsible for setting the vision and direction for Hive, organizing its rollout, and prioritizing the use cases and benefits that deliver the most immediate value. By focusing on clear deliverables that provide tangible results, we’ve ensured steady progress while maintaining iteration velocity and shipping cadence. You simply can’t build an entire compute platform and wait until it feels “perfect” to ship it, you’ll probably never ship it, you have to be smart on picking workloads, and migrating them to the new platform. Having real customers using the product as early as possible has been critical to validating and improving it.

While Hive has been quietly driving our builds infrastructure since last year, 2024 was the year it stepped into the spotlight with two blog posts: 

. The benefits have been significant: hardware differentiation so customers can choose the right machine size, a 30% improvement in build times and a reduction in provisioning time for push builds, like those required for Secure Compute users, from 90 seconds to just 5. Hive is a product I continue to build and refine, laying the groundwork for even more innovation in the future.

Revolutionizing compute: Shipping Serverless Servers

This year, I had the opportunity to ship one of the most exciting innovations in compute: 

. It’s a game changer for workloads, combining faster performance with significant cost savings. Inspired by the original spirit of Node.js—eliminating CPU idle time waiting for I/O—we’re bringing that philosophy back to the web world, enabling efficient and scalable compute.

To bring in-function concurrency to life, I drove educational materials, organized the beta stages, and engaged closely with customers to validate the savings and gather actionable feedback. I also pushed for a more pragmatic, experimentation-driven approach, encouraging the team to prioritize iterative shipping and real-world testing, including a public beta. By maintaining a tight feedback loop with early adopters, we ensured the feature met real-world needs while refining its performance.

The concept itself is simple but powerful: for example, when an instance is waiting for a response from an external API, a new invocation can reuse the same in-flight instance rather than spinning up a new one. Since compute costs are based on GB-hours, this approach effectively cuts costs while maintaining scale-to-zero efficiency. The results have been incredible, with customers seeing substantial savings and loving the impact. This is the future of compute, and I’m excited to keep building on its success.

Shipping Custom Environments: Addressing customers pain points

 have been one of the most requested features, especially by enterprise customers, and shipping it this year marked a significant milestone. This feature provides flexibility for customers with complex workflows while ensuring zero disruption to those who don’t need it.

Bringing Custom Environments to life was a long and rigorous process. Enterprise customers often have unique needs, underscoring the importance of recognizing that “you are not the customer” and requiring a more thorough and structured product discovery phase. This involved dozens of interviews to deeply understand their workflows and pain points, followed by close feedback loops with early adopters to refine the solution. The requirements and insights gained from this process were essential in delivering the right first iteration of the feature. It also meant rethinking core aspects of how Vercel operates, starting last year with the 

. The result? A feature that has been embraced with enthusiasm and love by our customers.

As 2024 comes to a close, it’s clear that building great products takes time, and there are no shortcuts. The successes of this year—like in-function concurrency, Custom Environments, and the evolution of Hive—are the result of multi-year efforts, iterating on solid foundations and setting new ones for the future. Great outcomes don’t happen overnight; they’re built step by step, with consistent focus and a clear vision.

The seeds planted in past years are now beginning to flourish, and the work we’ve done this year has laid the groundwork for even more innovation. Consistency remains key—not just in what we ship today but in how we build toward what’s next. As we move into 2025, I’m excited to keep raising the bar, delivering impact, and turning new ideas into reality.

2024 in Review: Building, Iterating, and Raising the Bar

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.

Blog