How we constantly conduct product experiments to validate our solution
Sep 30, 2021
In one of our last blog posts, we described how we validated that we are working on a big, growing and urgent problem: The fact that we experience constant distraction, context switching and lack of focus at work. This is not only a productivity issue, but more importantly, it also affects our mental health and wellbeing at work. Even though this is a hard nut to crack, we believe it is a problem worth trying to solve.
Now, how are we going to solve it? Based on the explorative user research we conducted, we did have a hunch what the solution could look like. In order to reduce the risk that we spend time and energy on an idea that won’t work, we went through a quick but deliberate process of concepting, prototyping, testing and iterating several different ideas.
While for our initial exploratory user research we spoke to a total of 75+ people, in the product experimentation phase we followed a more qualitative approach. 15 selected alpha testers, who fit our target persona, agreed to test our product and give feedback on a weekly basis. It was on purpose that we kept this number low, so that we could conduct weekly 30 minute calls with them and ensure that we truly add value. We also established a Slack community to encourage engagement with us but also between our users. Our alpha users now have access to our early product, they use it every day and can shape it together with us.
Cheap and fast experiments to learn quickly
The first solution we had in mind was a configurable work hub that organizes key information and actionables from your work tools visually in a dashboard-like interface. This should not just be a visual overview, but also enable smart and direct actions, as well as interconnectivity between the tools. The overall goal was to reduce the number of tool and context switches and increase focus at work.
We created several versions of mockups and prototypes and showed them to our test users.
These were our key learnings:
- Seeing information from several tools in one view (even though it was only relevant information) felt overwhelming to a lot of people. They didn’t know where to look at first.
- As a Web App or Browser extension it will end up being yet another tool and drown in the masses of all other tabs.
- It’s the type of solution that is only useful when all work tools are integrated and is therefor difficult to follow a lean MVP approach. When only 2 or 3 tools are integrated, people are unlikely to use it.
This is when we took a step back and reflected upon these learnings. We concluded the following consequences:
- Our product shall help people focus better. This is our key priority and everything we do should be centered around this goal.
- We are building a Menu Bar App (starting with Mac), so that it is always visible, easily accessible and stands out from all other web apps.
- We need to start with smaller hacks that already provide value and can be built relatively fast, building upon each other. This is how our Focus mode and Getting things done mode came to live.
In this next ideation phase we also took inspiration from competitors or companies working on similar challenges. We brought all of these ideas together in a big Miro board:
The close interaction with our alpha testers in the weekly calls and through our Slack community has been crucial in this process. We also used Instagram to engage in a more light-weight and fun way with our supporters.
As we keep inviting more and more alpha users to our product, we will also focus on more quantitative measures going forward. We have already set up tracking to measure and analyse our users’ daily activity on our product and we will ask them to what extent they have been able to focus better (e.g. more tasks/goals achieved, time spent in deep focus mode, overall time saved).
If you have thoughts to share or questions for us, please don’t hesitate to reach out at firstname.lastname@example.org.
And of course don’t forget to sign up to our waitlist here.