Stop Building Software. Start Cultivating It

There's a pervasive anxiety in the software industry. It's the feeling of never being good enough, of working late with the constant worry that what you just shipped will explode in production. It's the pressure to go faster, even when you know you're sacrificing quality. It's the frustration of feeling unprofessional, of never quite reaching a state of sustainable, high-impact work. Many of us have been there, living with this constant, low-grade stress.

But there is a better way. There is a path to professional tranquility that also delivers greater business impact. It doesn't come from a new framework or the latest methodology, but from a fundamental shift in how we think about our work. After nearly three decades in this industry, I've come to rely on five counter-intuitive but powerful mindset shifts.

1. Stop "Building" Software. Start Cultivating It.

One of the most damaging ideas I've encountered in our industry is the metaphor of software development as construction. We talk about "building" applications like we build houses. This metaphor is flawed, and it is the root cause of immense dysfunction.

It's harmful because it implies a static, finished product. A house, once built, is largely done. This mindset separates the "building" phase from a supposedly smaller "maintenance" phase. It leads to the absurd but common belief that software must be thrown away and completely rebuilt every few years.

We need a new metaphor: software as something that evolves, like a garden or a living system. It must be cultivated and guided. The single greatest advantage of software is its malleability, its ability to change. The construction metaphor negates this core strength. We are not masons laying permanent bricks; we are gardeners tending to a system that must constantly adapt to its environment.

If we saw the nature of software as something more evolutionary, as something that is alive, as a system that we are modifying all the time... that metaphor seems to me to be much more in line with the real nature of software development.

2. Your Most Valuable Contribution Might Be the Code You Didn't Write

Our industry often rewards the wrong things. Résumés are filled with lists of technologies used and massive projects "built." Productivity is mistakenly measured by the quantity of code written. More features, more complexity, and more lines of code are seen as signs of progress.

The truth is that true impact often comes from simplification. The most valuable work an engineer can do is often invisible. It's achieving an 80/20 solution that delivers most of the value with a fraction of the effort. It's proposing a simpler path that avoids a six-month project. It's having the courage to delete a feature that adds more cost than value.

Every feature, every line of code, has a "basal cost", an ongoing tax on the system. It adds to the cognitive load for new developers, increases maintenance, and creates friction that slows down all future innovation. The best engineers are masters of preventing unnecessary complexity. Their biggest wins, a disastrous project averted, a legacy system retired, will never appear on a performance review, but they are immensely valuable.

3. Agility Is a Strict Discipline, Not a Free-for-All

The word "Agile" has been misinterpreted to the point of becoming meaningless in many organizations. Teams use "delivering value" as an excuse for shipping shoddy work at high speed. For others, "being agile" has come to mean "anything goes", no documentation, no planning, no rigor.

This interpretation is a complete departure from the concept's original intent. True agility is a difficult and demanding discipline. It is not a shortcut or an excuse for chaos. It is a rigorous commitment to practices that enable sustainable speed and responsiveness.

In my head, agility is equivalent to a discipline, and a difficult one at that... a discipline of "Hey, I'm going to write the test first, then I'll do the implementation, then I'll refactor, I'll even eliminate functionalities that aren't useful." It's actually a tough discipline.

This discipline is embodied in concrete, systematic practices. On the technical side, it means Test-Driven Development (TDD) as the foundation for design and quality, Continuous Integration (CI) and Continuous Delivery (CD) to enable rapid, safe deployment, and continuous refactoring to keep the codebase simple and maintainable. On the product side, it means applying Lean Product Development principles to validate ideas before committing to full implementation, running experiments to test hypotheses, and ruthlessly prioritizing based on real user feedback.

But as the above highlights, it's not just about additive practices. It's also a discipline of subtraction, of proactively controlling technical debt before it becomes a crisis, of simplifying systems even when they're "working," and of removing features that don't add value. The goal is to maintain agility, both from a technical perspective (the codebase remains easy to change) and from a product perspective (the team can pivot based on what they learn).

