top of page

Reimagining Agile and Scrum for Product Management (Insights from Scott Sehlhorst)

Updated: Nov 1

By Andrew Park | 2024-10-31


This article is based on a couple conversations I had with Scott Sehlhorst, a seasoned product management and strategy consultant with over two decades of experience in software development, agile transformation, and product management strategy. Scott’s extensive career has involved helping organizations transition from Waterfall to Agile while refining product management practices to meet the needs of complex, multi-market software projects. He has been at the forefront of rethinking how Agile and Scrum can better serve product teams in modern, highly-complex software projects.

 

Agile and Scrum Need a Product-Centric Reboot

 

Agile and Scrum were a leap forward when they emerged, providing a more collaborative, iterative approach compared to the rigid Waterfall model. At the time, they addressed the fundamental need for faster feedback, adaptability, and increased developer involvement. However, since their inception, software projects have increased roughly 50x in size and complexity. This growth has exposed critical gaps in how Agile and Scrum interact with modern product management.

 

The initial framework of Scrum, for example, was built on assumptions that no longer hold true today. It was designed with the idea that development teams could sit with a customer to understand requirements and iterate quickly. But as Scott Sehlhorst highlights:


“You can’t serve multiple customers in multiple market segments, in multiple markets, who have different needs around the world and have them sit with you.”

 

Modern product development involves a web of diverse customers, competing priorities, and varying market demands. The product owner role, which was supposed to bridge the gap between development and customer needs, now often limits development teams to simply refining requirements and managing backlogs. This approach keeps the development team in the role of order-takers rather than strategic partners.

 

Today’s products are not simple, repetitive builds that benefit from routine execution; they are unique, evolving creations that require inspiration, creativity, and a deep partnership between product and technical teams. Agile and Scrum must adapt to this new reality by integrating a more product-centric mindset that reflects the vast scale and intricacies of modern software development.

 

Beyond Handoffs: Product Trios from Discovery to Delivery

 

The need for product management, design, and engineering to work together as a tightly integrated unit—a concept often called a “product trio” and popularized by Teresa Torres—is crucial. Scott Sehlhorst argues that modern product development cannot rely on the traditional handoff model, where requirements pass from one team to another, as seen in both Waterfall and Agile environments:

 

“This throw-it-over-the-wall stuff is very obviously not good enough. We need all three roles to participate in every step of the process, from defining problems to designing solutions to executing incrementally.”

 

Sehlhorst illustrates this with a “Necessary” model, shown in the far-right of his diagram, where the product trio’s efforts fully overlap in delivering value to the business, desirability for the customer, and feasibility for the team.



This model contrasts sharply with less integrated approaches, where teams focus on one or two aspects—resulting in outcomes that are merely “Not Good Enough” or “Less Bad.”

 

To succeed, teams must shift from sequential handoffs to simultaneous, cross-functional collaboration, from the discovery and strategy phases all the way through to delivery. This continuous, end-to-end approach ensures that design, feasibility, and value creation are considered holistically, rather than as separate stages. Sehlhorst insists that this level of collaboration is essential for addressing modern product complexities, where design decisions and technical feasibility often depend on a deep understanding of the value being created for the customer.

 

Meaningful Iterations > Time-Boxed Sprints

 

While Agile and Scrum promote incremental development, they often focus on project management outcomes rather than customer value. This can be a serious limitation for large, complex software projects, where delivering true value often means releasing fully developed features that address real customer needs, not just meeting sprint deadlines.

 

Instead of adhering rigidly to sprint timelines, Sehlhorst advocates for iterations designed around delivering complete features.

 

“Delivering one-fourth of every feature each time doesn’t create customer value.”

 

This problem is particularly pronounced for larger, more complex software products where incremental pieces aren’t enough to be useful. A more meaningful approach is to design each iteration around a complete, usable feature that addresses a specific customer need. This focus allows for faster feedback and more purposeful iterations, keeping teams aligned with real user needs rather than arbitrary deadlines.



Letting Go of Control: Delegating Agency

 

Agile principles emphasize empowering teams, but often fall short in practice, as product managers end up deeply involved in implementation details. Sehlhorst believes that delegating agency to development teams is crucial, but it requires trust and clarity in outcomes rather than specifications:

 

“As a product person, you shouldn’t be involved in how they’re going to try and accomplish it. You should be saying, ‘Here is how we’ll judge if it worked.’”

 

By focusing on outcomes and establishing clear metrics for success, product managers can allow technical teams the autonomy to determine the best solutions, leading to more creativity and faster problem-solving.

 

Redefining the Product Role Beyond “Requirements Management”

 

The product owner role in Scrum was meant to connect developers to customer needs, but in many cases, it reduces product managers to the role of backlog managers. Sehlhorst stresses that this misses the broader strategic and customer-focused nature of true product management:

 

“It’s not about clarifying requirements; it’s about driving the creation of valuable, desirable, and feasible solutions.”

 

Product managers must be allowed to focus on strategic planning, market analysis, and hypothesis testing rather than getting bogged down in tactical work. Only then can Agile and Scrum support the strategic role that product management plays in modern organizations.

 

Conclusion: Realigning Agile and Scrum with Product Strategy

 

The rapid growth in size and complexity of software projects demands an evolution in Agile and Scrum. Scott Sehlhorst’s insights point to a necessary shift from linear processes and role silos to deeply collaborative, cross-functional teams. Agile must be reimagined not as a set of rituals to be followed but as a framework that enables continuous learning, real-time adjustments, and outcome-driven development. As organizations adapt to the evolving demands of software delivery, they must prioritize true product agility, allowing product management to thrive and create sustainable, meaningful impact.

 

For a deeper dive into these concepts and practical strategies to implement them, check out my upcoming book, Product Oriented Software Engineering (POSE).




Recent Posts

See All
bottom of page