Showing posts with label lean product development. Show all posts
Showing posts with label lean product development. Show all posts

Monday, July 14, 2025

Refined and Expanded: Custom GPTs for Lean Discovery and Delivery

A while back, I shared how I built a Custom GPT to help teams ship smaller, safer, faster. The goal was clear: challenge teams to focus on learning and delivering value in small, safe steps.

Since then, I've refined that original GPT and expanded the approach.


From broad to focused: eferro Lean Delivery

The original Custom GPT has evolved into eferro Lean Delivery. This version zeroes in on one thing: helping teams deliver value in the smallest, safest, most reversible steps possible — always with zero downtime and minimal risk.

Whether you’re planning a migration, thinking about a tricky rollout, or just trying to keep changes deployable at all times, eferro Lean Delivery is your partner in challenging assumptions and slicing work even thinner.

Check it out here: eferro Lean Delivery

New: eferro Lean Discovery

Alongside Delivery, I’ve created a new GPT: eferro Lean Discovery. This one is all about the upstream part of product work: ideation, problem framing, hypothesis creation, and finding the smallest meaningful experiments.

Where Delivery helps you move safely and incrementally once you start building, Discovery helps you figure out what’s really worth building in the first place. It asks you uncomfortable (but necessary) questions like:

  • What problem are we really solving?
  • What’s the smallest experiment to validate this idea?
  • What signals are we looking for before investing further?

Try it here: eferro Lean Discovery

Where to find them

You can find both GPTs — eferro Lean Delivery and eferro Lean Discovery — in the GPT marketplace. Just search for eferro Lean, and you’ll see them there.


Both tools are built on the same spirit:
Software is about learning. The faster (and safer) we learn, the more impact we create.

No tracking, no hidden agendas — just simple tools to help teams focus on what matters: delivering value continuously, with confidence and calm.

Sunday, June 15, 2025

Built a Custom GPT to Help Teams Ship Smaller, Safer, Faster

Most teams build too much, too early, with too much anxiety. They optimize for perfect architecture before users, comprehensive features before learning, elaborate processes before understanding real constraints.

The result? Endless discussions, delayed releases, building the wrong thing.

So I built: 👉 eferro Lean – your no-BS delivery copilot

A Custom GPT that works with any product development artifact—PRDs, tickets, code reviews, roadmaps, architecture docs—and asks the uncomfortable, helpful questions:
  • "What's the smallest shippable version?"
  • "Do we actually need this complexity right now?"
  • "What if we postponed this decision?"
  • "How can we make this change in smaller, safer steps?"
Perfect for anyone building products: developers, PMs, designers, architects, team leads.


Use it to:
  • Slice big ideas into vertical experiments and safe technical steps
  • Plan parallel changes, expand-and-contract migrations, or branch-by-abstraction
  • Challenge bloated PRDs or over-engineered solutions
  • Turn risky releases into incremental, reversible deployments
It challenges assumptions, slices features into experiments, and guides you toward the last responsible moment for decisions. Questions that create momentum instead of paralysis.

Software is a learning exercise. Every feature is an experiment. The faster we test hypotheses safely, the faster we learn what creates value.

No tracking, no upsell, no agenda. My only intention is to share what I've learned and keep learning from the community.

If it helps one team ship better—with less stress, more learning—that's enough.

Saturday, November 30, 2024

Evolving Solutions for Maximum Impact

In Lean Software Development, the way we approach solutions defines our ability to deliver impactful results efficiently. Instead of breaking down a predefined solution into small increments, Lean encourages growing a solution incrementally in a guided direction. This is achieved through continuous feedback, ensuring the solution evolves dynamically rather than being constrained by initial assumptions.

Why Feedback Matters

Feedback is the cornerstone of this iterative approach. It often pushes us beyond the boundaries of the original solution, steering us toward unexpected yet more effective outcomes. By letting feedback guide our iterations, we move closer to what truly delivers value.

The Lean Approach to Evolution

Instead of starting with a "decided" solution and slicing it into parts:

We consider a better approach, to begin with a minimal idea, iterate based on feedback, and stop when the solution achieves the desired impact:


Focus on impact, not completion: The solution is "done" when it provides the needed results, not when every imagined feature is implemented.

This mindset shifts the focus from building a large, potentially wasteful solution to creating just what is necessary.

