#iterative frameworks

Nearly 17 years ago, the Agile Manifesto set forth principles for an iterative, adaptable means to deliver valuable technology to market. Since that time, Agile has evolved into an umbrella methodology, sparking iterative development frameworks such as Scrum, Kanban, and Extreme Programming; and amplifying the impact of iterative frameworks in related fields such as Lean Startup and Design Thinking. Arguably no philosophy other than Agile has played a greater role in facilitating “software eating the world”.

While Agile thinking has enabled modern, high-growth companies to quickly build products that compete with traditional alternatives, established companies remain perplexed that Agile methods within their own environments too often fail to bring their own disruptive innovation to market. 

In The Startup Way, Eric Ries underscores how an Agile mindset is at odds with traditional organizational design. 

According to Ries, established companies tend to structure their organizations based on the legacy of Alfred Sloan’s “decentralization with coordinated controls” and Scientific Management. While Scientific Management’s rigorous forecasting can facilitate efficient production at scale and cultivate accountability, it discourages unpredictability and experimentation. 

Through the lens of Scientific Management, Agile looks an awful lot like a process whose purpose is to increase efficiency or predict timing of software delivery, not an adaptable approach for teams to continuously develop valuable technology and adjust quickly to customer needs. The Agile mindset is difficult to capture on paper, which makes it challenging for corporate organizations to implement within familiar frameworks.

As a result, too many companies institute an Agile process, not an Agile mindset, spending enormous budgets to revamp large scale processes without committing to shifting core beliefs surrounding their product organizations.  

It seems counter-intuitive to put effort behind delivery transformation initiatives that require product teams to comply with complex “agile” rules and milestones when the very nature of the Agile mindset is about committing to focused learning and embracing uncertainty. 

Agile's iterative frameworks exist to find and build a minimum viable product as quickly as possible, learn from it’s successes and failures, then iterate. Process alone may standardize schedules and promote efficiency, but it misses opportunities to uncover meaningful products and features through repeated hypothesis testing and measured failure. Without organizational structures in place that promote all forms of product discovery - including fast failure - Agile and delivery transformation are simply buzzwords.

Janice Fraser offered some truly transformational advice to leaders of established companies in her talk at Mind the Product San Francisco Conference in 2017, which can be found above.

1. Value small, fully dedicated Agile teams and hold them to different standards than other functions. 

2. Invest in them as if they were a startup seeking funding, rewarding results with autonomy while limiting potential for loss. 

3. Openly discuss specific learning that results from their failures and incorporate across the organization. 

4. Provide runway for their product’s long term impact, as opposed to repercussions for missing short term estimates. 

Management guru Peter Drucker famously advocated for ignorance as a path to sound decision-making. According to Drucker, his greatest strength was “to be ignorant and ask a few questions”, rather than providing answers. “Ignorance is the most important component for helping others to solve any problem in any industry.”  

For product managers, Drucker’s advice is vital to success, particularly for those of us responsible for complex, evolving technology products. Why? Because the overwhelming majority of your product’s users are ignorant of the technical details, and they simply do not care. Details do matter, but some far more than others. As a tactic, ignorant questions are an effective way to channel the perspective of a user (or a stakeholder) and bring a complex conversation’s focus back to the level of “so what?”

Yet, too often Drucker’s advice goes unheeded and this tactic is misunderstood as a sign of weakness.

Great product managers must be in the habit of asking very simple questions, not solely for a specific detailed answer, but rather to uncover the more meaningful causes which result in that answer.

Great product managers must seek deeper meaning behind the current detailed answer’s rationale or implications on a customer’s jobs to be done.

Great product managers are also aware that today’s detailed answers too often expire or prove invalid before the tomorrow defined in a roadmap can become realized. 

A product manager is best suited to lead his or her team by discovering rationale for a specific technical choice, or principles being exercised by a question’s outcome. 

In short, great product managers must be comfortable being ignorant of details, but uncomfortable not knowing why those details matter. They must be able to ask questions that uncover factors driving today’s answers, then put them in context of customer impact and the product’s long term value to those customers. They must enable the team to frequently adjust the path forward without regret or ego in order to deliver the most valuable features.