Lean Product Management

John Dougherty

In my previous post, I introduced transformational leadership, as outlined by DORA. This approach is all about building a robust organizational culture. We achieve this by nurturing trust, respect, and honor among team members, creating an environment where everyone takes pride in their work and feels a sense of ownership. By encouraging intellectual stimulation and promoting the exploration of problems from different angles, we can naturally foster innovation within our teams.

In the upcoming series, we’ll dive deeper into the topic of innovation as a repeatable practice. But for now, let’s shift our focus to lean product management, which stands as one of the three key pillars contributing to organizational and software delivery performance. First, let’s level set performance.

Organizational performance is measured by profitability, market share, and productivity, while software delivery performance is measured by delivery speed, stability, and availability.

Within the realm of lean product management, there are several components to consider. For our purposes, I will highlight three key activities: team experimentation, working in small batches, and gathering and implementing customer feedback. These activities directly influence and shape the processes that drive organizational performance. Technical leaders play a crucial role in orchestrating these practices to achieve tangible results.

The validated model shows that effective leaders impact software delivery and organizational performance indirectly, by enabling teams to adopt technical practices and lean product management practices. It is these practices that drive organizational outcomes such as higher software delivery performance and organizational performance. These capabilities also drive cultural change…

DORA

In this exploration, we focus on practices that lead to the highest performance among software development teams, as measured by their ability to solve real customer problems. It’s important to acknowledge some underlying assumptions, such as the readiness of engineering teams to adopt these practices and the presence of a culture that facilitates regular access to users. Additionally, implementing these changes may require establishing various workflow processes, which might not be feasible for every organization. But, by studying these best practices, we can extract the underlying motivations and apply them within existing cultures, ultimately propelling organizations towards higher performance.

DORA’s concept of team experimentation encompasses several familiar concepts for practitioners of extreme programming (XP). Treat the story cards as capturing the conversation with the customer but not as a unchangeable requirement specification. Developers are encouraged to build prototypes and test ideas related to the problem domain and potential solutions, iteratively. The insights gained from these iterations are regularly validated with users. This feedback informs the team’s efforts to improve the design, including the flexibility to modify traditionally fixed inputs.

Put the power of designing the solution, in the hands of the people closest to designing the solution. This means allowing the team to make changes to stories, specifications, and technologies based on their collective learning. It’s important for the team to have a deep understanding of the business context to ensure the solution is genuinely valuable to end users. Studies have shown that up to 66% of feature development may provide little to no value to the user community, see for example A/B Testing. Consequently, the team should be able to drop features of low actual value. By avoiding low or non-value work, team effectiveness can increase up to threefold.

Ultimately, this approach is about velocity, driving speed towards delivering value, reaching the market quickly, and embracing the ability to fail fast. With each iteration of the prototype-discover-design-build loop, the team gains a deeper understanding of the problem domain, what works in the solution domain, and what doesn’t. Team experimentation aims to optimize the discovery and correction paths to run as efficiently as the company can sustain.

Working in small batches requires a few preconditions. Teams should follow trunk-based development, continuous integration, employ test-driven development or robust automated testing, begin development at the API contract level, and utilize feature flags for controlled deployment to production. Let’s break down these concepts further.

By starting development from the API layer or the GraphQL integration point, new features can be added and tested without being exposed to end users. Dark launching enables developers to check in code for small completed batches, even for features that aren’t fully finished yet. This contract-based development approach allows mobile and web teams to build toward the API as the contract between the platform and front-end teams, enabling parallel development, especially when incorporating mocking techniques.

These small batches are truly small in scope. The highest performing teams often make multiple check-ins to the trunk throughout the day, and each batch should never take more than a few days to complete. Adhering to the agile INVEST principle, teams must have a clear understanding of what needs to be built to achieve this level of granularity.

Lastly, if feedback is considered a gift, then customer feedback is cherished. It is essential to identify customer satisfaction metrics that are relevant to the business and collect them regularly. For new products and features, actively seek feedback through embedded users, beta groups, or other market sources. This feedback should be made readily available to development teams. It forms part of the business context, driving better results as the teams iterate.

These are vetted ideas that can significantly enhance the velocity of development teams, additionally you might consider visual work management, reducing work in progress (WIP), and similar lean practices. I will cover these topics in a future blog post. In the next blog, I will focus on technical practices, another pillar of transformational leadership.