Most product teams do not know, discuss or follow their implicit assumptions. These can be assumptions about the market, the user's needs or the technology. This creates a big and hidden problem for many teams: working on the basis of unspoken key assumptions poses a big risk to the product. What if an assumption turns out to be wrong? That could derail the entire product idea! Thanks to the Dunning-Kruger effect, I would even say that the less a team knows about its assumptions, the more confidence it has in a great product.
Our solution to this is to treat the assumptions in the same way as the tasks. We use this to critically examine why and how we build our products. Assumptions are not there to be validated, as many people put it, but to be tested! Testing an assumption should start with trying to prove it wrong, not with trying to prove it right. It is always easy to find reasons for something - but will it stand up to an advocatus diaboli trying to dismantle it?
This process may sound cumbersome, intellectually challenging and labour intensive. And that's true, it is all of those things. But I think that's good news: If it's hard, your competition probably won't make it! And even if it's hard, it will end up saving time and money that other teams waste by building the wrong features in the wrong way. So let's get started: What is an Assumption Board and how can you integrate it into your process?
The Assumption Board
This board works exactly like the sprint or development board you know from SCRUM or KanBan. It is a board with tickets that move through several stages that track the work to be done. Here are the stages:
Like a backlog, this is the inbox, the beginning of the journey of any adoption. When a project is launched, this should be populated in a workshop with the product team and stakeholders. An assumption takes the form "We assume that ...", e.g. "We assume that users are overwhelmed by the amount of features in competitor A's app".
Questions (ToDo, Sprint Backlog)
From an assumption we need to derive a question that allows us to test that assumption. The wording of the question is crucial because it will determine what kind of answers we get. The question should test the assumption, but not steer it in any direction. If you are too concerned with this issue, it may help to ask a colleague to formulate a critical, neutral question. An example might be: "More than 90% of the features in competitor B's product A are never used". A question directly represents a task for a UX designer or reseacher (or simply any person who cares about this question) that can be addressed by thinking up ways to answer it.
The process of researching a question first involves creating an experiment to collect data. Depending on the question, this can be a shadow of the users, contextual research, interviews, surveys, statistics, usability tests or many other common UX methods. This step includes planning and conducting the experiment as well as analysing the collected data and drawing conclusions related to the question. The whole process and structure should be traced in the respective ticket to make it transparent for each reviewer.
Every good scientific experiment is reviewed, and only a reviewed and critically examined conclusion is safe as a basis for decision-making. Therefore, in this step, a colleague should look at the whole process, methods, data and conclusions. If more data needs to be collected to address a reviewer's concerns, so be it.
Once the search has been carried out and checked, the ticket is ready to move on. There are two paths it can take: Questions that touch the core of the product become strategic resources. They are either kept in this board for documentation or moved to an internal wiki or other form of strategic documentation. It is important to find a visible place for it, as this knowledge should be used to guide future decisions.
Questions that ask more specific questions about the product become feature ideas and go into the development backlog. There, the product owner may need to consult with designers and developers to get an idea of what the implementation effort would be, and clarify with the researcher what the benefit to the user would be. With this information, the product owner can then prioritise the feature within the development backlog where it is now. It is beneficial to keep this ticket and move it forward so that anyone who touches it in the future can access all the research data, methods and conclusions.
Once this approach is fully integrated into the development process - all feature ideas go through the Assumption Board before being scheduled into a development sprint - it has the power to realign not only the development process but also the entire product. It is the fact-based way to develop products that does not rely on guessing games and pure luck to find the right solution.