Benefits of Lean Evolution

  • Through this approach, teams can achieve:
  • Faster impact: Reaching results quicker by avoiding overengineering.
  • Minimal code: Writing only what is needed reduces waste.
  • Lower basal cost: Simplified solutions are easier and cheaper to maintain.


Closing Thoughts

Lean Software Development reminds us that less is more. By evolving solutions incrementally and guided by feedback, we minimize waste and maximize impact. This philosophy emphasizes efficiency, ensuring that every line of code contributes to value.

Friday, November 01, 2024

Product Engineering in the AI Era

When developing a product, we must ask ourselves what value we contribute if the roles of Engineering or Development are merely seen as implementers. What is the extent of this value contribution? Furthermore, how will this contribution change now that AI will assist us with a significant portion of this work?

Let's refer to the insightful diagram created by John Cutler, which classifies the different types of teams from Waterfall to Product teams.



It's straightforward to discuss the value each type of team contributes to the business. From a business perspective, Waterfall teams or "Agile teams capable of releasing" add limited value and are primarily optimized for software creation (not necessarily for creating impact). 

In contrast, Product Teams are designed for end-to-end impact and maximizing business value.

Considering that AI will automate a considerable amount of the more routine and specialized tasks, it's clear to see the potential impact on these teams.

Teams focused on creating impact, which view software as a means to an end, will be significantly accelerated by AI, while those that are merely "implementers" may find themselves replaced. 

In this context, the importance of product teams and product engineers becomes increasingly evident.

Why should we focus solely on technology and software, when we could instead concentrate on solving business and user problems?

Tuesday, July 16, 2024

El coste basal del software

Traduccion del articulo original Basal Cost of Software
Traduccion realizada por https://x.com/simonvlc y publicada originalmente en su genial newsletter Estrategia de Producto: El Coste Basal del Software
---

En mi opinión, el coste de desarrollo de cada funcionalidad en un producto puede dividirse de la siguiente manera:

  1. El coste directo de desarrollo o coste inicial.
  2. Un coste semanal o mensual únicamente asociado con su existencia en el sistema. Haciendo una comparación con la Tasa Metabólica Basal del cuerpo humano, podríamos llamar a este segundo coste la Tasa Metabólica Basal o Coste Basal.

El Coste Basal se compone de dos partes diferenciadas:

  • El impacto directo en la capacidad del equipo debido a la complejidad añadida (nuevas dependencias, más código para entender, más posibilidades de bugs ocultos, etc.).
  • El impacto en el coste de desarrollo o evolución de otras funcionalidades debido a posibles incompatibilidades, acoplamiento, etc.

El coste inicial

Es el coste incurrido por el equipo durante el desarrollo inicial de la funcionalidad. Incluye el coste desde que el equipo comienza a trabajar en la funcionalidad hasta que el cliente la tiene disponible y comienza a usarla. Por supuesto, este proceso debería consistir en múltiples despliegues y lanzamientos parciales para obtener feedback y hacer los ajustes necesarios...

El Coste Basal

Tras el coste inicial de desarrollo, afrontamos también un coste continuo que reduce la capacidad del equipo para el desarrollo de nuevas funcionalidades (innovación).

Este coste, que continúa con el tiempo y solo termina con la eliminación de la funcionalidad o el fin de vida del producto, es el coste que paga el equipo por la existencia de ese código en el producto.

Es importante tener en cuenta que este no se refiere al coste de hacer modificaciones o corregir errores; se refiere al coste de simplemente tener el código allí...

¿Por qué se da este coste? ¿Por qué una funcionalidad que no evoluciona supone un coste? 

  • El equipo tiene que conocer ese código (dónde está, qué dependencias tiene, qué interactúa con él, cómo está diseñado...).
  • El conocimiento y las técnicas del equipo están en constante evolución. Cuando mejora en cualquiera de estos aspectos, deberá actualizar el código.
  • Cuando el equipo diseña una nueva funcionalidad, el código debe ser diseñado de manera que sea compatible con todas las anteriores y no genere problemas o regresiones. Y, por supuesto, este coste es proporcional a todas las que ya teníamos en el sistema.
  • Algo similar ocurre cuando un nuevo miembro se une al equipo. Este nuevo integrante debe aprender sobre todas las funcionalidades, por lo que el coste es proporcional a su número..