These are not optional extras; they are the very foundation of agility. They require an uncompromising commitment to quality, because it is only through high quality that we can earn the ability to move fast, adapt, and innovate sustainably over the long term.

4. Individual Performance Metrics Are a Trap

There is a growing and dangerous trend of trying to measure individual developer productivity with simplistic metrics like the number of commits, pull requests, or story points completed. This approach is devastating. In 2023, McKinsey published an article proposing a framework to measure individual developer productivity using metrics like "contribution analysis" and "inner/outer loop time spent." The response from the software engineering community was swift and unequivocal. Kent Beck, creator of Extreme Programming, called it "absurdly naive," while Kent Beck and Gergely Orosz wrote a detailed rebuttal explaining why such frameworks do far more harm than good.

The problem isn't just with McKinsey's specific approach. It's with the entire premise of measuring individuals in a collaborative discipline. This is a direct application of Taylorism, the management philosophy developed by Frederick Winslow Taylor in the early 1900s for factory work. Taylorism treats people as interchangeable resources to be optimized locally, decomposing work into specialized tasks and measuring each person's individual output. It took manufacturing 50 years to move past this thinking. Yet in software development, a creative, knowledge-based discipline where these ideas are least effective, we continue to apply them universally.

When you incentivize local optimization through individual metrics, the negative results are entirely predictable. As W. Edwards Deming taught, over 90% of an organization's performance is a result of the system, not the individuals within it. But individual metrics create perverse incentives that optimize for the wrong things. We reward behaviors that are easy to measure but destructive to the whole: a high number of commits (encouraging smaller, more frequent check-ins regardless of value), celebrating people for "being 100% busy" (even if they're blocking others), or lionizing "heroes" who constantly put out fires (often of their own making). These incentives inevitably lead to chronic bottlenecks, constant rework, and a toxic hero culture where knowledge is hoarded and collaboration is discouraged.

It is devastating because it promotes individualism in a profession that is fundamentally about collaborative problem-solving. It discourages essential practices like pair programming because it makes it harder to assign "credit." It optimizes for busy-ness (output) instead of actual business results (impact). As Beck and Orosz point out, measuring effort and output is easy, but it changes developer behavior in ways that work against the outcomes that actually matter.

Software development is a team sport centered on learning. The true measure of performance is the impact and health of the team. The most valuable person on a team would often score terribly on these individual metrics. They might be the "glue" that holds everyone together, the mentor who elevates the skills of others, the person who prevents bad code from ever being written, or the engineer who just deleted 10,000 lines of obsolete code, making the system simpler for everyone. Their contribution is profound, yet these metrics would render them invisible or, worse, label them a poor performer.

5. Don't Ask for Permission to Be a Professional

Too many engineers wait for permission to do their job properly. They see quality practices like writing automated tests as something they need to negotiate or justify to management. This is a fundamental mistake.

You don't ask your manager for permission to use a for loop or a recursive function; you use the right tool for the job because you are a professional. Writing tests is the same. It is a non-negotiable, foundational part of professional software development, not an optional feature you need to bargain for.

This responsibility extends beyond just testing. Your job is not merely to execute instructions. It is to solve problems. That means taking the initiative to understand the "why" behind a feature, respectfully challenging requirements that don't make sense, and proposing simpler, better solutions. This isn't overstepping; it is the very core of engineering. By taking this professional responsibility, you build trust, earn autonomy, and position yourself to make a real, lasting impact.

Conclusion: A More Sustainable Future

The key to a more sustainable, impactful, and professionally satisfying career is to abandon the "construction" mindset. When we stop thinking of ourselves as builders of static artifacts and start seeing ourselves as cultivators of living, evolving systems, everything changes.

This single shift in perspective is the thread that connects all five of these principles. It leads us to value subtraction over addition, to embrace discipline over chaos, to measure team impact over individual output, and to take ownership of our professional standards. It is the path away from anxiety and toward durable, meaningful work.

