Use the 7 Product Dimensions Model to Guide Product Discovery and MMP Design

In their book Discover to Deliver: Agile Product Planning and Analysis, authors Ellen Gottesdiener and Mary Gorman introduced a simple and powerful model to guide product discovery effort – The 7 Product Dimensions model. This model identifies 7 areas (product dimensions) that we will need to explore – through collaborative questioning and reflection – in order to learn more about the product. The dimensions are User (who the users are), Interface (how they interact with the product), Actions (what they can do), Data (what data the product needs/stores in order to work), Control (rules & constraints), Environment (platforms that would host the product/on which value will be delivered), and Quality Attribute (customer’s expectations around quality, usability, etc.). The premise is simple: if we ask good, powerful questions about each of these dimensions, we’ll learn a great deal about this product we want to build, which will help us build a better product. You can find more information about the 7 Product Dimensions framework and canvas Here^[1]

Here are some of the questions that we could ask to discover more about each product dimension:

• User: Who are the people/systems/devices that will use/directly interface with this product?
• Interface: What will the interface look like? do we need to interface with any external databases or systems? What technical design will satisfy the user experience? What APIs do we need for the actions to communicate with business systems?
• Actions: What type of actions will users take when using this product (reflect on the capabilities identified earlier)? What are the capabilities the product offers its users? (e.g. search for subscriptions, establish an account, purchase a subscription, modify a subscription, purchase equipment, and modify an account, etc.) Does the team have the skills and knowledge to implement these actions?
• Data: The data dimension identifies the data and information the product retains. What data is needed to support those user actions? What data is most useful for the business to understand user behavior and assess the value this product has created to the customer? Where do we store, protect, and expose the data?
• Control: The control dimension identifies constraints that need to be enforced, usually in the form of policies and regulations implemented as business rules. Are there any constraints on what the users can do/what they can access on this product? what regulations or internal policies do we (the business) need to conform to for this product? How do we ensure that the product interface is secure? 
• Environment: The environment dimension represents the product’s hardware and software platforms. Will the product work on smartphones, tablets, etc.? Which ones? Which software and hardware platforms will be used?
• Quality Attributes: The quality attribute dimension represents the properties that qualify the product’s development and operation. What are our customers’ expectations regarding things like speed, usability, performance, availability, etc.? can the product scale to meet peak times and still maintain a reasonable response time?

Next, I will show how to facilitate a workshop based on this model early in the project to uncover assumptions, share mental models, and ensure that everyone’s on the same page. This is where the real value of this exercise lies. I say this because I often see teams and facilitators run this (and other) activities as if they were “checkbox” exercises, going through the motions, following the steps one by one, but little ‘real’ conversations of substance take place. As a facilitator, always keep in mind that the mechanics of these activities are just to facilitate the sharing of ideas in a psychologically safe environment, the mechanics are not why we’re doing it. The conversation is what is really important.

Design Your MMP Using the 7 Product Dimensions Framework

Agile is powerful because it allows us to deliver value to our customers in successive slices – increments – of value. This has obvious advantages: 

• Your customers start getting value from your product sooner
• The nature of product development in a complex environment means that we will need to make A LOT of assumptions as we plan & design a new product, even if it is – as in our case – an improvement/replacement of an existing product. With frequent value delivery, we get to test & validate those assumptions early on, allowing us to correct course with a little cost if some of our initial assumptions turned out to be wrong 
• You end up building a product that is a much better fit for the changing and evolving needs of your customers. Every time you release an increment of your product to your customers, they interact with it and you receive feedback. You use that feedback to improve the overall product. As your customers' priorities inevitably change, you pivot to address and incorporate that change – a strategy only possible because the product isn’t built as one indivisible piece whose every aspect has been planned, analyzed, designed, and locked in well in advance, but as a series of dynamic product increments, each analyzed, planned and designed just in time, each delivering value to the customer.

The Minimum Marketable Product (MMP) is the smallest piece of functionality that can be delivered that has value to the customer and the business and provides us with valuable feedback about whether we’re building the right functionality and also whether we are building it right. We say the smallest because we want to start receiving feedback ASAP – we want to provide our customers with a valuable first increment, but we also want to do that fast so that we can validate our assumptions and start learning quickly.

The second M in MMP (Marketable) is equally important. The MMP should contain all of the pieces that are required for value realization – not just features and capabilities, but also all the necessary training, documentation, operational support, etc. Releasing the MMP may include things like launching an advertising campaign, getting regulatory approval, etc. The MMP is not a throwaway prototype.

A challenge that many teams face is determining what goes into the MMP. How do we determine which features or capabilities should be available in the MMP? How do we handle non-functional requirements such as scalability, performance, security, etc.? Should the MMP be available on every possible platform (mobile, tablet, etc.) or should we focus on supporting only one platform for the first few increments and expand support to other platforms later? Etc.

We can use the 7 Product Dimensions model from the previous exercise to help us design our MMP.

source: here

To design the MMP, first identify the highest value/most important options in each of the 7 dimensions in the model (user, interface, action, data, control, environment & quality attribute). The MMP is simply the assembly of these high-value options (see diagram above).

But what does a high-value option really mean? How do we prioritize options within each product dimension? High-value options are what we consider Must-haves (a must-have option is one that is so critical to delivering a viable MMP that there’s no point in delivering the MMP without it). To decide whether an option within a dimension is a must-have (and therefore belongs to the MMP) or not, explore the following question together as a team: is it possible to deliver a viable MMP – a product increment that not only works but delivers value to the customer and the business and allows us to learn and gather valuable feedback – without this option? If the answer is anything other than an enthusiastic NO, the option isn’t a Must-have.