Answer This Question: “What is Your Product?”

This essay is part of the book 97 Things Every Scrum Practitioner Should Know, by Gunther Verheyen (editor)

Alice, wandering in Wonderland, said it best. “If you don’t know where you are going, any road will get you there.” This certainly applies to software development teams. Even some of the best Scrum teams can’t answer the simple question, “What is your product?” 97 Things Every Scrum Practitioner Should Know_Final Cover

Scrum is about continual discovery and delivery of products. For a product to be successful, it must be desirable to customers, viable for the business, and feasible for technologists to build and support. Notice the subject of that sentence: product. Not knowing what your product is manifests itself in numerous ways.

As intuitive as Scrum might be, the Product Owner needs to provide guidance and product oversight. The role of a Product Owner isn’t easy. Failing to define the product leads to all sorts of issues, ultimately impacting team satisfaction and product outcomes:

A plethora of Product Backlogs exist, often with the same customers and the same domain. They overlap and have items that conflict with one another. Moreover, functionality can be duplicated among multiple ‘products’. Coordinator roles such as release managers, project, or program managers are introduced. The customer experience for completing an end-to-end value stream using the product experience is clunky, laborious, and abrasive. Product Owners struggle to prioritize and provide focus. Local optimization exists, resulting in decisions, actions, and structures that impede achieving overall organizational goals. These are but a few of the maladies for not having product clarity.

Scrum Masters can facilitate the important work of helping Product Owners, the Development Team, and business stakeholders define their product. Apply these three product definition principles:

Principle 1: Adopt outside-in thinking. Define your product from the perspective of customers, both users and choosers. Users directly interact with the product to obtain some benefit or to solve a problem. Choosers are those who make buying choices. It isn’t unusual for Development Teams to create products based on their own, or their Product Owner’s, inside-out bias. Outside-in thinking, on the other hand, is both humbling and enlightening. It allows the entire Scrum Team to approach product work with empathy and curiosity.

Principle 2: Take the long view. Projects come and go. Successful products live a long and healthy life. Products evolve and morph through all stages of their lifecycle from introduction, to growth, maturing, and then decline. Products benefit from continuous discovery and delivery. New technology adoption and feature development are critical to improving your product’s value proposition. This principle reduces the need to create separate products. Innovations improve your product’s business viability, customer experience, and improve product quality.

Principle 3: Define the product as broadly as possible. A broadly defined product gives a Scrum Team more product options, simplifies communication, clarifies roles, and forces prioritization. Refraining from narrowly scoped products, enables organizations to optimize people and resources. Broadly defined products have many benefits:

  • Organizational systems optimization ensures that high-level goals are met
  • Backlog management and prioritization become simpler to manage
  • Decision-making is streamlined
  • Strategic planning and roadmapping become more straightforward to define
  • Customer and organizational communication become clearer
  • The product influences your organizational structure

Product development with Scrum requires clear product direction. Establishing a shared, consistent, and coherent answer to the fundamental question, “What is your product?” offers a huge benefit. Knowing what your product is provides the necessary foundation to deliver successful products with Scrum.

Leave a Reply

Your email address will not be published. Required fields are marked *