The arrival of AI does not invalidate these principles; it reinforces them. If anything is going to change, it's that these mindset shifts will become more critical, not less. When we can generate code faster than ever, distinguishing between building and cultivating becomes more important than ever. When AI can produce features at unprecedented speed, knowing what NOT to build becomes the differentiating skill. The tools evolve, the disciplines adapt, but the goal remains constant: sustainable impact over time, real value delivered, and complexity kept under control. Now we have new tools and evolving disciplines, but they're still pursuing the same fundamental objective.

What is one "construction" habit you can challenge in your team this week to start cultivating your software instead?

References

• Stop Building Waste: 6 Principles for High-Impact Engineering Teams Eduardo Ferro (2025)
  eferro.net/stop-building-waste
  A complementary piece exploring how to maximize outcomes while minimizing software complexity.
• Perverse Incentives, Predictable Results: When Your System Sabotages Your Teams Eduardo Ferro (2025)
  eferro.net/perverse-incentives
  Explores how Taylorist thinking creates perverse incentives in software development and offers systemic solutions.
• Measuring developer productivity? A response to McKinsey Kent Beck and Gergely Orosz (2023)
  Kent Beck's version | Gergely Orosz's version
  A detailed rebuttal to McKinsey's framework, explaining why measuring effort and output damages engineering culture.
• Yes, you can measure software developer productivity McKinsey (2023)
  mckinsey.com
  The original McKinsey article proposing individual developer productivity metrics.
• Basal Cost of Software Eduardo Ferro (2021)
  eferro.net/basal-cost-of-software
  Introduces the concept of ongoing cognitive and maintenance costs each feature adds to a system.
• Extreme Programming Explained: Embrace Change Kent Beck (1999, 2nd Ed. 2004), Addison-Wesley
• Software has diseconomies of scale – not economies of scale Allan Kelly (2015, revised 2024)
  allankelly.net/archives/472
• The Most Important Thing Marty Cagan (2020), Silicon Valley Product Group
  svpg.com/the-most-important-thing

Stop Building Waste: 6 Principles for High-Impact Engineering Teams

As engineers, we've all been there. We spend weeks, maybe even months, heads-down building a new feature, polishing every detail, and shipping it with pride, only to watch it languish. There's no greater professional waste than to develop something that nobody cares about.

This isn't just a feeling; it's a harsh reality backed by data. A huge portion of the software we build is pure waste. But it doesn't have to be this way. By shifting our perspective on what software is and how we build it, we can transform our teams from feature factories into high-impact innovation engines. Here are six hard truths to get you started.

1. Let's face it: Most of what we build is waste.

The first step is to accept the uncomfortable reality that a large percentage of software features go unused. This isn't an opinion; it's a fact. A well-known study by the Standish Group on custom applications found that a staggering 50% of features are "hardly ever used," and another 30% are "infrequently used."

This isn't just a problem for smaller companies. The best tech giants in the world face the same challenge.

The experience at Microsoft is no different: only about 1/3 of ideas improve the metrics they were designed to improve. Of course there is some bias in that experiments are run when groups are less sure about an idea, but this bias may be smaller than most people think; at Amazon, for example, it is a common practice to evaluate every new feature, yet the success rate is below 50%.

If the top companies, with all their resources and data, have a success rate below 50%, we have to be humble about our own ideas. Many of them are flawed. This means we desperately need a process to filter out the bad ideas before we commit to the expensive process of building them.

2. Think of software as a liability to be minimized.

This might sound counter-intuitive, but it's a critical mindset shift. We tend to think of the code we write as an asset. It's not. It's a liability.

Software is "very expensive to build/maintain/evolve." It's only a "means to achieve impact," not the goal itself. Worse, it has "diseconomies of scale," meaning the more of it you have, the more expensive each part becomes to manage.

This creates a "vicious cycle of software." Your team's capacity is used to build new software. This software immediately adds costs: cognitive load, debugging, monitoring, and architectural complexity. These ongoing costs reduce your team's capacity for future innovation. Because this maintenance cost isn't linear (it grows faster than the size of your codebase), you can quickly find your team spending all its time just keeping the lights on. I call this ongoing cost the "Basal Cost of Software", a term borrowed from basal metabolic rate, where each feature continuously drains team capacity, even when not actively being developed.

