What Is Your Product?
“So, what is your product?” That was the key question I posed in my Agile Cincinnati keynote recently.
In my product coaching work, I have come to realize that many organizations don’t have a clear and consistent answer to this fundamental question. This has serious consequences. A poorly defined product impacts your ability to respond to changing customer and market needs. It results in less than satisfying product outcomes. It causes organizational and communication woes. It thwarts organizations efforts to scale agile product development.
Everyone in your product development ecosystem should have a shared, consistent, and coherent answer to the fundamental question, “What is your product?”
You need a shared, consistent, and coherent answer to “What is Your Product?”
Image by EBG Consulting
The Five Principles
There are five principles that can help you to define your product:
1. Adopt outside-in thinking.
Many organizations erroneously define their products by taking a technology perspective. They consider the product’s underlying technologies, components, and tools and call a logical grouping of them a “product.” This approach defines the product from an engineering perspective and not from a customer perspective.
Alan Cooper’s prescient book, The Inmates are Running the Asylum, was a wake-up call back in 2004. Its title comes from the bizarre 1989 cult film by the same name involving a plot whereby an experiment mind fluid exchanges in an insane asylum that goes array. Consequently, the doctor becomes the patient and the patient becoming the doctor. Cooper (the father of Visual Basic and originator of personas) makes the point that technology products are horribly designed and make users feel stupid.
Define your product outside-in (not inside-out).
Image by Ellen Gottesdiener, EBG Consulting
This represents inside-out product thinking and it simply doesn’t work. Instead, define your product from the perspective of customers, both users and choosers. Users are those people who directly interact with the product to obtain some goal or solve a problem. Choosers are those who making buying choices. Outside-in thinking is both humbling and enlightening. It allows you to approach your product work with empathy and curiosity.
2. Take the long view.
Some seven years ago, I gave a presentation about product roadmapping with the title “Products, Not Projects.” Even before I started I noticed that some attendees, many of whom were professional project managers, were not happy with the title. Projects come and go while successful products live a long and healthy life. A healthy product evolves and morphs through its lifetime, benefiting from continuous discovery and delivery.
A healthy product has a long lifecycle, from birth
(introduction and launch) through decline.
Image by Ellen Gottesdiener, EBG Consulting
When organizations fall into the trap of viewing technology innovations as products in-and-of-themselves, they usually end up with multiple products that are serving the same customer or market. Some with the same core capabilities. This complicates organizational processes and confuses customers.
The better approach is to take the long view of your product. New technology variations and developments are part of ongoing improvements to your product’s value proposition. They can improve your product’s business viability, customer experience, and improve product quality.
A product organization taking the long view operates as a single virtual product community despite having distinct product management and product development organizations. Developers and engineers actively participate in discovery to validate technology innovations, parity imperatives, and new product capabilities. The product community invests in fast, efficient experiments before making costly changes to the product.
3. Define your product as broadly as practical.
Many organizations I work with define their products narrowly. This results in numerous kinds of organizational maladies including:
- Products with multiple overlapping and conflicting backlogs
- Functionality duplicated across multiple products
- Bottlenecks caused waiting for technology specialist teams
- Excessive coordination and product roles
Narrowly defined products lead to negative customer experience.
Image by Ellen Gottesdiener, EBG Consulting
Most importantly, narrowly defined products can result in a bifurcated user experience. Completing an end-to-end value stream using your product is clunky, laborious, and abrasive. Customers needing to communicate with the organization to solve problems or answer questions are faced with a confusing array of disparate support teams in different departments. Problems and questions are slow to resolve as the customer gets passed from department to department.
A narrowly defined product has another unfortunate side effect. It promotes a natural bias to optimize outcomes that serve only that particular product’s narrow goals. This phenomenon is known as local optimization and results in decisions, actions, and organization structures that impede the overall, and more global organizational goals.
On the other hand, when you define your product as broadly as possible, you “see the whole.” This affords you a view of a wider terrain of product options, simplifies communication, clarifies roles, and forces prioritization. Broadly defined products allow your organization to optimize people and resources for the entire organizational system. This is called systems optimization. Systems optimization through broader product definition facilitates your organization’s ability to meet your higher-level goals. It also eases and simplifies:
- Strategic planning and roadmapping
- Backlog management
- Organizational and customer communications
- Prioritization and decision making
- Role definition
Another benefit with systems optimization is simplified organizational design. This is discussed in the next section.
4. Structure must follow product.
Some organizations fall into the trap of defining products according to their organization chart. Parts of products supported by a particular functional group or reporting line is declared to be a product. Chaos and confusion ensue each time there is a reorganization. Over time, the product architecture emulates a hairball of intertwined interfaces, technology knots, Wild West of cowboy code, and cruft. The product and product team suffers from the unfortunate effect of Conway’s Law where a product’s design is “a copy of the organization’s communication structure.”
When a product is defined outside-in, your organization benefits with a more product-centric design. Feature teams and end-to-end value stream teams are formed based on customer outcomes. You have one backlog per product, which helps ease prioritization and avoids the trap of local optimization. You can learn more about local optimization pitfalls from Michael James’ excellent video about “team output owners.”
Finally, Craig Larman’s’ brilliant Laws of Organizational Behavior states that “culture follows structure”. When you have defined products in a customer-centric manner, with a long view in mind, and as broadly as possible, structure follows product.
5. Defining your product requires collaboration.
To obtain a shared definition of your product, employ team collaboration. In my keynote, I shared some of the experiments from product thinking facilitated workshops in which we defined a product through a series of progressive, interactive activities. These activities include clarifying the work of product management and ownership, using the Product Canvas, decision making rules, customer research, and value proposition canvas.
People Collaborating to Define Product
Photo from Product Definition Workshop by Ellen Gottesdiener, EBG Consulting
The Importance of Knowing Your Product
Agile product development is about continual discovery and delivery of products that are desirable to customers, viable for the business, feasible for technology people to build, and supportable. How you define your product guides drives your discovery and delivery.
The first thing to do when you are starting or reinvigorating your product organization is to answer the question, “What is your product”?
Many thanks to Andy Repton, Michael James (MJ), Cesario Ramos, and Tim Ottinger for their helpful feedback on this blog.
A Russian version of this blog is now available at Agilix Consulting. Thank you, Illia Pavlichenko!
Leave a Reply