Agile and the Product Mindset

Adopting a product mindset is critical when transforming to an Agile development methodology, like Scrum. Shifting our thinking from project to product expands our view beyond the confines of the triple constraint—scope, cost, and time. The product mindset forces us to consider the larger, strategic roadmap and the value we want create.

Product vs. Project

The Economic Times describes a product as an item offered for sale. The product has a useful life after which it needs to be re-launched or extended to keep it relevant.

The Project Management Institute defines a project, as is temporary endeavor to develop a unique product, service or result.

The very definitions of products and projects create different perspectives and incentives.

A product manager needs a vision of how to position the product in the marketplace. The possibilities for growing and extending a product are almost endless.

The project manager is charged with delivering a project within its defined scope and prescribed budget and timeframe. In essence, the project manager is destined to manage trade-offs and constraints to achieve her goals.

These are not simply linguistic differences. They create and reinforce attitudes and beliefs that are critical to achieving the Agile mindset.

Customers vs. Stakeholder

Products have customers. By definition, a product needs someone willing to purchase it. Projects have stakeholders who have an interest in the outcome.

Stakeholder management tends to be a balancing act. How can I manage the competing interests of my stakeholder community?

Customers are people that we strive to delight. How can I provide a superlative user experience.

Understanding your customers and their needs is a critical component to product management. Who are customers? What features and functions will enhance their experience?

There are many methods to understand and get close to our customers. UX (user experience) professionals have well-established techniques. Customer persona mapping is one popular tool. When we build our customer personas, we create proxies for our real customers. These personas are often prominently displayed so the team can be constantly reminded of whom they are serving.

The Product Vision

The product vision is the overarching goal that describes what should be delivered. The vision should be inspirational. It should provide the team with a clear understanding of why they are there.

When I teach Product Management classes, one of the exercises is to develop a product vision. Many professionals who have roots in traditional software development methodologies struggle with expressing a vision. They default to listing detailed features and functions.

In a recent class, I asked my students to create a vision for their product. They started rattling off a list of detailed requirements and specifications. After a few minutes, I cut them off and told them that they lost me 30 seconds into presentation.

I said, “your role is to regulate financial instruments to ensue people have money to retire, right?” They nodded. I suggested that they reframe their vision statement to reflect the security they provided to retirees.

I then challenged them to develop a customer persona that captured the emotional appeal of their work. They created a persona of a schoolteacher who had a secure future because his retirement savings were secure. The persona was compelling

At Spotify, resources are not assigned to Agile teams. Rather, the product owner needs to present a vision that is so captivating that the staff volunteers to work on that product. Spotify is not a typical company. But could you imagine being in an environment where you could choose to work on what inspires you?

Driving Value and Eliminating Waste

In Lean, the goal is to maximize customer value while minimizing waste. Value can be defined as the features and functions that enhance the customer’s experience.   There are many forms of waste, but the primary definition is things that do not directly add value to the product.

When considering value, it is important to describe the “what” separately from the “how?” In describing the “what,” it is often necessary to look beyond the original requirement to find the true need.

For example: a mobile banking application requires authentication to secure transactions. The “what” is security and the “how” is the authentication process.   Login processes that require users to manually type in their username and password are cumbersome—they meet the need for authentication but do not deliver value. Enabling the fingerprint scanning function reduces wasted effort for the customer—it meets the need and reduces waste.

There are many forms of waste in the software development process that are often hidden from sight. However when exposed, it is easy to recognize these forms of waste:

  • Partially done work. Work that is in-process does not deliver value until it is complete;
  • Extra processes. Work that does not provide direct value to the customer, such as extra keystrokes or excessive documentation;
  • Extra features. It is estimated that 50% of software features are never used. The time and effort to create these features could be better expended elsewhere; and
  • Waiting. Waiting causes delays and frustration.

Focusing on maximizing customer value and minimizing waste establishes a new framework for evaluating our products and product features. Are our customers really going to use that function? Is that the most effective way of enabling that feature? Are we (internally) efficient?

Prioritized Product Backlog and the Minimum Viable Product

In Agile and DevOps, we don’t predefine the product scope to be all of the features we could ever want. Rather, the product owner develops a prioritized list of features, called the product backlog. These features are bundled into a series minimum viable product (MVP) sets that are delivered incrementally over time.

Incrementally delivering capabilities to our customers allows us to start realizing benefits earlier. Rather than waiting for the entire project to complete before customers use it, they can begin using components as they become available. We can learn how our customers actually user our products. This gives us the opportunity to “fail fast”—learning from our mistakes quickly rather than waiting to the end to “fail big.”

Even my clients that have been Agile for years still struggle with the prioritized backlog and MVP. They have implemented the ceremonies and artifacts, but still talk about “delivering the project” which implies the entire scope of work. Agile recognizes that an application may never be done-done—there are always features that might be added or defects that could be corrected. But, at a certain point we need to draw the line and acknowledge that we have implemented the features that were a priority.

Shifting from a project to a product mindset may seem easy. But it is much more than changing vocabulary or practices. It is about shifting our framework to be customer focused and value driven. It changes how we approach the development process.

© 2017, Alan Zucker; Project Management Essentials, LLC

To learn more about our training and consulting services, or to subscribe to our Newsletter, visit our website:


Economic Times, The. Definition of ‘Product’. (n.d.). Retrieved July 21, 2017, from

Kim, Gene; Humble, Jez; Debois, Patrick; Willis, John. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations (Kindle Location 1113). IT Revolution Press. Kindle Edition.

Pichler, R. (2017, May 11). 8 Tips for Creating A Compelling Product Vision. Retrieved July 21, 2017, from

Scrum Alliance. (n.d.). The Product Vision. Retrieved July 21, 2017, from

Standish Group, The. (2010). Modernization: Clearing a Pathway to Success. Retrieved from

Image Courtesy of: