So you’ve got the brief for the next project, a clear business problem that you need to solve. Or maybe it’s an instruction to build a new initiative, an epic or single user story to work on. Whichever it is, you’ll want to run some kind of kick-off to get everyone on the same page before you dive too deep into product planning.
If you want to build the right thing, you’ll need to start with an experimental mindset.
Focus on learning how to achieve a measurable output rather than a delivery goal. But you have limited time, and getting everyone in the room at the same time can be a real problem. So when you get everyone together, you need to ask the right questions to get everything your team needs in the shortest amount of time.
Below are the 5 simple project kick-off questions the design team at Envato ask. They should give you enough to get started.
1. What do we know we know?
The first step is to list out all the information or data that you already have.
You may have to prepare this beforehand. Anything that will help you make decisions during the process of running the project, like things you have learnt from previous projects, or data collected from research. The important part is to question as a team whether the information is fact or if it is an assumption.
If it’s an assumption you’ll need to move it to question 2.
2. What do we know we don’t know?
This question is all about listing all our assumptions about the project.
What is the expected outcome of running this project? What does our gut feeling tell us is the right thing to do?
Don’t forget the answers from question one that we decided weren’t based on actual facts. It’s worth discussing what happens to these assumptions if they happen to be wrong. This will help you decide how important each assumption is, based on the risk involved.
3. What don’t we know that we know?
Sounds like a strange question to ask, but the team has probably done lots of similar projects. They have encountered the same problems again and again.
Asking this question will uncover a lot of information buried in that experience. Have people on the team worked on similar things in the past, how did it go, what happened etc.
4. What don’t we know that we don’t know?
This one sounds even stranger. But this is really important.
It’s about discovering all the risks in the project. What are the things that could make the project fail, is there anything we haven’t even thought about yet? You then need to consider the impact of these risks and the importance of turning these unknowns into knowledge as quickly as possible.
5. What does success look like?
This question is slightly different to the others. It’s about the team gaining a shared understanding of success.
If the whole team can agree on a way of measuring the outcome of the project, they will work far better together in achieving that success. It’s important to define a really clear, measurable way to determine success. It should be based on a fact and should be impossible to argue against. This measure also allows you to define when you are done and can move on to the next project.
Once you’ve answered the above questions, you should have enough information to get started—although you will likely uncover more.
You’ve listed your assumptions about the project. You’ve uncovered the risk and talked about the knowledge you already have. The team has a shared understanding of the goal of the project, based on a clear measurable outcome.
You’ve achieved a lot in a really short amount of time. The team can now move forward together—with this shared understanding. You will turn the unknowns into assumptions. These assumptions will lead to hypotheses. Those will lead to experiments leading to knowledge. The risks you discovered force you to test the riskiest hypotheses and build the right knowledge, helping you discover the right thing to build.
This article was originally published on UXPin.