Why we do watch parties at Fyxer
How we get closer to customers five days a week
Yesterday, I was sat in a room with eight engineers and our CTO explaining why we should put Maltesers in popcorn.
A surreal moment.
Is this real work?
Yes, yes it is.
Let’s rewind.
Every product team thinks they’re customer obsessed.
In practice, most research is something done in individual projects and presented back in bullets.
The problem is not that the insights are wrong - it’s that they’re second hand; there’s a gap between the builders and the problem they’re building for.
Shock: intuition doesn’t come from reading. It comes from doing.
When a builder does the research themselves, they don’t inherit an opinion. They’re seeing the problem first hand and forming their own judgement.
Short term, it may feel new, uncomfortable, time-consuming. Long term it means the whole team can make better decisions.
If it’s so good, why doesn’t everyone do it?
Time.
And access.
So, three weeks ago, we decided to try something new.
We started experimenting with watch parties in the office.
What’s a watch party?
It’s where a group of builders sit in a room watching customers.
Companies like Wise, Google Ventures, Skyscanner and others run watch parties to help get stakeholders closer to customers and scale UX research.
For Fyxer, that means eight or so product engineers gather in our biggest meeting room to watch a recording of someone’s screen as they work, sometimes with snacks 🍿 Our product marketing manager sourced recordings from the team and customers, so we have MP4s ready to play.
We occasionally pause to chat about what we see, and we go round at the end to share one friction we noticed at the end.
It was an idea from our CTO to do these twice a week, along with daily ‘product shadowing’ sessions.
Shadowing is where a handful of engineers literally stand behind people as they work. Luckily for us, we have colleagues who are our target customers (so we can explain why it’s not meant to be creepy). For other companies these might be trickier to organize.
In both shadowing and watch parties, we’re looking for friction in peoples’ workflow, and any current behaviors and coping mechanisms to these frictions. ‘Friction’ comes out in many ways:
Repetitive or repeat tasks
Context switching
Excess scrolling
Excess clicking or highlighting
Delays or pauses
Missteps and mistakes
Number of windows open, tabs, screens
Time to complete tasks
Number of steps or destinations in a flow
When shadowing you can ask in the moment why someone is acting the way they are. With watching screen recording, we can’t ask ‘why’.
Observation shows you the “what” with no fluff or lies. Interviews help you understand the “why”. Experiments prove whether any of that actually matters for your commercial metrics.
Hence why no single method is enough.
Where watch parties sit within the broader insights stack
Let’s be clear: watch parties aren’t a replacement for interviews or AB testing.
They’re not analytics. They’re not customer calls.
They sit in the juicy space in between.
They’re for identifying new problems to solve, or ways that your current product isn’t hitting the mark. Because you’re observing behaviour directly, you remove some of the distortion that comes from memory and self report in interviews.
Watching someone struggle with something is very powerful too - it inspires ideas, creates urgency and energy within the team.
But it doesn’t automatically mean the problem is worth solving.
Maybe the person you’re watching enjoys that friction. Maybe the 100-tab Chrome browser gives them a dopamine hit when they close them all 🫠
As a product or growth person, you need to separate:
Problem: is there one?
Demand: is there interest in solving the problem?
Impact: does solving it meaningfully move business metrics?
Watch parties help with the first one (sometimes the second). The rest of your testing work can answer the rest.
Here’s a full summary of where watching users sits within other testing methods:
The simplest way I think about it:
Watch parties make everyone in the room uncomfortable at the same time. The rest of the challenge involves working out whether that discomfort deserves to be solved.
To end: the three reasons you should do watch parties
Even though they’re not perfect (but realistically, what is?) here are three main reasons watch parties are becoming a team staple for us:
Reason 1) Problem alignment
When the whole team has watched the same awkward pause, the same excessive tab switching, the same slightly awks workaround, our conversations in the office change from ‘is there a problem to solve’ to ‘how can we solve this?’ and ‘will this have an impact’?
Meaning we’re one step closer to an impactful product.
Reason 2) Operational ease
They’re so scalable and easy on the product ops 😮💨
These sessions don’t require 6 hours of my time for 12 separate user research calls where I add an engineer into each.
You can run them twice a week for 45 minutes each, and add as many people to the meeting as you want (until someone’s too far away from the screen to see).
And finally, 3) Distributing intuition
When we’ve collectively watched tens of hours of a customer’s workflow, we’re closer to how they actually work. We start to recognize patterns without needing them explained. We don’t need a deck and wasted time communicating this.
Short term, we have fewer assumptions and more evidence.
Long term, we’re scaling product sense within the team 🤘
What next?
Now you know what snack selection to bring - and how to run them - have a go, let me know how it goes.