The 7 Product Dimensions to Guide your Agile Software Development
One of the best analysis tools I’ve found especially useful is the 7 Product Dimensions (Ellen Gottesdiener and Mary Gorman, 2012), a simple and powerful model to identify product needs at all levels of planning.
This model identifies seven areas of product dimensions that the team will need to explore- through collaborative brainstorming, questioning, and reflection, to learn more about the product. These dimensions include:
User: Who values, benefits from, or uses the product at the end? The user could be a person, another system that interacts with the product, or another device with an interface with this product.
Interface: What mechanisms should the team create to connect users with the product? How does the product send and receive data? What will the interface look like? What APIs do we need to create for the product to communicate with other components? Do we need to interface with any external system or database? What should be the technical design to satisfy the user experience? Note: To visualize the interfaces, it is recommended that you use context diagrams, wireframes, and prototypes
Action: What are the product’s capabilities and what it offers its users? (E.g. Multiple selections, search, subscriptions, etc.) How are actions triggered, and in what sequence? How does the product respond to user interactions? Does the team have the knowledge, experience, and skills to implement these actions? Now, from a test perspective, we need to ask additional questions such as “How do actions affect data?” or “What are the potential issues that may occur where a step is skipped or done In the wrong sequence.”
Data: The data dimension is used to identify the data and information the product receives, from where, and how is the data stored and validated? Also, the team will have to ask additional questions like “What data will the user need to interact with the product?” “Where do we store, protect, and expose the data? or “what are the transitions between data states.”
Control: In this dimension, the team will focus on identifying constraints that need to be enforced, for example, regulations, business rules, internal politics to conform, etc. In addition, the team will have to answer the question of what’s the risk of non-compliance.
Environment: We need to focus on the product's physical properties in the environment dimension. This means that the team will have to answer questions like “On which type of devices will the product support?” or “What operating systems are supported?” “How will it be deployed, configured, and licensed?” or “What is the supported hardware?”.
Quality: The quality dimension represents different product attributes such as the product SLA and service levels for operational qualities such as safety, performance, usability, availability, etc. Also, the team will have to define the attributes that will be measured during development and testing, such as efficiency testability.
Although there are seven dimensions to cover, the premise is simple; all you need to do is create a list of questions that your team will answer when conducting this session. If you focus on the right questions (you have some great examples that I already provided above), you will learn a great deal about the product to build and how you will do it to meet customer expectations.
I’ve found it helpful to consider all seven dimensions in different activities such as release planning, Feature refrainment, and before starting a new iteration on the iteration planning meeting. Adding this method to my regular team activities helps the team realize what is missing and what other stories or resources are required.
For example, if the product will receive data from a third-party system, the team will have the chance to ask all questions in the ‘Data’ dimension, such as “Do we need to test the third party system or just the integration part”? Or “When should this testing start?” or “How do we generate this data” or “Will the sender and receiver will print appropriate error messages?” or “What negative data can we use to test the system recovery time?” or “What is the authentication process to receive this data?” or “Where will the data be persisted?” These are examples of preliminary questions that you can create as a checklist for this session, and I think it’s obvious when I say that they asked early as possible.
What is the suggested Facilitation Process?
There are different ways of facilitating this meeting, but here is the process that works best for me and my team:
Phase 1: Introduction, set of expectations, and model review
If your team is new to this model, you should start the meeting by explaining the model (including the seven dimensions) and setting the activity’s expectations. It is essential that you explicitly emphasize that the meeting activity is supposed to simulate conversation, and brainstorming, and push the boundaries of what we need to explore (There is no role saying that you must have a ready answer for all questions).
Phase 2: Working on the seven dimensions
Now that the team knows what to expect from the meeting, it’s time to review the dimensions one by one. A simple process that you can use for this part of the meeting:
On each dimension, present the team with the ‘prompt questions’ above (remember that they are just suggestions, add your questions). The questions are essential to the brainstorming process as they help increase people’s focus, creativity, and innovation. One thing worth mentioning to the team is that they’re not limited to answering these particular questions as presented by the facilitator- these questions are there to promote conversation and not set boundaries.
After the questions are shared with the team, give each of them (individually and silently) the time (usually a time box of 15 minutes) to think on answers and insights to the prompt questions to share with the other team members.
When the time box expires (or the team is ready prior), ask each team member to share his answers/insights per question. As part of this activity, remove duplicates and consolidate similar answers/insights.
The meeting facilitator with the team, reflect on the answers (per dimension) to check: What’s controversial? What stands out compared to other answers? Which answers have the most support from the team? Etc.
Now that you narrow the agreeable answers by the team, it’s time to start voting. You can use any voting technique the team used during the planning activities. The voting process is done per dimension per item; the facilitator will present it and let the team vote on how strongly they agree with having that idea/answer as part of the dimension. At the end of this stage, you should have a board with items ranked with priority as determined by the team.
Phase 3: Conclude the exercise
Take all items on the board and share them will the team and any other stakeholders relevant to the project. Ensure to follow up on those items during the refrainment and planning activities to transform ideas into actionable items.
Phase 4: Retrospective
Close the session by asking the team if they have more insights that they are willing to share related to the process of the meeting and what they think they will want to improve next. Take those items and make sure to use them to guarantee that this activity will be efficient as possible.