Y lo peor de todo, este sobrecoste es continuo hasta la "muerte" de la funcionalidad. Por ejemplo, hasta el fin de la vida del producto, hasta que ningún usuario la use, o hasta el fin del mundo (lo que ocurra primero).

Evolución del coste de una funcionalidad

Como hemos visto, el Coste Basal de una funcionalidad es más o menos constante durante su vida. Pero cada lenguaje, dependencia o tecnología que hayamos usado en su desarrollo, puede alcanzar un punto en el que ya no es utilizable por cualquier razón (dependencias obsoletas, problemas de seguridad, evolución normal que deprecia la versión del lenguaje que usamos, etc.). Desde este momento, el coste puede dispararse porque estamos obligados a actualizarlo, incluso aunque no queramos evolucionar la funcionalidad.

En resumen, el coste real puede ser representado por el siguiente gráfico:

El problema

Un error común es negar el Coste Basal y considerar que si no se hacen cambios, el coste de mantenimiento de una funcionalidad es cero. Supongo que esto proviene de utilizar metáforas de otras profesiones como la construcción, que no son aplicables al desarrollo de software.


La capacidad no es infinita

A pesar de que la capacidad de un equipo cambia (positiva o negativamente) con el paso del tiempo debido a distintos factores (conocimiento del negocio, técnicas, estrés…), esta es finita.

El Coste Basal acumulado de todas las funcionalidades de las que el equipo es responsable reduce la capacidad disponible para desarrollar nuevas funcionalidades (innovar).

Con el tiempo, podemos observar como la capacidad del equipo para innovar decae rápidamente:

Hasta el punto de que cuando la capacidad se agota, el equipo se encuentra en una situación en la que le es imposible innovar porque pasa todo su tiempo “manteniendo” las funcionalidades de las que es responsable.


O bien reduce su velocidad al desarrollar nuevas funcionalidades, acumulando coste basal, pero a menor ritmo.

Conclusiones

Las secciones anteriores destacan varios principios que debemos considerar para mejorar la eficiencia de nuestros equipos de producto.

  • Debemos minimizar el Coste Basal tanto como sea posible, logrando el impacto deseado con la menor cantidad de código posible.
    • Cuando sea posible, incluso sin añadirlo.
    • Iterando la funcionalidad, partiendo de una solución mínima, para adaptarla lo más posible a las necesidades del usuario.
    • Haciendo el software/diseño lo más simple posible. Debe ser fácil de evolucionar sin sobreingeniería (YAGNI).
  • Debemos eliminar cualquier funcionalidad del producto que no tenga el impacto deseado, eliminando así su Coste Basal.
  • Debemos monitorizar continuamente el código del equipo para detectar la obsolescencia de dependencias, lenguajes y tecnologías para evitar que el Coste Basal se dispare.

Veamos un ejemplo teórico sencillo para ayudar a transmitir el mensaje. Supongamos que un equipo acumula un 1% de Coste Basal por semana, lo que significa que, por cada 100 unidades de producto (código, características, mejoras), añade 1 unidad de Coste Basal. A medida que este se acumula, en 52 semanas (aproximadamente 1 año), el equipo solo podrá dedicar el 60% de su capacidad a nuevas funcionalidades/mejoras (innovación). En dos años, será apenas el 35%. Por supuesto, este ejemplo es una simplificación, pero destaca que negar este coste no es una opción viable.


Recordad: La Simplicidad — el arte de maximizar el trabajo no hecho — es esencial.

Relacionado y referencias

Otros artículos interesantes


Sunday, June 02, 2024

Talk slides / Lean Software Development: A more effective Agile

Yesterday, I had the pleasure of giving a talk at https://eventos.paradigmadigital.com/agile-real-life. My talk "Lean Software Development: A more effective Agile" explained how the teams I have been part of work. We use a combination of Lean Software Development, with Lean Product Development, and Extreme Programming.

I leave the presentation slides here in case someone might find it useful:

Link to the original doc

Related content and references:

Sunday, November 12, 2023

Learning lean/Agile concepts / short videos

 


🆕 Updated on June 24, 2025 — Added a new section on Systems Thinking and Quality with the classic Red Bead Experiment by W. Edwards Deming.

Yesterday, my colleague Cristina Verdi asked for interesting resources to help introduce Lean Software / Product Development concepts.
I passed her a series of short videos that I always use to illustrate certain related concepts. I'm posting them here in case they can help someone.

