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.

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

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

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

De ingeniería a producto

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Accept some bugs will slip into production, take calculated risks

It's all about iteration speed

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

Check UI doesn't break for smaller devices

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

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

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

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

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

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

Blog