Happy Teams = Better Products
I recently attended the London edition of the Mind the Product Conference at the Barbican Centre, a product management conference geared towards sharing the lessons, practices and tools that have helped some of the world’s most successful products grow. Amongst the various talks ranging from How to build awesome customer experience using the Kano Model and 5 Psychological Principles of Persuasive Design nestled a talk by Nilan Peiris, the VP of Growth at TransferWise.
Now I saw Nilan speak at the first Growth Hackers Conference last year, and obviously given the audience the talk was focused, much more on the latest ‘hacks’ that he’d developed and employed to help TransferWise grow. This time, however, his talk focused purely on one topic, Culture, with his premise being How do you build a culture that builds product that grows itself? I was intrigued.
In one of his slides, flashed a tweet from, Kristo Käärmann (Co-founder CEO @ TransferWise), claiming that:
“Our product is purely an outcome of the people we hire and the decisions they make. Once on board, the biggest influence is culture — the basis for decision making and their shared values.”
Given my recent transition from Product Manager (where I felt my focus was primarily on shaping great products) to Agile Coach (where my focus is now on shaping great teams and enabling them to build great products), it’s fair to say that I was overjoyed with this statement. Particularly given that it’s come from two people that I admire and who are working hard to give something back to the customer, obviously making a little money along the way.
That said, it got me thinking. If Culture is so vital in the success of a product, with many of the world’s most successful companies expressing the importance Culture plays in their growth, then what is the key to creating the right one? Surely, it can’t just be the output of the people you hire?
Personally, I think it extends to something more than that. For me it revolves around making those that you hire happy. Largely because even if you hire the most talented of individuals, if they’re unhappy then they will never be motivated to apply their talent to it’s fullest, and, perhaps more importantly when it comes to making a product successful, apply it in pursuit of another’s vision. To paraphrase renowned theologian Albert Schweitzer:
“Happiness is the key to success, if you (and your team) love what you do then you (your product and your business) will be successful”.
To most this might seem like a no-brainer, for it is well established that happy people are more productive than those that aren’t. Obviously productivity is not necessarily a measure of quality, but it’s clear that happiness (and well-being for that matter) is on some level an essential component of building truly great products. Whether that be in creating a healthy, nurturing environment within which teams can create products or in fostering a culture of happiness that supports growth.
Why is it then that many continue to ignore the happiness of the actual team responsible for creating the product in favour of other outputs like a team’s speed or efficiency. Maybe it’s because they’re easier to measure and less subjective. Or maybe, it’s some deep-seated notion that stems from decades of established and unchallenged management theory, where processes have been engineered to ensure predictability, leading us to subconsciously focus on a team’s speed and efficiency rather than their happiness and its effect on the quality of their output. A bit of a leap perhaps, but it does make me wonder.
Perhaps the biggest culprit leading us to draw our focus away from happiness is that many of those responsible for developing great products have got slightly lost in the hype that surrounds them. Preferring to spend time focusing on defining their MVP, MLP or MMF (I mean come on…) or discovering the latest ‘growth hacks’, rather than utilising what’s right in front of them, their team.
So if I feel so strongly that the happiness of a team does have an impact on the quality of their output, then what do I think makes a team happy? Here’s my best effort based on what I’ve observed so far:
- Purpose — teams need to be provided with a goal, preferably one they have input into setting. They want to be given a problem to solve, not an instruction manual of how to solve it.
- Trust — teams need to be trusted to make their own decisions, which means they need to work in an environment in which they feel comfortable experimenting and can learn from those decisions as quickly as possible to assess whether they were the right ones to make. They also need to trust each other and feel comfortable “handing over their lego” to others who feel more confident in solving a particular challenge (or at least experimenting). ‘The Sliding Scale of Giving a Fuck’, developed by Cap Watkins, is an excellent method for dealing with the inevitable discomfort individuals face with this problem when adapting to work in a high-functioning team.
- Diversity — they need a variety of opinions, experiences and skill sets. And I’m not talking about creating a team simply with a variety of roles and levels of seniority, I’m specifically speaking to the healthy tension and discussion that stems from having a truly diverse team and is necessary in order for each individual to challenge their assumptions and confront their biases in the best interest of the team and the product.
- Access — to the right tools, to knowledge, to users and to resources. I’m not saying pander to their every need, as there must always be a rationale behind every request, but give them whatever they feel they need to achieve their goal. With regards to access to users, I would encourage each and every team member into meeting with the product’s intended users. For without empathy for the problems they’re facing, how can the team be expected to solve them well.
- Focus — you cannot force someone to focus on a specific task, but you can try to remove all the negative distractions that surround them. Just be sure that you understand the root cause of any distraction and it’s effect on each team member before removing it, as often one person’s distraction is another’s inspiration.
Rather than just leaving it there, I thought it might be a good idea to put my words into action (for talk - action = shit). So over the next few months, I’ll be using some of tools and processes that can help measure a team’s happiness to better understand how the principles I’ve suggested above effect the relationship between the happiness of teams responsible for building products and the quality of those products. I hope you’ll join me on this journey. Until next time.
There may be some who are reading this that are thinking ‘of course successful companies can afford to invest in things like happiness and culture, they don’t have worry about keeping the lights on.’ Well, as with all ideologies, I urge you, to consider this as something to strive towards. Start by identifying something small, something achievable that will have an immediate impact. Do it. Reflect. And then using your newly acquired knowledge identify a suitable next step. Repeat.