Resource Efficiency vs Flow Efficiency:
Systems Thinking and Quality:
  • The Red Bead Experiment (14m) by W. Edwards Deming — A powerful demonstration that performance and quality depend on the system, not individual effort. A reminder that systemic issues require systemic fixes.

Tuesday, August 15, 2023

Why Lean Product Development is Essential for Effective Product Teams

 In today's fast-paced and competitive business landscape, it is crucial for companies to have effective product teams that can deliver high-impact solutions. However, many product teams often struggle to achieve this goal due to various challenges and constraints. In this blog post, we will explore the importance of lean product development from the perspective of engineering and how it can enable effective product teams. We will also discuss the role of system architecture in facilitating product delivery&discovery and highlight some common pitfalls that hinder the success of product teams.

The Risks of Product Development

Before diving into the details, let's first understand the risks associated with product development. According to a blog post by Marty Cagan, there are four major risks: value, usability, feasibility, and business viability.

  • Value: Will customers buy or use our software? This risk pertains to whether the customer sees value in the product and is willing to adopt it.
  • Usability: Can users figure out how to use the software? This risk focuses on the user experience and whether the software is intuitive and easy to use.
  • Feasibility: Can our engineers build the software within the given constraints? This risk considers the technical feasibility of implementing the desired features.
  • Business Viability: Does the solution align with the overall business strategy and goals? This risk examines whether the solution is viable from a business perspective.

It is important to address these risks to ensure the success of a product. However, many product teams often overlook or underestimate these risks, leading to failures and wasted resources.

Learning from Industry Leaders

To emphasize the significance of lean product development, let's take a look at some insights from industry leaders. Microsoft conducted research on their own product development process and found that only one-third of their ideas actually improved metrics. Similarly, Amazon's success rate was below half of their ideas. These findings highlight the importance of validating ideas and the need to filter out ineffective ones.

It is crucial to recognize that even highly successful companies like Microsoft and Amazon face challenges in generating impactful ideas. Therefore, assuming that all ideas are great without proper validation can be detrimental to a product team's success.

Not only are many of the ideas not positive, but also the ones that are, require several iterations (with real feedback) to begin generating positive impact.




The Vicious Cycle of Software Development

To understand why lean product development is essential, we need to examine the vicious cycle of software development. In this cycle, a product team has a fixed capacity to develop software. While some features may generate positive impact, others may go unused or fail to meet user expectations. Additionally, the software incurs maintenance costs, such as debugging, monitoring, and infrastructure support (See: Basal Cost of Software).

Over time, the accumulation of software and its associated maintenance costs can deplete the team's capacity for innovation. This cycle hinders the team's ability to focus on high-impact initiatives and leads to a decrease in overall productivity.

Furthermore, the cost of maintaining software is not linear with its size. Doubling the size of an application does not double the maintenance cost; it increases it even more. This exponential increase in maintenance costs further limits the team's capacity for innovation.

Viewing Software as a Means to an End

To break free from the vicious cycle of software development, it is crucial to view software as a means to an end rather than the end itself. Software should be seen as a liability and an expensive asset that should be minimized. The focus should be on maximizing outcomes, impact, and return on investment while minimizing functionality, requirements, and maintenance costs.

By adopting this mindset, product teams can prioritize high-impact initiatives and avoid wasting resources on unnecessary features. This shift in perspective enables teams to make better decisions and deliver more value to customers.

This way of thinking also helps protect against the Feature creep that many products suffer from.

Effective Product Teams and Lean Product Development

To achieve high performance, product teams need to embrace effective lean product practices. These practices involve building the right thing and making the thing right.
Building the right thing involves minimizing the amount of software while maximizing the impact. It requires filtering out unnecessary ideas and focusing on initiatives that align with the overall business strategy. This approach ensures that the team's efforts are directed towards high-impact solutions.
Making the thing right involves continuous learning, hypothesis experiments, and user stories. It requires a collaborative team effort, with everyone involved in the product discovery&delivery process. By working together, teams can validate assumptions, reduce risks, and deliver elegant and impactful solutions.

This process of continuous learning, filtering ideas, continuously experimenting, and delivering in small, safe steps that allow us to learn (through feedback), minimizing waste as much as possible, is what we would call Lean Product Development.



The Role of System Architecture

