3 questions everybody should know the answer to
Whatever you’re working on, it probably needs to be delivered quickly.
There’s deadlines to meet, stakeholders to manage, and meetings to book. In all the rush of the day-to-day, it’s often hard to work out what actually needs to be achieved. Lou Downe calls this “the headless chicken of Delivery.” The chicken in question is not a specific person, but an atmosphere created by an abundance of external pressure and a scarcity of perspective.
That’s why it’s important to regularly zoom out.
I try to do this on every project I work on. As much as we all love a good old blue-sky-thinking away day, this sort of perspective is really needed at all times. Everybody on your team, every attendee of any meeting, should know the answer to these questions — or at least be trying to find the answers.
1. What problem are we trying to solve?
This is the scariest question to ask. It’s scary because it can feel like you’re the only person who doesn’t know the answer, and that if you ask it people will think you shouldn’t even be in the room. This is imposter syndrome! If you notice you feel like this, try to have confidence that the goal simply isn’t clear enough, and that other people are probably feeling the same way.
2. How do we know this is a real problem?
This is where you might start to annoy people. It’s important to remember though, that whenever we make anything, we’re placing a bet that it will have the intended effect. How much are you betting that you’re right? Do you have all the information to make that bet?
At the start of a project, you probably don’t know for sure you’re working on a real problem. In fact, every project starts with a big list of assumptions. Some things you do know, some things you just think you know, and some things you know that you don’t know. That’s why it’s important to start doing user research and gathering data that shows conclusively that it’s a real problem. Research is only as good as it’s methodology, so make sure you have someone trained in this on your team. Prototyping early on is another good way to get real confidence quickly.
3. When will we know when we’ve fixed it?
Publishing documents, deploying code, giving presentations. These are not markers of fixed problems. You need smart metrics that really prove to you that the problem is fixed. If you’ve answered question 2 already, then you know how to measure the problem so measuring the fix should be straightforward.
Where it gets more complicated is how you know that you’ve fixed it. Some problems go away on their own, others are fixed by another team with a different intervention. Be aware of this and make sure you’re measuring your impact at every stage.
These questions might seem basic, but they are surprisingly hard to answer. I’m not sure that’s the only reason people don’t ask them though — I think often people don’t feel like they have the permission to ask. If you’re reading this thinking exactly that, why not show these questions to your line manager in a one-to-one setting and see what they think?
Whatever your job title or seniority, I’d really encourage everyone to try these questions out. It might just be the difference between a successful project and a headless chicken.