The goal of a high-impact team isn't to build more software. The goal is to "Maximize Impact" while actively trying to "Minimize Software."

3. Your engineers are your best source of innovation.

For too long, engineering has been treated as a "feature factory." In this classic model, engineers are seen as "code monkeys" who are handed fully-defined solutions and told to just build them.

This model is incredibly wasteful because it sidelines your single greatest asset. Empowered engineers are the "best single source for innovation and product discovery."

Every engineer on a product team should have a "product mindset" and a sense of "product ownership." This means they think about delivering value, not just features. It means they need to understand user problems deeply, which requires direct contact. Engineers should, from time to time, be in the interviews or making shadowing with the customer. Effective product teams are multidisciplinary, involving the "whole team" in the discovery process, not just product managers or designers working in a silo.

4. Maximize Outcomes, not Outputs.

It's easy to measure progress by the wrong things. This is the critical difference between outputs and outcomes.

• Outputs: These are the things we create. Functionalities, Requirements, Interfaces, Story Points. They are easy to count but tell you nothing about value.
• Outcomes: These are the results we want to achieve. Value, Impact, a change in user Behavior, ROI. This is what actually matters.

This distinction represents the next logical step in the evolution of Agile thinking. In the original Agile Manifesto, the authors prioritized "working software over comprehensive documentation." That was a huge step forward twenty years ago, but it's not enough anymore. Today, we need to champion "validated learning over working software."

"Classic" product teams are measured by outputs, which inevitably leads to bloated, low-impact software. Effective teams, on the other hand, focus on maximizing outcomes. Their goal isn't just working software; it's "validated learning." The core principle that drives every decision is simple: "Maximize Outcomes, Minimizing Outputs."

5. Design your systems to enable learning.

If our goal is to validate ideas and learn as quickly as possible, then our technical architecture and practices must be optimized for that goal. Building a high-impact product isn't just about culture; it's about having the technical foundation to support it.

Here are a few key practices that facilitate product discovery:

• Decouple release from deployment: Releasing a feature to users is a business decision. Deploying code is a technical one. They should not be the same thing. "Feature flags" are the essential tool that separates these two concerns, allowing you to test code in production safely. They are also the foundation for running experiments like A/B testing.
• Don't fly blind: You can't learn if you can't see. Your system must have robust product instrumentation, metrics, domain events, and operational data. This feedback is essential for understanding user behavior and measuring the impact of your experiments.
• Create a safe system to learn: Learning requires experimentation, and experimentation requires safety. Your system needs to have a low cost of failure. This is achieved through techniques like canary deployments, a solid experimentation framework, and a blameless culture that encourages trying new things.
• Enable rapid prototyping: You should be able to validate hypotheses without writing a lot of production-ready code. An extensible architecture with APIs and integrations for nocode solutions empowers the entire team. A product manager or designer with access to open APIs can run dozens of experiments and achieve validated learning without ever needing to change the core production solution.

6. AI changes the game, but not the way you might think.

It's unclear exactly how AI will reshape software development, but one thing is certain: we can now generate code and features faster than ever before. AI coding assistants can produce working software in minutes that might have taken days before.

This sounds like pure upside, but here's the trap: if we simply use AI to build more software faster, we'll only accelerate the vicious cycle. We'll accumulate Basal Cost at an unprecedented rate, drowning our teams in complexity even faster than before.

The real opportunity with AI isn't to build more. It's to learn faster and be more ruthless about what we keep.

AI should enable us to:

• Run more experiments and validate ideas quickly, iterating solutions before committing to production code.
• Build prototypes to test hypotheses without the traditional cost of development.
• Adjust and refine solutions rapidly based on real user feedback.

But this only works if we're radically more aggressive about:

• Eliminating what doesn't work: If an AI-generated feature doesn't deliver impact, kill it immediately. The lower cost of creation doesn't justify keeping failures around.
• Controlling complexity: Just because we can build something quickly doesn't mean we should. Every line of code still carries its Basal Cost.

