Failures and trust recipe for product teams
Over the years of hands-on experience, as a UX designer brought into product teams or single delivery projects, I have never felt more assured about how important it is to have the right people in your team and a delivery process set up at the company to empower people to feel secure, deliver and achieve more than just enough.
I wonder how many designers, developers, writers are working in teams right now where the basic foundation of trust is not quite there? And how damaging is that to the product, service, more importantly, the team itself?
I used to talk about the ‘freedom to fail’ in my last role because I thought it was such a powerful UX mantra, i.e. truly reflecting the users' needs and doing that early and often via testing, iterating, releasing so on. And it is.
But now I understand that even before we want to engage users, we need to make certain that the freedom to fail is alive and well within the team. I'm not talking about the product at this stage, I'm talking about the PEOPLE in the team.
I believe success in a team begins before the MVP or beta ships. Before the focused sprint release pushes that feature.
So what is success and how can you build it in?
High performing teams can be a coalescence of:
- Talented people
- Variety of skill sets | the right people for the job
- Clear product vision and roadmap
- Real-time | cloud-based collaboration
- Agile processes
- Right hardware and software for the job
- Well managed short term projects | long term projects
- Food. lots of it.
But we can take it a step back if you really want to build a successful product team.
TRUST. Trust is the bedrock of a well functioning, high performing, successful product team.
When your team is empowered with ‘freedom to fail’, in themselves and the tasks they carry out, the frequency of failures rise — and the learnings GROW.
Learnings from failures are the real measures of success, as the wins lie in understanding what doesn’t work well or as we expected. These are the pivotal new things we uncover in our own work. Again, this is including the discoveries in our own failures on the job as well as learning from user testing. The failure learnings can start earlier.
Being able to talk about these failures and bring these to the table is called knowledge sharing. In societies where women are educated, the rate of economic success and societal progression rises. This is a bigger lens view of knowledge sharing, but still one of my faves and it’s applicable because we are still talking about education. I'm saying — isn’t knowledge sharing incredibly powerful and think how much knowledge lies in failures.
How to build it in can be different for teams, they are all unique. A good place to start is to create empathy among the team. Before you launch into a delivery, learn about each other. Take an hour or so to have a session where everyone can bring something to eat and something to share. (see what I’m doing here ; )
A good UX task to complement the above is a Hopes and Fear exercise to uncover expectations and doubts about the new project. Get them used to sharing ahead of delivering. Trust builds in naturally when the team realises that its not ‘you on trial’, but more of ‘how can we do this better for the iteration’ and ‘thanks for bringing such a good info snack, we can use this!’
My last expression is on celebration. Acknowledge and celebrate your teammates in the good times. Because it shouldn’t be only the bad times that make the headlines. Positivity in the workplace, in a team, is infectious and delightful.
