, turning innovations into defaults, and proving that infrastructure could be both powerful and invisible. If last year was about setting the foundation, 2025 has been about unleashing velocity by removing the bottlenecks and nuances that stand between an idea and a shipped product.

This year, I focused on simplifying the complex. From shifting how we pay for builds to redefining the execution model of serverless compute, the goal was to create a platform ready for the modern era. We are entering a time where humans and AI agents build side-by-side.

The ships for this year have been career-defining: shipping 

 for builds, leading a new execution model with 

. These were not just regular features. They were fundamental shifts in how the web is built and scaled.

However, this review is bittersweet. It marks not just the end of a year, but the end of my chapter at Vercel. But before we get to what’s next, let’s look at how we reshaped compute in 2025.

Unblocking the pipeline: On-Demand Concurrency

We started the year by tackling a legacy constraint: build slots. For years, teams had to buy slots, which naturally created bottlenecks from time to time. If you had 5 developers or agents pushing code, but only 2 slots, you can see the problem if they all want to push changes at the same time.

 to solve this. It is a simple but incredibly powerful change to our pricing model. Instead of provisioning capacity by buying slots, you simply access high concurrency and pay on-demand per minute.

This shift was critical. In a world where AI agents are pushing code alongside humans, the volume of concurrent workstreams is exploding. On-demand concurrency ensures that building and deploying your changes never becomes the bottleneck.

Following that, I shipped what is undoubtedly one of the highlights of my career so far: 

I led a new execution model for serverless compute designed specifically for modern workloads. For years, we spent our time optimizing for short idle times and millisecond transactions. We assumed faster responses was always better. But the paradigm has shifted.

With the rise of agents, you now have more idle time, and sometimes you are actually happy to have it. You want to give the LLM time to "think" so it gives you a better answer, or you want to keep a connection open while a function streams a response back. Traditional serverless was not built for this. It penalizes you for waiting as it charges for all resources based on duration, locking your instance regardless of whether the CPU is idle or not.

Fluid Compute changes the equation by allowing requests to share an instance. It brings the efficiency and performance of servers to the scalable nature of serverless. It eliminates the trade-off developers used to make, offering the best of servers and serverless all together.

Aligning cost with value: Active CPU Pricing

Shipping Fluid was a massive step, but true to the philosophy of iteration, it was only the beginning. To truly support these new agentic workloads, we needed to fix the economics.

We fixed this with one of our most ambitious ships: 

The concept is radically fair: you should only pay for what you use. This is critical for agentic workflows. When your function is waiting for an LLM to respond, you are not using the CPU. In the old model, you paid for that wait. Now, you don't.

Regardless of the runtime, when running on Fluid compute, you pay primarily for the resources consumed. If your workload is not CPU intensive, like waiting on an LLM API or streaming tokens back to the user, you are not billed for CPU cycles you are not using. You only pay for the reserved memory. This unified the model and drastically lowered costs, making it economically viable to run complex, long-running agentic tasks on serverless.

While we were refining Fluid, we were cooking something else in parallel: 

We have been running untrusted code securely for years to power our own builds. It made sense to expose this primitive to the world. Built on top of Hive (the general compute platform I’ve been building with the team for years), and powered by Fluid compute with Active CPU pricing, Vercel Sandbox allows anyone to spin up secure environments for untrusted code instantly.

This is perhaps one of the strongest primitives for the agentic era. Whether it is an AI agent generating a UI or a code interpreter running data analysis, developers can now give agents control of a sandbox for every use case. We have already seen the community embrace this with incredible creativity, including projects like the 

, which lets anyone build their own vibe coding platform.

2025 was, without a doubt, one of the greatest years of my professional life. We did not just ship features. We fundamentally changed the economics and mechanics of the platform.

However, as the year closes, so does my time at Vercel.

I have always believed in leaving on a high note, and I am incredibly proud that I am doing exactly that. We have set the bar higher than ever, and the platform is in a stronger position than it has ever been. I am leaving with a heart full of gratitude for the team and the community. I am excited to watch Vercel continue to crush it, but from now on, I will be rooting from the outside.

I have a deeply optimistic view of what the future holds.

2025 in Review: Building for the agentic era

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.

Mariano
Cocirio

Latest

LATEST

2025 in Review: Building for the agentic era

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

On making things happen

Let's
Connect

MarianoCocirio

Latest

LATEST

2025 in Review: Building for the agentic era

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

On making things happen

Let'sConnect

Mariano
Cocirio

Let's
Connect