Today’s product development efforts focus on testing, experimenting, and getting feedback on features and functions before developing them. These new techniques and schools of thought are exciting and (if the posits guiding the features are good) should improve the abysmal success rate projects experience in delivering stuff people actually use. All too often, though, user stories that are skillfully refined, defined, decomposed and successfully delivered are ultimately deemed “bad” because people don’t see any value in the finished product. That’s where the product assumption map comes in. This map helps product owners and their stakeholders better align their assumptions about what their product is expected to do and the people they believe will use their product. This creates a repository of assumptions that can be explored and validated before committing time and money to experimenting, designing and building the functionality.
The product assumption map improves the quality of user stories by creating a matrix of the things the product is expected to do (supported roles) for the intended users (actors). The first contribution the map makes is the conversations around the things your team wants the product to do and in doing this supplies the roles the product supports. At this stage, the map focuses on helping the product definers recognize that they could have very different people with different perspectives wanting to do the same things for potentially different reasons.
Product Assumption Map: The Approach
The approach is straightforward: capture a group’s assumptions about the things the product will allow people to do. Then capture the “actors” who the team believes will want the things the product offers. The product assumption map accomplishes this in two steps. First it organizes the things your product team assumes people want to do using a thing/doer statement. Second it captures the types of people your team thinks are most likely to do those things. The end result is a map that will help you explore and validate these assumptions using Lean Startup techniques, exploratory testing, and existing marketing/product development efforts. To do this you will need 2×2 Post-its, medium-tipped markers and Flip Chart paper (and painters tape if the flip charts are not self-adhesive).
In this map, each role is described as a thing/doer relationship, a concept described in Jeff Patton’s work. The thing Doer’s post-its go across the top of the flip chart paper. Our site editor (actor), for example, fills several thing/doer roles in his job, such as blog/reviewer, image/inserter, mind/reader, mental mush/molder.
Next the team agrees on the “Actors” they believe will want to do the things the team envisions the product will provide. Each Actor is written on a post-it and lined up in the first column. I agree with Jeff Patton that formal business titles work best in identifying Actors.
You then create a table.
Next score each cell according to the frequency of use:
Total each row and column and write it on the post-it. Then find the column(s) with the highest score. This is the most frequently used Thing / Doer in your map. Total the rows and find the Actor with the highest score. This is the most pervasive Actor. The cell where these two intersect is the key feature function.
Now we are ready to test our key assumptions.
Actor/Role Smoke Test
The smoke test is the simplest test to start validating your assumptions. According to Wikipedia, the purpose of a smoke test is to “reveal simple failures severe enough to reject a prospective software release.” In this case the smoke test interrogates each assumption made about the pervasiveness of a thing/doer item and the capability of it to meet the needs of the most active actor in your product. The test can be as simple as going to people and asking them what their goal is when doing this thing as part of the role they are playing. (Hi, Salim, can you help me? As a project manager what are your expecting to get from reading the daily bug report?)
- If the actor has a goal they want to reach and a ready list of expectations, then you can place them in the appropriate actor/role cell. The more actors you ask this of the clearer the expected outcomes become. Be sure to write down the expectations as they make great acceptance criteria.
- On the other hand if the actor agrees this is a thing they would do, but does not have goal they want to achieve nor clear expectations, this could indicate more thought and conversation is needed.
- Finally if the actor looks at you strangely, mumbles under his breath, tells you to leave or calls security, it is a great indicator there are problems with that actor/role assumption. You might want to see if there is another actor that wants to do those things, or if the current actor wants to do other things.
In a few hours, teams can identify where their assumptions show convergence, divergence, and positional thinking about the things the product supports actors doing.
Assuming that you have some positive feedback, you can now focus on cross-validating the acceptance criteria with other actors in the map, using the most pervasive thing/doer column.
The most common result of this simple exercise is having everyone aligned about the things the product intends to do as well as the degree to (or not) people have an interest in what you are proposing. This may be enough for some broad scope decisions or considerations. It does not have to be the end of the exploration.
Beyond the Smoke (Exploratory Testing & Lean Startup)
Other types of tests include exploratory tests, A/B tests, context interviews, and others. If you are not familiar with testing in an agile frame, you might find Lisa Crispin’s presentation on test planning useful. You’ll also want to consider data from your marketing and product development folks.
You can also conduct simple experiments by talking to people who hold the titles of the actors in the actor/role model. There are several good approaches to testing goals and expectations. You may want to start by looking at Eric Ries’ work Lean Startup, as the concepts in this book are really a form of testing. Another source is Lisa Crispin and Janet Gregory’s book Agile Testing. It does a great job of introducing Brian Marick’s four quadrants of test, where you can get an overview of business-facing tests that critique the product (quadrant 3).
This is the latest update to the product assumption map. Updates are based on feedback and comments from users and from its role in workshops and training. If you can contribute please leave a comment so that we can get better at evaluating and validating our assumptions.