Saturday, August 26, 2023

Good talks/podcasts (Ago 2023 I)

 

These are the best podcasts/talks I've seen/listened to recently:
  • Simon Sinek Performance vs Trust (Simon Sinek) [Company Culture, Culture, Inspirational] [Duration: 2:21] (⭐⭐⭐⭐⭐) Great description of the impact of trust on team members and leaders.
  • CONSTANT Changes To User Requirements Drive Me CRAZY (Dave Farley) [Agile, Continuous Delivery, Inspirational, Lean Product Management, Lean Software Development] [Duration: 0:13:00] (⭐⭐⭐⭐⭐) This presentation by Dave Farley shows that software development is not just about translating perfect requirements into code, but rather a process of discovery and exploration. It acknowledges that the nature of the problems being solved has changed and that it is impossible to have all the answers. It emphasizes that successful software products must be able to adapt and evolve over time, and that the key to success is embracing change and making it easy, safe, and low-cost.
  • Tips For Technical Startup Founders | Startup School (Diana Hu) [Inspirational, Lean Software Development, Lean Startup, startup] [Duration: 0:28:00] (⭐⭐⭐⭐⭐) Diana Hu shares her advice for being a technical founder at the earliest stages - including topics like how to ship an MVP fast, how to deal with technology choices and technical debt, and how and when to hire an engineering team.
  • Scaling Shape Up Beyond Bootstrapped Companies (Ryan Singer) [Product, Product Leadership, Product Strategy] [Duration: 0:47:00] Interesting talk about the ShapeUp product development methodology and how it can be used in different contexts. Very interesting ideas even if you don't use ShapeUp.
  • AI Impacts in Development Practice (Michael Feathers) [AI, Devex] [Duration: 0:33:00] Interesting reflections on how the profession of software developer might evolve with the introduction of AI (LLMs, GenAI). Among other topics, Michael talks about the importance of quality in this environment, the adaptation of practices like TDD, and the need to specify precise requirements, etc.
  • FAST '23 - Building and Operating a Pretty Big Storage System (My Adventures in Amazon S3) (Andy Warfield) [Engineering Culture, Engineering Scalability, Scalability] [Duration: 0:53:00] he perspective of evolution, design, and team organization in the context of rapid growth and at a scale hard to imagine.
  • Minimum Viable Architecture (Randy Shoup) [Architecture, Architecture patterns, Evolutionary Architecture] [Duration: 0:47:00] Presentation on 'Minimal Viable Architecture', discussing its evolution alongside a product's lifecycle phases: idea, start, scale, and optimize. Each phase examines business goals, constraints, and suggests corresponding software architecture.
  • Artificial Intelligence seen from the software development lifecycle perspective (Nerea Luis) [AI, MLOps] [Duration: 0:54:00] (⭐⭐⭐⭐⭐) Great introduction to the differences between traditional software development and the development cycle with AI models. Nerea introduces concepts such as Continuous training, model deployment, MLOps, and collaboration between data scientists and software engineers. Highly recommended for software engineers looking to delve into these topics and collaborate more closely on AI-based feature development.
Reminder: All of these talks are interesting, even just listening to them.

Related:

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:

Sunday, June 18, 2023

Good talks/podcasts (Jun 2023 I)


 

