Problem Framing

‘Let’s run a Design Sprint’

‘Great, what’s the challenge?’

‘Oh, I don’t know, we have lots of challenges’

This is a frequent occurrence in the Design Sprint world. Great teams come together and jump into a Design Sprint without a particular problem or challenge. So what you say?

Well a couple of things can happen if the above takes place:

1. The Sprint is a failure as the team need more time to decide on a challenge worth tackling and such don’t have enough time to complete all the necessary exercises OR the team has chosen a challenge hastily and then find out it’s not the right challenge to be tackling for this Sprint.

2. The chosen challenge hasn’t been validated, i.e is there really a problem that needs to be solved?. This means the team need to do more research to make sure they are tackling a problem worth solving.

3. The right people are not in the room and may have to start all over again. A Sprint consists of generally 7 participants, in most cases a lot more than 7 people have a say on the particular challenge. For example, some key c-suite or senior team members may not be able to block off the time and if the team run go into a Sprint without a clear challenge, there is no alignment outside of the team. This will cause further delays and problems when it comes to green lighting a validated project later down the line.

Enter Problem Framing.

Problem Framing is a technique used to figure out where your team should focus their energy.

In this meetup we will be showing you the steps to conducting a Problem Framing session, as well as doing a couple of the steps on the day. This will be an interactive session.