Most product teams don’t know, discuss or track their implicit assumptions. Those 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 a basis of unstated major assumptions is a big risk for the product. What if an assumption turns out to be wrong? That might topple the whole product idea! Thanks to the Dunning-Kruger effect, I’d even wager that the less a team knows about their assumptions, the more confident they feel that they have a great product.
Our solution to this is to track assumptions in the same way we track 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 by trying to prove it wrong, not trying to prove it right. It’s always easy to find reasons for something – but will it withstand a devil’s advocate, trying to dismantle it?
This process might sound cumbersome, intellectually challenging and a lot of work. And that is true, it is all that. But I think this is good news: if it is hard, your competition probably won’t manage to do it! And even though it is hard, in the end, it will save 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 just like the sprint or development board that you know from SCRUM or KanBan. It’s a board of tickets that move through several stages which track the work to be done. Here are the stages:
Like a backlog, this is the inbox, the beginning of each assumption's journey. When starting a project, this should be filled up in a workshop with the product team and stakeholders. An assumption takes the form of “We assume that …”, for example “We assume that users are overwhelmed by the amount of features in competitor A’s app.”
Questions (ToDo, Sprint Backlog)
From an assumption, we have to derive a question that allows us to test this assumption. Phrasing the question is crucial because it will define what kind of answers we get. The question should examine the assumption, but not steer it into any direction. If you’re too invested in this topic, maybe asking a colleague to phrase a critical, neutral question can help. An example can be “More than 90% of features in product A from competitor B are never used.” A question directly represents a task for a UX designer or researcher (or just any person caring enough to do this kind of work), which can be tackled by thinking up ways to answer this question.
The process of researching a question first involves creating an experiment to gather data. Depending on the question, that can be shadowing of users, contextual inquiries, interviews, surveys, statistics, usability tests or many other common UX methods. This step involves designing and executing the experiment, as well as analysing the gathered data and drawing conclusions towards the question. The whole process and structure should be tracked in the respective ticket, to make it transparent for any reviewer.
Any good scientific experiment is reviewed, and only a reviewed and critically examined conclusion is safe to base decisions on. So in this step, a colleague should have a look at the whole process, methods, data and conclusions. If further data has to be collected to overcome a reviewer’s concerns, so be it.
Once the research has been done and reviewed, the ticket is ready to move on. There are two paths it can take:
Questions that touch the core of the product turn into strategic resources. They are either kept in this board for documentation, or moved into an internal wiki or other form of strategic documentation. It’s important to find a visible place for it, since this knowledge should be used to guide future decisions.
Questions that ask more concrete questions about the product turn into feature ideas and move into the development backlog. There, the product owner might need to check with designers and developers to get an idea how high the implementation effort would be, and check with the researcher to determine how high the user benefit would be. With this information, the product owner can then prioritise the feature inside the development backlog, where it now lives. It’s beneficial to keep this ticket and move it further, so everyone who touches it in the future can access all the research data, methods and conclusions.
Once fully integrated into the development process – all feature ideas move through the assumption board before being planned into a development sprint — this approach has the power to refocus not only the development process, but also the whole product. It’s the fact-based way to develop products that’s not reliant on guessing games and plain luck to find the right focus for the product. Instead, it will uncover risks, streamline decisions and ensure the oh-so-expensive development time is used wisely.