These are the best podcasts/talks I've seen/listened to recently:
  • Sabotaging a Transformation (Fred George) [Agile, Culture, Inspirational, Transformation] [Duration: 0:42:00] Real experiences on Agile transformations: common obstacles and strategies to overcome them. Specifically, it addresses: executive unawareness, lack of engagement, power shifts, and blame-oriented cultures.
  • Software delivery in small batches: Dr. Deming (Adam Hawkins) [Devops, Lean, Lean Software Development] [Duration: 0:14:00] (⭐⭐⭐⭐⭐) This episode highlights the significant impact of Dr. W. Edwards Deming on lean manufacturing, Total Quality Control (TQC), and the subsequent development of DevOps in software delivery. Deming's focus on holistic thinking, continuous improvement, and understanding the system laid the groundwork for lean principles, which later influenced the emergence of DevOps, revolutionizing software development and operations.
  • Improving Software Flow (Randy Shoup) [Devops, Flow, Inspirational, Lean, Lean Software Development, Technical leadership, leadership] [Duration: 0:50:00] (⭐⭐⭐⭐⭐) In this session, Randy explains how they improve the overall flow and the engineering capacity following the ideas in the Unicorn Project (Locality and Simplicity, Focus, Flow, and Joy, Improvement of Daily Work, Psychological Safety, and Customer Focus). It is an excellent talk about generating/improving an engineering culture following lean principles.
  • AWS Community Day Nordics 2023 - The Tao of Event-Driven Architectures (Luc van Donkersgoed) [Architecture, Architecture patterns, Serverless, Technology Strategy] [Duration: 0:30:00] In this talk Luc presents 10 simple rules to organize and standardize event-driven systems, which helps build future-proof implementations.
Reminder: All of these talks are interesting, even just listening to them.

Related:

Sunday, May 07, 2023

Good talks/podcasts (May 2023 I)


 

These are the best podcasts/talks I've seen/listened to recently:
  • Artificial Intelligence: Last Week Tonight with John Oliver (John Oliver) [AI] [Duration: 0:27:00] Funny report on the state of artificial intelligence. Presentation for all audiences. Not technical.
  • Prioritizing Technical Debt as If Time & Money Matters. Goto 2022 (Adam Tornhill) [Engineering productivity, Technology Strategy] [Duration: 0:28:00] Adam presents an interesting approach for classifying and tackling technical debt based on analyzing code changes over time, by authors and files, in order to identify hotspots worth investing in.
  • The Difference Between Continuous Delivery & Continuous Deployment (Dave Farley) [Continuous Delivery, Technical Practices, Technology Strategy] [Duration: 0:18:00] In this episode Dave describes the differences between Continuous Delivery and Continuous Deployment: what each one gives you and when Continuous Deployment may not always be the correct answer.
  • The wet codebase (Dan Abramov) [Software Design, Technical Practices] [Duration: 0:25:00] Interesting talk about software design, design principles, and how it's worth understanding them in their context to apply them correctly. It reminded me of this post I wrote about the DRY principle https://www.eferro.net/2017/02/applying-dry-principle.html
  • NUMMI (2015) (Frank Langfitt) [Lean, Lean Manufacturing] [Duration: 1:04:00] (⭐⭐⭐⭐⭐) The interesting history of the NUMMI plant and the joint venture between GM & Toyota. A good story to understand some of the lean principles. There is a previous version of the podcast with other interviews at https://www.thisamericanlife.org/403/nummi-2010
  • Many More Much Smaller Steps with GeePaw Hill (GeePaw Hill, Chris Lucian, Austin Chadwick) [Evolutionary Design, Lean Software Development, Software Design, Technical Practices, XP] [Duration: 0:39:00] (⭐⭐⭐⭐⭐) Good conversation about GeePaw Hill's software development approach based on taking continuous small safe steps (Many More Much Smaller Steps).
Reminder, All these talks are interesting even just listening to them.

Related:

Monday, May 01, 2023

Lean Coffee: Defer Commitment / Postponer decisiones

El pasado lunes  24/04/2023 tuve el placer de poder colaborar en un Lean Coffee sobre uno de los principios Lean que más me interesan y que creo que menos gente pone en práctica: Defer Commitment.

Gracias a todos los participantes creo que quedo una sesión muy interesante y que espero que tenga continuidad en alguna otra sesión futura.

Gracias a todas las comunidades de Software Crafters que quisieron colaborar con la iniciativa:

Aquí tenéis el vídeo:

Aquí teneís un hilo con algunas de las preguntas y respuestas que se dejaron en el panel:

Referencias y Lecturas relacionadas