September 11, 2020
How many research projects fail? If failure is defined as nothing concrete resulting from the research, then I’d argue quite a few. More than I’d care to admit from a personal perspective.
Whilst anything and everything can go wrong once a project is underway (I once ran a usability lab with lots of small children, during which my bold new tactic of “let’s feed them all lots of sweets to keep them happy” failed to revolutionise childcare in the way I’d hoped), it’s the initial kick-off stage which is most often at fault. This might be down to basic expertise issues such as failing to understand the relationship between sugar and 5 year olds, or it might be because of more fundamental problems such as the internal politics of big organisations. Regardless, I’ve learned to apply four key lessons which can help you set up for success.
It sounds simple - speak with the person who is responsible for the project before it starts - but this can be deceptively complex when working with larger companies. I’ve learned the hard way to always apply “the two degree rule”: don’t just meet with your boss, find out as much as you can about their boss - and ideally the next person up the chain as well. The current state of relationships between these people will tell you a lot about what you’re going into.
Sometimes the person ostensibly in charge has just had this responsibility delegated to them from above: they might understand little and care even less about what you’re doing, just so long as their boss is happy with the results once you’re finished. In the worst instances you might be two rungs down from the person you’re vicariously working for, but they’ll still be the ultimate judge of whether the work you’ve done was successful.
Your best option in these situations is to never be afraid of simple questions. Asking outright “what does good look like?”, or “what’s the best outcome you’re hoping to achieve with this?” doesn’t make you look naive or inexperienced - it just gives you a chance to discern whether the goals of your project are being set by the person you’re talking to, or somebody else you might need a quick chat with. Determining this at the outset is the only way to successfully achieve step two:
You know who you’re working for, but do you know what they want? Whilst this again might sound obvious, think of the last project you worked on which didn’t go well, and try and fill in the below equation:
For this project to succeed, X needs to do Y in order to achieve Z
The projects I’ve worked on which didn’t succeed are the ones where I’ve had a very different answer to this equation at the end than I did at the beginning. Sometimes it’s because I failed to follow Rule 1, and didn’t realise until it was too late that the answer was:
The boss of my boss needs to present a coherent long-term product strategy to the board in order to not get fired
Most of the time projects will be a lot simpler, and will involve giving a Designer or a Product Manager what they need to improve a particular feature. Even here though subtleties can creep in which are best dealt with at the outset: does the feature need a rapid iteration before a more important project starts next week? Or is there scope to go deeper and think about whether the feature even needs to be there? Never be shy of asking such blunt questions. It’s much worse to try and proceed when you don’t have the right answers.
As well as the equation above, try thinking about which single metric is most relevant to the topic you’re researching. Is it that amount of time users spend on something? The average cart value? Conversion rate? Registered users? The best way to define success is to be explicit about how you intend to measure it.
Again, this can be more subtle than it first looks. Occasionally I’ve been asked to deliver things which are outside of my expertise - which is very much on the qualitative rather than the quantitative side of things. A Director once asked my team to deliver something which was much more data-driven - and because I hadn’t properly conducted Step 2, I incorrectly interpreted this as “you need to do this otherwise I’ll fire you and find somebody else”.
As it turns out, only the last part was true - this was clearly a job for someone with a different skillset than me, and I was able to connect my Director to the relevant team. Unfortunately this only happened after I’d spent a great deal of time and effort attempting to complete a task I wasn’t able to do to any useful standard. Confidence is often more about being up front with what you can’t do than what you can. Now every project I do with Filo starts off with me spelling this out for anyone we work with, so they know exactly what we’re able to deliver - as well as what we can’t.
If being so forthright about things you can’t do sounds like a risk, then it’s one which is easily mitigated by following the fourth and final step to a successful kick-off:
It doesn’t matter what it is: old agency reports; transcripts of usability labs; onboarding materials used to explain how your company works to new staff - the more material you have, the better. I’ve lost count of the number of times I’ve accidentally duplicated something which already exists. Now we always make sure we audit what’s already been done before starting a new project. You don’t have to wade through every single line of every single document, but you do need to know which documents do and don’t exist. At the very least this will tell you where the gaps in your company’s knowledge are which your project intends to fill. The more explicit you can be about this, the better.
These four principles can help any project get off to the right start. The next step then is to share what you produce at the earliest moment possible. For us, that means committing up front to completing an audit as quickly as possible.
This article is part of our "Beginners Guide to Research" series, which sees a new article uploaded every week. Drop us a line at firstname.lastname@example.org if you'd like to know more.