If you watch any sports, I’m sure you’re familiar with how frustrating referees can be. It seems like they are conspiring against your team and go out of their way to make bad calls.
While biases in referees do exist, it’s interesting to note that both teams feel this way. If this were true, this would mean that referees don’t want any team to win and they are just interested in screwing both sides.
I personally love basketball and have seen this referee frustration in action myself. I still remember watching the 2016 NBA finals where the Cavaliers beat the Warriors in 7 games. I would find myself yelling at the TV for what seemed like critical missed calls and injustices from the referees.
This led me thinking to how tough the referee jobs must be. They can alter the momentum of a game in a few seconds and change the entire outcome.
The NBA has also recognized this and started putting out “Officiating Last Two Minute” reports where they list out all the calls that referees made in the last two minutes of a match. They then list if this was the correct call to make in hindsight.
I love this report. The NBA is accepting that they don’t always get the calls correct and they are asking for accountability from fans and teams.
In our work, we don’t always achieve a successful project outcome despite our best intentions. Projects fail for a variety of different reasons but I wanted to list out the 5 most common issues which we learned by actually making these mistakes.
While I can’t list the specific companies or projects in which these mistakes happened, I’ll provide as much detail as possible.
Mistake #1: Incorrectly Gauging Internal Capacity for Managing Data
In this project, we incorrectly gauged how capable the team would be at managing and using the data that we implemented. If a company doesn’t have dedicated roles around data (e.g. data analyst), it is likely that they won’t be able to get much use out of their own data.
For this mistake, a better alternative would have been to provide further support or help them hire a data analyst. Our mistake here was also not communicating these issues and how they could solve them.
Mistake #2: Implementing the Wrong Tools
In this project, we ended up implementing the wrong tools. Despite our initial tool research, the tools we chose didn’t solve all the problems and this meant the company had to re-implement another tool that was a better fit.
For this mistake, further research would have helped. I also think running through scenario planning could have uncovered future issues.
Mistake #3: Focusing on The Wrong Problem
In this project, we were focusing on the wrong problem (data). The company was quite early in their journey and had bigger problems to tackle (product-market fit and user acquisition). While data can help with these problems, it’s not always the right solution.
For this mistake, we should have rejected the project and instead recommended simple data implementations that they could do internally while focusing more on qualitative data.
Mistake #4: Failing to Get Buy In From Other Teams
In this project, we failed to get buy in from other teams. We were working with the marketing team and failed to talk to the product team. Eventually, the product team made their own decisions around data which duplicated the work we were doing.
For this mistake, better business discovery could have surfaced some of these issues. We could have worked together to solve them instead of duplicating effort and resources.
These mistakes (and more) have shaped how we approach projects and the recommendations that we make on a daily basis. I hope you’re able to avoid some of these mistakes and commit to publicly admitting your mistakes.
What's next for you?
Or if you're ready to start using data to make better decisions for your product and company, then let's talk and see if we are a good fit for each other by filling out the form below. (Or you can call us at 650-203-2788).