System architecture plays a crucial role in facilitating lean product delivery. It should be designed to optimize learning, experimentation, and evolution. Here are some key considerations for system architecture:
  • Decoupling Release and Deployment: To enable business-driven decisions, release should be decoupled from deployment. Feature flags can be used to control the release of new features and enable experimentation. This ability to release to a group of users independently enables the team to progressively validate hypotheses with different customer groups, thus managing the risk assumed in each case.
  • Product Instrumentation: The system should be instrumented to gather relevant metrics and operational data. This data provides valuable insights into user behavior and helps in making informed decisions. Assuming that a team can be autonomous and make good decisions when flying blind and without instruments makes no sense. Product-level instrumentation and observability are not a luxury, but an essential part of any effective product team.
  • Operational Data Exploration: It is essential to have systems in place to explore operational data effectively. This ensures that the collected data is utilized to its full potential and helps in identifying patterns and trends. This point complements the previous one; having good instrumentation is useless if it is not easy to exploit for making product decisions or learning about our users' behavior.
  • Safe-to-Learn Environment: The system should provide a safe environment for experimentation and learning. A blameless culture should be fostered, where failures are seen as opportunities for improvement rather than as a cause for blame.
  • Modular/Decoupled Architecture: A modular architecture enables multiple product teams to work autonomously on different parts of the system. It reduces the blast radius of failures and allows for more efficient development and maintenance. This architecture should also allow the team to easily compose new applications, proof of concepts, and demos based on the available modules and components. When the design quality is good, it is much easier to reuse components for experiments and as a basis for new use cases.
By incorporating these architectural considerations, product teams can create an environment that enables continuous evolution, learning, and experimentation. Ultimately, it all comes down to having an adaptable system that we can trust and that is optimized for making small, low-risk changes at high speed.




Depending on the type of system, we can even include architecture decisions that specifically help us experiment and learn more quickly. For example, if it is a product that can be considered a platform, having all capabilities and use cases accessible through APIs can allow us to experiment and create prototypes very quickly using those endpoints from Low Code or No Code systems.

Overcoming Challenges and Maximizing Outcomes

To build effective product teams, it is essential to address common challenges and pitfalls. Here are some key points to consider:
  • Autonomy and Decision-Making: Product teams should have the autonomy to make decisions and generate ideas. Stakeholders should trust the expertise of engineers and involve them in the product discovery process.
  • Technical Debt and Stability: Addressing technical debt and ensuring system stability are crucial for successful product delivery. Without a stable foundation, teams will struggle to innovate and deliver high-impact solutions.
  • Focus on Outcomes: Engineers should shift their focus from technology to outcomes. The value and impact delivered to customers should be the primary concern, rather than the features or technology used.
  • Continuous Learning and Improvement: Product teams should embrace a culture of continuous learning and improvement. This involves validating assumptions, running experiments, and constantly seeking feedback from customers and the system.
  • Collaboration and Ownership: Effective product teams require collaboration and shared ownership. Product managers, designers, and engineers should work together as a cohesive unit, leveraging their respective expertise to deliver high-impact solutions.
  • Praise Continuous Impact and Learning: To generate the appropriate dynamics within the team, we must celebrate the impacts we achieve (changes in user behavior, metric improvements, cost reductions, etc.) and not so much the functionalities we make available (which would only be the means). It is also essential that we celebrate the learnings since they allow us to make better decisions and increase future impact.





Conclusion

In conclusion, lean product development is a critical component of effective product teams. By prioritizing product discovery&delivery and incorporating it into system architecture and practices, teams can maximize outcomes, minimize waste, and deliver high-impact solutions. It is essential for engineers to embrace a product mindset and actively participate in all aspect of the product development process (discovery, delivery). By doing so, they can contribute to innovation and drive the success of their product teams.

If you want to learn more about product discovery&delivery and effective product teams, I recommend reading the following books:
Or if you prefer talks, I recommend these ones:
Remember, product development and continuous delivery go hand in hand. To achieve success, product teams must embrace both and strive for continuous learning and improvement.

References and related content



Wednesday, August 09, 2023

Engineering & Product relationship: random notes