The bottleneck has shifted. It's no longer about how fast we can build. It's about how quickly we can decide what to build and how fast we can learn from what we've built. Teams that master validated learning and ruthless prioritization will thrive. Teams that just use AI to build faster will simply create waste at machine speed.

Conclusion

To break the cycle of building software nobody uses, we have to fundamentally change our approach. We must accept that our job is not just to write code, but to solve problems and deliver value. This requires embracing a new set of principles.

First, recognize that software is a liability to minimize. Second, understand that empowered engineers are the best single source for innovation and product discovery. And finally, ensure that our technical solutions should optimize learning and discovery. By building our teams, culture, and systems around these ideas, we can stop wasting our effort and start building products that truly make an impact.

What is one thing your team could change tomorrow to optimize for learning instead of just delivery?

References

• The Four Big Risks Marty Cagan (2017), Silicon Valley Product Group
  svpg.com/four-big-risks
• The Most Important Thing Marty Cagan (2020), Silicon Valley Product Group
  svpg.com/the-most-important-thing
  
• Software has diseconomies of scale – not economies of scale Allan Kelly (2015, revised 2024)
  allankelly.net/archives/472
• Online Experimentation at Microsoft Kohavi, Crook, Longbotham et al. (2009), KDD 2009
  microsoft.com/research
  Documents that only ~1/3 of ideas improve metrics at Microsoft; Amazon's success rate is below 50%.
• Are 64% of Features Really Rarely or Never Used? Mike Cohn (2015), Mountain Goat Software
  mountaingoatsoftware.com
  Analysis of the Standish Group statistic on feature usage.
• Extreme Programming Explained: Embrace Change Kent Beck (1999, 2nd Ed. 2004), Addison-Wesley
• Empowered Product Teams Marty Cagan (2017), Silicon Valley Product Group
  svpg.com/empowered-product-teams
• Basal Cost of Software Eduardo Ferro (2021)
  eferro.net/basal-cost-of-software

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:

• "Accelerate: The Science of Lean Software and DevOps" by Nicole Forsgren, Jez Humble, and Gene Kim
• "The Principles of Product Development Flow: Second Generation Lean Product Development" by Donald G. Reinertsen
• "The Lean Startup" by Eric Ries
• "The Lean Mindset: Ask the Right Questions" by Mary&Tom Poppendieck
• "Escaping the Build Trap" by Melissa Perri
• "Inspired: How to Create Tech Products Customers Love" by Marty Cagan

Or if you prefer talks, I recommend these ones:

• Competing On The Basis Of Speed by Mary Poppendieck 
• Keynote: Friction by Mary Poppendieck 
• Agile Adria 2013 keynote: Make Impacts Not Software by Gojko Adzic 
• Beyond Features: rethinking agile software delivery by Dan North 
• Creating Value and Flow in Product Development by John Cutler 

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

• https://www.svpg.com/empowered-product-teams/
• https://www.eferro.net/2020/06/technology-at-core-of-product-discovery.html
• https://www.eferro.net/2022/08/software-development-art-of-postponing.html
• https://productdeveloper.net/from-software-engineer-to-product-engineer/
• https://productdeveloper.net/iterative-incremental-development/
• https://www.eferro.net/2021/02/basal-cost-of-software.html
• https://jpattonassociates.com/dont_know_what_i_want/

Book Review. The five dysfunctions of a team

The Five dysfunctions of a Team

by Patrick Lencioni

This book helps to identify and solve the most common and important dysfunctions of a team. It helps to convert a group of related people working in an organization into a high performance team that works as a cohesive unit that can achieve much more than the individuals by themselves, or working as a group.

As an example, it uses one of the most important teams in any organization, C-level management. It examines the problems, possible solutions, as well as the process to make this change possible. The truth is that the tips, method and processes can be applied to any group of people who want to become a real team.

The first part of the book is written like a novel, very much like The Goal or The Phoenix project. The second part gives tools and describes the framework to create good teams.

Very instructive and easy to read book. Good for anyone interested in working or forming teams.

Discovered the illustrated version via Luis Artola :-)