“Fall in love with the problem” they said — or how we validated we are tackling a problem worth solving

When working on a new idea or product, you can easily fall into the trap of building a solution in search of a problem or solving a problem that customers don’t care enough about. This is something that we, Jana and Mihri, consciously wanted to avoid when we started working on Beams.

We would be lying if we said we didn’t have any solution in mind before we validated the problem space — It’s simply human to think in terms of solutions rather than problems first. And that’s actually alright, as in many cases there is a legitimate problem behind that potential solution you have in mind. But instead of building something that might not solve the problem, it’s a good idea to first ensure that you truly understand the underlying problem and that your motivation is primarily to solve that problem.

In the following, we want to share how we went about our initial user research that aimed at validating the problem space and what we learned along the way.

Using a combination of qualitative and quantitative research methods

We knew we wanted to tackle a problem that we have been experiencing ourselves and we wanted to solve it for people like us. As one software engineer and one product manager some of the most frustrating challenges for us have been countless context switches, constant distraction and lack of focus at work. When going remote during the pandemic, this problem became even more prevalent.

Before testing any kind of ideas or solutions, we wanted to validate that this problem is top of mind for other people as well. Our goal was to get answers to the following questions:

1. Is this problem big enough and is it worth solving?
2. Who suffers most from it? Are our customers who we think they are?
3. What are their behaviours at their digital workplace? And what is actually causing the problem and why?
4. What solutions have they tried to solve this problem?

We believe in the value of exploratory qualitative research methods and enhance it with quantitative research methods to see patterns in what people do. In our case, most of the research efforts went into user interviews and focus groups for co-creation sessions (qualitative) as well as a survey and screen time analysis (quantitative).

Talking to potential users and truly understanding their pain points

Having conducted hundreds of user interviews in our previous jobs, we’ve been experiencing the value of user-centricity first hand, as it allows you to really dig deeper and ask about the why. It is helpful in generating hypotheses and identifying risks associated with your concept. This is why it has been our guiding principle from day one. But we’ve also experienced how difficult it is to get it right. It’s easy to ask biased questions when you’re passionate about something or to talk to the wrong people. It’s also easy to make wrong conclusions and end up building something that no one really understands or wants.

In the first two weeks we ensured to speak to 20 people per week and until today we try to conduct at least five user conversations every week (even though the purpose and focus of the conversation has been shifting significantly).

When conducting user interviews a proper preparation, well-guided conversations with open-ended questions that talk about specifics not hypotheticals, and a thorough evaluation of research insights is key.

Enhancing insights from user interviews with qualitative research methods

We also created a survey where we asked a broad range of people what tools people use most regularly at work. The goal of this survey was to better understand people’s behaviours and preferences when it comes to work tools. This helped us later to decide what tools we would start with for our prototype.

And finally, we got really interesting insights from asking people to record their screen for a few hours during their work day and share the video with us. Or alternatively, share their RescueTime results with us. This helped us to quantitatively see what people spend their most time on and how many context switches really happen throughout the day.

Synthesizing all learnings into actionable insights as a basis for our product hypotheses

What do we do with all those learnings now? The next step in our process was to gather all key insights onto a digital whiteboard (High five to Miro! Did you know you could copy a long list of phrases and paste them on Miro where they will automatically appear as Post-it notes? We like!).

We structured and grouped key insights from all conversations and research methods under common themes. We discovered several patterns as well as similar language used by the people we spoke to — which would later help us to phrase our value proposition.

Most importantly, we found answers to the four questions we sought to get clarity on:

1. The problem is ubiquitous. Every single person we talked to understood the problem right away, they immediately related to it and told us stories of when they experienced this issue strongly.
2. People who experience many context switches at work seem to suffer most from the problem: Product Managers, entrepreneurs. Many of them work in early to mid-stage digital tech startups.
3. The following insights are the basis for our product hypotheses:

• Everyone has their own preferred way of working, following their own processes and using their favourite tools → Therefore, our product needs to be customisable to fit into any workflow.
• People use a lot of different tools on a regular basis, but within a tool, they usually only use a handful of key features and look at a few information points → This is why we follow a 80/20 logic in our product, focussing on the most important features and actionable information points.
• Around 60% of context switches are short interactions (e.g. answering a message, accepting a calendar invite, looking something up in a note, writing down a to do, etc.) → On our product, we will enable direct actions for all those quick interactions.

4. Most people have already tried out several tools and hacks for productivity and focus (more or less successfully). People turn off or snooze notifications, create calendar blockers for focus time or try to answer emails only twice a day. → Therefore, a dedicated focus mode will be important for our product.

What’s next? Quickly moving on to focus on the solution

It was quickly clear that the problem we are tackling is real. Some people even told us the problem might be too big, maybe even unsolvable. We don’t think so — or at least, this won’t keep us from trying. So once we had validated the problem space, we quickly wanted to move on and focus on the solution.

A lot of startups don’t fail because of demand, but rather because the solution they came up with is not good enough to get people to switch. A much bigger challenge for us now is to create a solution that will truly add value to users. This is why we are currently fully focused on building, testing and iterating our prototype in a continuous loop.

If you care about this topic and have thoughts to share or questions for us, please don’t hesitate to reach out at team@usebeams.com.

And of course don’t forget to sign up to our waitlist here.