Leader Spotlight: Acknowledging and overcoming biases, with Laren Agius
Laren Agius is Director of Product at Beatport, a worldwide home of electronic music for DJs, producers, and their fans. He began his career in sales at Adidas before joining customer sales at HSBC. From there, Laren transitioned to telecom and served as a technical team leader for broadband at XLN Telecom. He later joined TSI Voice & Data as a project and product delivery manager before moving to product management at Papaya Ltd, an electronic money institution. Before his current role at Beatport, he served as a product manager at Trust Payments and Proper Group.
In our conversation, Laren talks about the importance of writing down and talking through biases before beginning the research process in product management. He shares the signals he relies on to move from ideation to building, as well as his views on what makes a true agile mindset.
Talking through biases during research
You encourage your team to write down potential biases before beginning the research process. From your perspective, what is the value of taking this step?
When you write down your biases, you activate your self-awareness. If you're an experienced researcher, your brain is inherently programmed this way, but product managers who have never performed research or focused on strategic user interviews need to flex this muscle. It’s a good starting point to get that self-awareness and also instills a culture of honesty between the team. You start seeing people thinking deeply, which activates critical thinking, and creates a safe space for collaboration.
On the flip side, when you’re running the research and synthesizing the information, there's a clear element of accountability in the process. Research involves a lot of time and money, so if you get the wrong results, you burn a lot of that. And, at the end of the day, this creates a lack of trust within the whole structure.
The last benefit of doing this is in the synthesis — it helps you build a better story. For example, our customers dig for music, i.e., they go deep inside our catalog, which is pretty extensive. Let’s say, "We assume that our customers only care about curated playlists to discover music," did we validate that? The initial bias was yes, customers care mainly about playlists, but then they organise their collections as they prepare. Through the research, we found an interesting data point that a specific segment discovers music through different touchpoints on the store. This finding created an educational point linking what we thought and what we found out to set plans in place to improve their music discovery experience.
How does the practice of talking through your biases help foster a safe space and a more productive work environment?
Writing down what you think and what your biases are opens you up to your peers. It pairs up with the element of honesty, and it also creates a fun discussion because, as you expose your thoughts, it creates a space where new ideas surface. It also enables team members to open up, and you will most likely find some peers are thinking along the same lines.
It also creates a grounding point for what questions to ask. A while back, I ran an experiment when we were preparing for user research. One team wrote down biases, then formed the questions. At the same time, I asked the other team to just form their questions on how to approach this research. What we found was that we were approaching the same hypothesis differently. The team that started with the biases focused on what we need to learn from the customer, while the other team was mainly focused on filling data gaps. Both are valid approaches and need to be balanced. This helped us build a practice to ensure we are not siloing our thinking, and are instead learning what truly matters to the customers and how solving their pain points will help the business grow.
Positioning and asking the right questions
You mentioned that after you outline the biases, you start thinking about questions to ask your customers regarding the product experience. What happens after that?
First, identify the hypothesis. Specifically, what do we need to learn? Once you understand that, it’s important to make sure everyone is on the same page. Then, you need to segment your customer. In the early days of practicing research, I wanted to talk to all of my customers, but that’s not viable. So, you need to segment based on demographics, whether they’re new or existing customers, etc. Once you have defined the segment, you need to filter it down to find the right people that you want to reach out to and learn from.
I find that a lightweight survey is an efficient way to screen customers. Surveys also help create a building block and conversation starter for when you're going to have the meeting with the customers. Through the survey it is also important to give the customer the option to opt in for an interview, as this will help you filter warm/cold leads. Additionally, use the tools you have to enrich the information about your customers and look for specific actions they completed as this can help you refine and get very granular within your segment.
While we’re screening customers, we like to work with our data analytics team to start understanding the gaps we have within the data and understand what it is telling us. This approach should help you get a good understanding of what questions to ask and which customers to speak with to help you evaluate what matters.
What pitfalls have you seen teams make in going through this process, and how can they avoid them?
Something I noticed as I started moving more into leadership is that teams fall into the same traps of getting to a paralysis point, such as asking, “Is the question good enough? Is this the perfect question?” It's a trap, and it’s easy to fall into.
The guidance I give those teams is that good enough is good. Once you know who to speak to, get started. This way, you start understanding what the customers need, rather than getting stuck on data and planning. Remember, the first user interview is always going to be clunky, but the second one is always going to be better as you start getting more confidence and improving incrementally. It’s also important to refine your questions if you feel the need to do so, as that can help maximize the impact.
In a nut shell, just get it done. Start talking to customers. The customers don't know why you're asking these questions. They're happy to participate. Just go with the flow, stick to the plan, and see where they take you.
Signals to move from ideation to building
Are there any specific signals you look for to determine whether a hypothesis is strong enough to move into build mode?
Before you do any research, you need to understand the opportunity. If it’s targeting customer acquisition, the approach will focus on how you’re going to get these customers. But if the opportunity is focusing on optimizing the engagement within your product, the approach will be different. That starting point is the most important input as it will influence, to some extent, how you're going to ask questions and to who. The easy way out is to make the data work for the opportunity, but that’s never a good idea. It's a trap you can easily fall into.
My team practices cost-benefit analysis. First we work to understand what the problem and the opportunity is, and after the interview, you're going to go through a discovery to understand how and what to build. The research gives you a pulse of whether you're on the right path or not. The discovery gives you an idea of how much it will cost and it is a good practice to build a proof of concept and see if the idea is even viable. And if it's not viable with the technology you have, then the question will be what do we need to make it work?
Then, you can decide where you want to go. You might say, “This is a good opportunity, but we're not ready for it. How do we prepare for it strategically?” That could be a longer-term play. Or, there may be an opportunity to break it down further and build a small feature to gain further engagement, add customer value, and collect feedback. That way, you build up towards the vision and steadily get to the desired outcome.
Another important signal is whether the opportunity and solution align with strategic outcomes and goals. By this stage, you would assume yes, but sometimes, you learn that you're thinking about the opportunity and the solution in a totally wrong way. Those are all important signals, and they need to work all together.
Does this approach differ as you move from one organization to another? Or is this standardized and applicable to every scenario?
It differs — what works in one company won't necessarily work exactly the same in another, and this even comes down to teams within the same company. The most important thing is to get a good read of the room. Understand what the problems of the company are and pick pieces from your and your peers’ experiences. You should never work in isolation, so this will help you see what works best for that particular team.
I've been on teams in the past where someone introduced a playbook they've used in their four previous companies. It was a very painful experience because you're doing big transitions in a short period. In most companies, if the company is successful, something is working. There might be problems, but there are always problems. If something is working, don't rip off the bandages. Poke one by one, identify where the root cause is, what you can improve, and start introducing new practices, then measure and refine.
If you introduce a new process that worked for you before, it may not work again. This happened to me before, and, surprise, the team was nowhere near ready for the change to async communication. It was chaotic. We decided to take a step back because we weren’t ready. Instead, we started building it slowly and, after a year, managed to get to async communication working.
It’s important to keep in mind that coming in and implementing a brand new process without understanding the way of working really shakes everyone to their core. It creates a pretty unstable confidence level within, and often introduces new problems.
How do you handle situations when other stakeholders might want to prioritize speed, but you want to make sure that you do thorough user research?
This comes up in every team and structure. I admit to prioritizing speed over time sometimes — it depends on the pressures. I think it's important to use all the tools that you have. In this day and age, there are so many different tools we can use. We use a mix of product analytics tools for session-based data and recording. They can help get qualitative data at scale because you can answer a lot of questions without talking to the customers.
There are also market reports you can tap into. That can save a ton of time. And surveys, too. I love them because they’re quick and easy to do. You get a lot of data fast. With everything, though, you need to be careful with the data you have. Use everything at your disposal and do it continuously, as that brings speed to research. We also aggregate as much data as possible on either a Confluence page or through JIRA. That helps build a story and keep a repository of learnings.
A data-driven agile mindset
What approach do you employ to make this continuous data loop part of the culture rather than just a task?
It's about building a habit. For us at Beatport, our customers are usually DJs and artists, so they're readily available on social media platforms of any kind. If you're a product manager of a product with a lot of online activity, you’ll see tons of comments from people. That research is done almost effortlessly.
When I find feedback on Reddit, for example, I take a screenshot or copy-paste the link to send it to myself. Then, when I have dedicated time to go through all of it, I can look into everything at once. The whole thing ends up being quick but insightful. Also, if it's being done progressively, it can take a lot of time, but by doing it continuously and in short doses, it becomes easy. It actually becomes fun because I find myself and my team connecting with those customers. We can reply to Reddit comments, and suddenly, we’re collaborating organically.
Also, in the music industry, artists want to connect. They’re social butterflies, but I’ve also seen this effect working in banks. When I was in fintech and telecom, there were still so many conversations going on. I recommend people use whatever they can to talk within the industry. You'll be amazed at how much you learn from different points of view and it helps you shape your next opportunity for growth.
Lastly, you’ve shared that you see agile as a mindset and not just a framework. Can you break this sentiment down for us?
I would say it's very subjective. From my past experiences, using a tool and a framework doesn't make you agile. I've seen teams and companies using sprints, JIRA, and all the tools, but they were still running projects using waterfall. There's nothing wrong with waterfall, but people aren’t calling it like it is.
The way I see the agile mindset, it should inherently be based on collaboration. You need to be open to connect, learn, and understand where the problems are. The sooner you understand the problem, the sooner you can make small adjustments to where you're going.
Also, you're constantly in collaboration with your stakeholders and the customer. You're adding value to the customer. You might launch an MVP, but maybe you have a bigger initiative that you want to complete. If there are opportunities where you can start incrementally releasing, the functionality becomes the system that you're building. Doing that in a good iterative process comes from a mindset.
Finally is adapting to change. We live in a very fast-paced world. Technology is evolving at a rapid pace right now. You need to be able to fail fast, but deliver value continuously.