Waterfall or Agile? It Turns Out It Doesn’t Really Matter
Waterfall or Agile?
When I started in product management in the early 2000s, my company exclusively used the “waterfall” development methodology. We were the epitome of a linear-driven organization with our phased scoping documents, business cases, product requirements documents (PRDs) and development plans.
I worked for a large financial services firm that responsibly monitored any and all changes to its core platform. Releases were managed to the Nth degree as to not impact the core transactional business. The waterfall process made complete sense for the environment.
However, my particular product portfolio consisted of business intelligence and analytics products based on the data from the organization’s transactions. Conceivably, we could build and manage our products without impacting the core systems. So with a great engineering partner who convinced the powers-that-be to become more flexible in our ways, we set out to be the first group within the organization to use Agile Scrum to build our products.
“Wagile”
Our team of engineers, product owners and scrum masters learned quickly and became a well-oiled agile machine in the midst of a waterfall behemoth.
As it turns out, 15 years later things haven’t changed that much for large complex organizations such as my former employer. While pure software companies almost universally use some form of agile development process today, other firms still use waterfall or a hybrid process – some waterfall, some agile… “wagile” if you will.
In recent research conducted by Sequent, a solid majority of firms indicated they use either waterfall or a combination of waterfall and agile.
Based on our experience helping companies build successful product businesses while navigating these complicated and fluid processes, we’ve recently updated our Product Management Framework to more accurately depict and guide the product management function.
We Cracked The Code
As you can see, the critical component of Customer and Market Insights underlie the entire product management lifecycle. This work area entails accurately understanding customer needs and then segmenting the target market into groups of customers with a similar need. In addition, having a pulse of the overall industry and competition leads to well-planned and positioned products.
The Discovery and Strategy work area serves as a business canvas to capture data, derive insights and formulate strategies. It is during this part of the process that Product Managers identify targeted opportunities for the organization to pursue.
Within Product Planning and Product Introduction, organizations may be using linear or iterative processes or some combination of both. While the mechanics differ somewhat between linear and iterative processes – with linear consisting of phased units of work whereas the planning, design, development, and testing activities are done in circular repetition in iterative processes – the core functions of assessing opportunities, creating clear, compelling value propositions and prioritizing efforts remain constant.
The Post-Launch Product Management (PLPM) work area focuses on the performance of products within the context of strategies of the firm, division, and product line. An important function during PLPM is the monitoring of the market and product in order to make adjustments to the marketing mix (e.g. product, price, promotion, and place) to maintain the product’s impact.
Ultimately, the choice of development methodology (linear or iterative) has no direct correlation to product success. However, organizations with a keen market focus, deep understanding of customer needs and internal processes that are well understood and consistently deployed are often best-in-class performers.