These notes come from my preparation for a panel on technology and product to which I was invited (https://lu.ma/tech-sherpas-madrid). I am publishing them here in case they contribute or help to initiate some conversation. Of course, the panel was great, and it included responses from Isaura Fontcuberta and Rebeca Francisco Najarro that contributed more than my own, but for obvious reasons this post only includes mine since they are the ones I have notes on. The panel was very well conducted by Pedro Pablo Aparicio



Q&A Notes

Let's start, should a product company have two Product and Technology Roadmaps, or should it have a single roadmap?

Ideally a single balanced roadmap. The problem is that in my experience this has many implications. Assuming that there are two different reporting lines (something that we should be able to question), there tends to be an imbalance. By instilling product sensitivity within engineering, this imbalance can be mitigated, making engineering attuned to these sensitivities without seeing them as antagonistic. On a small scale, what has worked best for me is that this division does not exist at all. :) If, out of necessity, there are two roadmaps, there must be clear rules for prioritizing (percentages, for example). (See: https://www.eferro.net/2021/10/it-depends-development-mix-product.html)


Continuing with the topic, taking advantage of the fact that we are talking about RoadMap, who is responsible in the case that there is 1 or 2 roadmaps….

If two reporting lines exist, it becomes a matter of negotiation, although I question the necessity for dual lines in all situations. The final responsibility can vary depending on several factors such as the nature of the product (be it business digitalization, information systems, or deep tech), the business domain's complexity, or our strategic approach. More often than not, Product assumes the final responsibility. Regardless, my fundamental belief is that product development is a cooperative team endeavor. Thus, if two lines exist, the process mandates not just continuous negotiation but, even more importantly, continuous collaboration.


Do these product minded engineers exist? Is it a creation, what would be its definition?

They exist, and I know quite a few. I would also consider myself in that group. Actually, seeing software as a means to achieve an impact (product) is one of my fundamental premises of this profession. Obviously you need to recruit with this mindset in mind, fostering and developing this orientation among your team members. My experience at Alea Solutions and The Motion has been like this, and then at Nextail and ClarityAI. I strive to ensure that my teams adopt this mentality, and my hiring practices reflect it. (See: https://productdeveloper.net/from-software-engineer-to-product-engineer/ https://svpg.com/empowered-product-teams/ )


Do all engineers have to have this predisposition or what would be the percentage within the team or squad to carry it out?

At least the senior people on the team. In any case, I think this mindset can be generated and trained. In some cases where the product is very technical or deep tech, perhaps there wouldn't be as much difference between people who have this predisposition and people who don't.


Do you think it is good that there are two people as leaders of product and technology? Does it depend on the type of product or company? 

I believe that it's not necessary and that it's a problem that has arisen due to the speed of innovation and the immense amount of technologies and the cognitive load that this generates. 

Nonetheless, I firmly believe we need to actively address this issue. It is essential to guide engineers towards understanding that their work's ultimate goal is creating impact, while also helping Product people to grasp the necessity of sustainable engineering processes and practices. From my perspective, the solution is intimately linked with lean methodologies, specifically Lean Software Development and Lean Product Development.


The alignment between Product Manager (PM) and Tech Lead (TL), what is in your experience the best way to achieve this alignment?

Promote cooperation understanding that the result and impact is always at the team level. In that context, the PM, has to learn about sustainable software development and the TL must learn about product/impact and how to work with customers. Both must also learn techniques to maximize impact and develop product in very small steps, with continuous feedback, postponing decisions until the last responsible moment, minimizing as much as possible the Basal Cost of the solution. (See: https://www.eferro.net/2021/02/basal-cost-of-software.html )


Closing / Conclusions

As a closing, can you give your 2-3 tips, based on your experience, on how to have a great relationship between Product and Technology?

  1. 1 Hire/grow product (minded) engineers. It's easier to learn about product/business as a developer than the other way around (plus it's necessary).
  2. 2 Many of the tensions are alleviated by using the same language (centered on business), defining product boundaries, clear acceptance criteria and clearly defining what is a prototype, an MVP, and a normal product (so that it's defined how to make each one).
  3. 3 If performance is incentivized and evaluated at the team level with common objectives, I think it's much easier to align. Of course this implies that the objectives include sustainability and the ability to continue the evolution of the system."



References:

Monday, February 01, 2021

Basal Cost of software

Last update: 2024/04/05

In my opinion, the development cost of each feature in a product can be divided as follows:

  • The direct development cost of the feature or initial cost.
  • A weekly or monthly cost only associated with the existence of this feature in our system. Making a comparison with the Basal Metabolic Rate of a human body, we can call this second cost the Basal Metabolic Rate of a feature or Basal Cost of a feature.


The Basal Cost of a feature is composed of two different parts:

  • The direct impact in the team capacity of the added complexity of this feature (new dependencies, more code to understand, more possibilities for bugs to hide, etc).
  • The impact on the cost of the development or evolution of other features due to potential incompatibilities, coupling, etc.


The Initial cost of a feature

This is the cost/expense incurred by the team during the initial development of the functionality. It includes the cost since the team starts working on the feature until the customer has it available and starts using it. Of course, this process should consist of multiple deployments and partial releases to obtain feedback and make the necessary adjustments…

The Basal Cost of a feature

After the initial development cost, we had this continuous cost that reduces the team capacity for new features development (innovation).
This cost, which continues over time and only ends with the removal of the feature or the end of life of the product, is the cost incurred by the team for the existence of that code and that feature in the product.
It is important to keep in mind that this cost does not refer to the cost of making modifications to the feature or fixing bugs, it refers to the cost of simply having the code there...

Why does this cost happen? Why is there an ongoing cost for a feature that is not evolving?

  • The team has to know that code (where it is, what dependencies it has, who interacts with it, how it is designed...).
  • The team's knowledge and techniques are continuously evolving. When the team improves in any of these aspects, the team should update the feature's code.
  • When the team designs a new feature, the code should be design in a way that is compatible with all the previous features and doesn't generate problems or regressions. And of course, this cost is proportional to all the features we had in the system.
  • Something similar happens when the team has a new member. This member should learn about all the features, so the cost is proportional to the number of features.


And worst of all, this overhead is continuous until the "death" of the feature, i.e., the end of life of the product, until no user uses it, or until the end of the world (whichever comes first).


Evolution of the Cost of a feature

As we saw, the Basal Cost is more or less constant during the life of the feature. But each language, dependency, or technology can reach a point that is no longer usable for whatever reason (obsolete dependencies, security problems, normal evolution that deprecate the language version we used, etc).  From this moment, the cost can skyrocket because we are forced to update it even if we don't want to evolve the feature.


So in summary, the real cost of a feature can be represented by the following graph:





The problem

A common mistake is to neglect the Basal Cost and consider that if no changes are made to a feature, the feature's ongoing cost is zero.
I guess this comes from using metaphors from other professions such as construction that are not suitable for software development.




Non-infinite capacity

Although the capacity changes (positively or negatively) over time due to different factors (knowledge of the business, techniques, stress...), the team capacity is finite.
The accumulated Basal Cost of all the features that the teams own reduces the capacity available to develop new features (innovation).

Over time we can see how the team capacity for innovation shrinks very fast.


To a point where capacity is exhausted, the team finds itself in a situation where it is impossible to innovate and spends all its time "maintaining" the functionalities it already owns (See Fig 1).


Fig 1

Or the team begins to move increasingly slower in developing any new functionality, accumulating basal cost, but at a slower pace (See Fig 2).

Fig 2


Conclusions

The above sections highlight several principles that we must consider to improve our product teams' efficiency.

  • We should minimize the Basal Cost as much as possible, achieving the desired impact with as little code as possible.
    • If possible, even achieving the impact without the need to develop code.
    • Iterating the functionality to adapt it as much as possible to the user's needs and making the solution minimal.
    • Make the software/design as simple as possible. It should be easy to evolve without overengineering (YAGNI).
  • Eliminate or remove any feature from the product that does not have the desired impact, thus eliminating its corresponding Basal Cost.
  • Monitor the team’s code continuously to detect the obsolescence of dependencies, languages, and technologies and avoid the Basal Cost skyrocketing.

Let's look at a straightforward theoretical example to help convey the message. Let's assume that a team generates a 1% cumulative Basal Cost per week, meaning that every 100 units of product increase (code, features, improvements) leaves a residue of 1 unit of Basal Cost. As this cost accumulates, in 52 weeks (approximately 1 year), the team can only dedicate 60% of its capacity to new features/improvements (innovation). In two years, it will be barely 35%. Of course, this example is an oversimplification, but it highlights that denying this cost is not a viable option.



Capacity evolution for a team generating 1% cumulative Basal Cost



Remember: “Simplicity --the art of maximizing the amount of work not done-- is essential.

Related & References


Other interesting articles

Updates

  • 2024/04/05 Included Alex Fernández's feedback 
  • 2024/04/05 Added a simplified example in the conclusions section

Thanks

The post has been improved based on feedback from: