"Agile" is a product development tactic not a collection of techniques

Many organizations rely on a mixture of processes and platitudes to determine how they work. Every company leadership team likes to claim ownership over their organizations unique processes, but in reality they are minor variations on widely known processes. This is why the majority of technology product companies work the same way using the same processes; however, most technology businesses fail and most follow the same processes. This begs the question, do the processes work?

This question is, simply put, stupid. Because focusing solely on the process is stupid. This is how product management becomes project management.

A process is a technique. It is not a tactic of product management, and it is certainly not a product strategy. It is all too common for organizations to adopt agile/lean processes (mostly for how they deliver products to market) and then claim to be agile/lean product organizations. The 6th Chapter of the Second Edition Marty Cagan’s Inspired outlines what these organizations look like to a tee. You should read that chapter and then come back to this article as it outlines both the overall processes used and the reasons why it isn’t commonly successful. For those without access to that book, here is a summary:

The majority of new ideas come from external sources like the sales and marketing teams, or internal sources who are higher-up in the organization. These ideas are then assessed by creating a formal or informal business case meant to outline potential cost (time, money, tradeoff costs) versus potential returns. Then on a quarterly or yearly basis these ideas are organized into a “product roadmap” meant to prioritize product work (aka projects) by most important to least important. This “roadmap” includes release time frames for the work within it. The product managers gather the requirements for a project; give the requirements to the design team; and then each of these projects are given to engineering to implement. The engineering team often breaks the work into segments of smaller work known as sprints. (Inspired: How to Create Tech Products Customers Love, by Marty Cagan, 2nd ed., Wiley, 2018.)

A lot of organizations fall into the trap of thinking they are agile and lean because they have tactical and strategic platitudes instead of real tactics and strategy to guide them. This results in people trying to mimic success by pairing platitude to technique (often these are chosen by ease of adoption).

Product Strategy

A product strategy, in its purest form, is the path to achieving a company’s product vision. It informs us of what customer problems to try to solve which in turn dictates which tactics should be used to actually solve the problems.

Agile, lean, and even waterfall are product development tactics. These tactics can be implemented in varying ways to support, standardize, and/or streamline the two core product development tasks: discovery and delivery. You can use these aforementioned tactics for either or both of these. Circling back to the previously cited description by Marty Cagan, those organizations use waterfall product discovery with agile product delivery.

The best technology product organizations use agile and lean product development tactics for both discovery and delivery because these tactics focus on addressing the risks and wastes of product development as early and as often as possible. This is what most people think of when they think of agile product organizations. And these are the principles that make these tactics so powerful.

Development Tactics

Tactics scale with an organization. Tactics are resilient. They grow with the business to inform it which processes will be successful given the company's size, locations, time zone differences, and technical architecture.

A 10 person start-up co-located in the same office can be lean and agile without needing any process at all. A rigid stand-up process will not work for a small global team that contends with timezone conflicts. A platform engineering team that is leveraged by many product teams might need to focus on throughput so other teams are able to be lean/agile.

The techniques or processes that have come to embody agile and lean product development are manifestations of the tactics. They are meant to be standardized and repeatable ways to successfully complete the tactic. A technique’s success is based on more than the technique itself. There are plenty of martial arts techniques that are successful at ¼ speed during a demo with a limp-fish of a volunteer, but fail the moment they are used under real-world conditions. Even a successfully executed technique will only be successful under the right contextual conditions despite the technique being tactically sound.

Even a successfully executed technique will only be successful under the right contextual conditions despite the technique being tactically sound.

When people say agile and/or lean isn’t a silver bullet for successful product development, make sure they are not focused on the myopic view of the techniques being used. More often than not, they are.

Organizations that embody the agile and lean principles have an undeniable track record for success; therefore, the market has settled the debate on whether or not these tactical principles are objectively successful or not. The tactical principles of agile and lean (to address risks and wastes as early and often as possible) should be an organization’s guiding light not the techniques. Yet everyone focuses on the techniques.

So how do you know what technique to use and when?

A quick tangent: there are three ways to think about how to solve a problem: Ad Hoc, Rule-based, and Algorithmic.

• An ad hoc approach is characterized by treating each situation as inherently unique and either explicitly or implicitly not taking into consideration similar situations one previously experienced.
• A Rule-based approach would mean you research past similar situations to identify a pattern you can use to quickly assess and act in a situation with a reasonable degree of success.
• An Algorithmic approach would mean one has researched (or learned from) past situations to develop an understanding of the interrelated/interacting systems at play in order account for all the meaningful variables at play to achieve an extremely high success rate.

Unfortunately, an algorithmic approach is probably not achievable given the constant changes occurring in markets and the systems that affect them.

Realistically the best we can achieve is to define a set of rules to determine what technique (that adheres to your organizations tactical principles) will be most likely to be successful under a certain set of internal and external conditions specific to an individual organization.

But who makes the rules and who decides what rule needs to be followed when?

In the context of this manuscript, a product manager. Only the product manager knows the relevant context around their product area; therefore, they are the only ones positioned to make the judgment call of what rules need to be defined and which needs to be applied to make the decision of what technique is needed.

It is the role of the product leadership team to build a framework that empowers their product teams to decide what rules to define, follow, or not follow. Product leadership should define the strategy, and tactical principles to be followed. Product managers need to understand the strategy and tactical principles to determine what process/technique is needed for their situation.

The product discovery process is typically the most difficult task for organizations to empower product managers to own. The reality is over half of the product ideas an organization has will not be successful; which is scary to think about. For many, especially those who are output focused, this can and will be a sticking point. Often these individuals will say things like, “The product manager will spend a lot of time on things we don’t end up delivering to the market. That is all wasted time.”

In reality, product discovery is about identifying the high-risk low-reward ideas as quickly as possible so less time is wasted building, marketing, and selling bad products. Those downstream tasks are where the real costs associated with “waste” are incurred by a technology product organization.

Optimizing product teams for agile and lean product discovery is optimizing a product organization for outcomes.

The best product discovery processes are highly collaborative and should involve cross functional teams that can work together under the direction of a product manager to quickly identify new product ideas and determine which ideas are viable. During the discovery process the team should strive for a high throughput process to efficiently examine incoming product ideas.

The higher the throughput of identifying the non-viable ideas as early as possible the quicker the team will identify the viable ideas. Empowered product teams insulate the business from the risk of delivering products to the market that customers don’t care about.

The product delivery process is just as important as product discovery. Delivery is focused on executing on an already vetted product idea. The vetting process should include determining if the business has the ability to deliver the product to market. Typically the focus of delivery is supporting the engineering team to build the product. Most technology organizations let their engineering department define this process. In parallel to the engineering team building the product the product manager should be ensuring all the relevant go-to-market support work is happening on the right timeline with the right people to ensure a successful launch.

Product is about outcomes, not output. We sell solutions to problems. These solutions are more than just the software and/or hardware we sell. Solutions should be holistic; therefore, products and product management have to be holistic. A prerequisite for this is understanding product development tactics like "agile" and "lean".