This was my first time attending the Mind the Product conference, and I have to admit I was a bit surprised by its scale - 1700 attendees at the Barbican Centre. Admittedly, there were some big names amongst the talkers, with product leadership representation from Google, Skyscanner and Facebook to name a few.
There were a few talks that stood out for me, which are listed below along with my key learnings from each of them.
VP Product & UX at Patients Like Me
This was the first talk of the day, and one of the best in my opinion.
Kim touched on several topics that I find interesting, such as the balance of legal requirements with design considerations, or the fact that sometimes the people that we are affecting with the products that we build may not even be our direct users.
The best thing about Kim's talk for me though was the fact that she was continually asking people to think of the ramifications of the technology and solutions that we implement, and whether they are, in fact, in the best interests of our users (or society!).
I've written before about how I've occasionally been troubled by the drive of some companies to implement technological solutions which don't have a defensible balance between the benefit to the company and the corresponding benefit to the user.
As Kim pointed out, one of the reasons that companies can end up going down these cul-de-sacs is that they become to too focused on metrics which don't relate to the user. A great tip that she shared was to make sure that solutions are periodically reviewed against a set of definitions in order to ensure that the application of used-centred values is being given due consideration. The example provided was to used Marlow's Hierarchy of Needs and to ask two questions:
- Does the solution positively affect at least one of the layers of Marlow's hierarchy?
- Does the component negatively affect any of the layers of Marlow's hierarchy?
The answer to question one should always be 'Yes'.
The answer to question two should always be 'No'.
By incorporating a test like this into regular review processes, product managers are given a opportunity to frequently check the barometer of their product and make sure that they are not being led astray by metrics-centred design and that the values that their product is supposed to be providing to their audience are not being skewed by a focus purely on the technological or commercial incentives provided by a particular solution.
Principle Product Manager at Skyscanner
Rik's talk was great - for me, the main takeaway was to make sure that when approaching new development or feature implementation, it's important to adopt a truly scientific attitude.
In other words, we should do our best to frame our work around the scientific cycle - observe, ask questions, hypothesise, experiment, analyse and produce conclusions. Rinse and repeat.
One of my favourite things about how Rik talked about this was his willingness to embrace and discuss failures. He gave a couple of great examples of when Skyscanner made changes which they thought would result in progress towards their goals, but which actually achieved the opposite - in fact, his opinion was that roughly 80-90% of the experiments undertaken produced results which were contrary to the original hypothesis.
For me, all of this highlighted the importance of being resilient, and also helped me remember that the way that we communicate our results to stakeholders is important if they are to properly understand the benefits of experimentation - as Rik put it, we shouldn't be lamenting an unexpected result as a 'failure' - we should instead be celebrating the fact that we have successfully disproved one hypothesis 🙂
There were two other quick concepts from Rik's talk that I wanted to make note of:
- HARKing - HARK stands for Hypothesising After Results Known - it's a phenomenon whereby people who have set a hypothesis which has turned out to be incorrect convince themselves (after the fact) that actually, the hypothesis they really wanted to check is the one that the experimental results data supports. It's a term I hadn't heard before, but I can absolutely think of examples where I've seen this happen. Great to know there's a proper term for it!
- Design like you're right, test like you're wrong - This is the principle that we should always go into solution design with an optimistic mindset, but once we are at the stage of testing our results, we should flip that mindset around, and work hard to prove ourselves wrong. This is the best way to ensure that we're not unconsciously glazing over any issues - which, if we're honest, are only ever going to come back and bite us at some point in the future if we don't take account of them. Who do we want to find these errors - the development/product team.... or users... or our key stakeholders... or the press...? I know which I'd prefer.
Great little concepts to be aware of and to track in my own work.
Director of Product Design at Facebook
Ryan's talk was at a much higher level than some of the other sessions throughout the day at Mind the Product. It was good to get a bit of a feel for how Product teams operate in mega-scale businesses like Facebook though.
I'd say the main thing that stood out for me from Ryan's talk was the human side of both product design and development. From his own experience of joining Facebook's News Feed product team just two months before the 2016 US election ("what could possibly go wrong?") to that of his co-workers and staff members - Ryan said he can tell when Facebook is getting some negative press as there are fewer people in the office wearing branded gear, presumably to avoid awkward conversations with strangers (or acquaintances, or loved ones).
I think there's a temptation, especially when considering tech giants like Facebook, to forget that everything that we see ultimately boils down to someone's day job. And, as much as it can be easy to sometimes paint certain products or teams as 'the bad guys', the reality is that most people are just going to work and trying to do a the best job they can. No-one is setting out to be the bad guy.
The thing that trips all of this up can probably be summed up by something that Ryan said:
"Building consequential things tends to have consequences" - Ryan Freitas
None of us can argue that Facebook (and its News Feed) are inconsequential elements of the digital landscape. And this of course means that the people who maintain, curate and develop these products are always going to be open to more scrutiny, more voices, and more chances to get something wrong.
I liked the fact that Ryan acknowledged that this scrutiny really is required - that without it, sometimes companies would not spot, or give enough weight to the potential issues with their products. #
I also liked that, as a leader, Ryan sees it as part of his job to be personally resilient, in order that he can be the buffer that his team needs. I have the feeling that, given his role, he must have particularly tough skin.