Case Study: Motion CEO Harry Qi's Path To Product-Market Fit Started With Choosing The Right Problem To Solve

Learn how Motion found the right problem to solve to make using Google Chrome better and faster.

Nov 30, 2020

Problem: Which Features To Prioritize Building?
The Motion to prioritized solving browser performance issues when one does extensive knowledge work.
Market: Knowledge Workers In Need Of A Faster Browser
One billion professionals using Google Chrome need a fast browser.
Solution: Manual User Onboarding Helps You Figure Out What To Build Next
Motion has focused on reducing tab clutter through its command-line interface. Manual onboarding has helped them understand quickly why features are not working for users.
Team: Optimizes For Speed In Decision-Making
The cofounders optimized for speed in product development, and hiring individuals who can wear multiple hats.
Takeaway: You Must Choose The Right Problem To Solve
Motion’s team discovered the right problems to solve first through manual onboarding, as they were able to closely listen to their users.

Motion’s Founder File: Why startups shouldn't worry about incumbents

Motion is Superhuman for the browser: it reduces friction and solves the biggest pain points when working in the browser. For example, Motion lets you instantly load up your calendar right from any page, help you easily clean up & organize tabs, and find & manage any Google document across all your accounts.

Qi is the Co-Founder & CEO of Motion (YC W20). After graduating from Dartmouth College in Math and Computer Science, he worked at Optiver as a quantitative trader for two years prior to starting Motion in 2019. Qi believes in taking big, calculated risks when young, which is why he decided to quit his job and found a startup at 23.

Motion cofounders (from left to right): Omid Rooholfada, Ethan Yu and Harry Qi.

Problem: Which Features To Prioritize Building?

What are the key problems you've had to solve on your journey to product-market fit?

As an early-stage, pre-PMF startup with minimal technical resources (two technical co-founders), a top challenge is prioritizing what to build. This is true during the pre-product phase and the iteration phase. There are always too many features to build and too little time. These features are often requested by users (even power users), who can sometimes be very passionate and zealous that you feel bad telling them: "We aren't building that anytime soon."

When prioritizing what to build, it is essential never to lose sight of two things: 1) who are our current target customers and 2) what specific problems we are solving for them. We'd politely decline feature requests from non-target customers or for non-target problems. For example, we often receive requests that ask us to build a detailed and robust time-tracking feature for browser activity. After interviewing these users, it became clear that we shouldn't build it: they are mostly freelancers who need to submit timesheets to get paid. They aren't our customers, and we aren't trying to solve that problem.

Only when our target customer asks us to build something about the problem we are solving, then we start diving deep into their pain points, brainstorm a solution, and engineer it out. For example, a popular feature request we used to hear from users is scheduling tabs to re-open in the future. Upon investigating, we found out that they want the feature to help clean up tabs better because otherwise, they'd leave these "reminder" tabs open for weeks. Since a major problem we are solving is reducing tab clutter, this was definitely within the realm.

Why are these problems important to solve for creating the best solution for your customer?

Without focus, a startup can build a million things, and probably none of them well. We learned this the hard way when we first started Motion: we wanted to tackle ALL the problems working in the browser. Soon, we found ourselves stretched thin across over a dozen individual features, none of them loved by any user. For example, we built a "notes" feature to help users take notes while browsing. While this seemed like a plausible feature, we'd soon find out that the use case was too broad and that our notes feature would never be as good as existing apps like Notion.

We had to narrow down the customers as well as the problems we wanted to solve for them. Churn has gone down significantly due to this focus, and surprisingly, we didn't lose many customers (probably because the features we stopped working on were the bad ones anyway).

We use Superhuman's PMF Engine (through Viable Fit) to identify and prioritize customer pain points. The framework is good at figuring out which users to care about, discovering the persona of target user segments, finding out which features are working, and prioritizing what to build next. However, a complementary set of frameworks is required to make product decisions: data analytics on user engagement.

The PMF survey (like any survey) is dependent on what the user tells you. There are two issues with this:

Users lie (most of the time unintentionally)
The feedback loop can be too slow when you don't have at least hundreds of new users each month.

Data analytics (e.g., Amplitude, Google Analytics) can solve both of these issues. For 1), Sometimes, users can over-estimate how much they are using a product (I think early-adopters tend to be overly enthusiastic about new toys). Other times, they feel bad telling you your product sucks.

For 2), most people don't answer surveys, even your most enthusiastic users. Usually, only 10-20% of surveys you send out will be answered, and to get a meaningful PMF score for the cohort, you need 40 responses. This means that you need 200-400 users in the cohort, and if you don't have that many new users coming in (you can't re-survey old users), you'd need to wait until you do to receive meaningful results. In contrast, data can immediately tell you changes in user engagement.

When prioritizing what to build, it is essential never to lose sight of two things: 1) who are our current target customers and 2) what specific problems we are solving for them.
(Click to tweet the above quote! ^)

Market: Knowledge Workers In Need Of A Faster Browser

Once you identified the critical problems to solve, what led you to realize there was a huge market opportunity to be unlocked by doing so?

I'm going to quote a recent Aaron Levie (Box CEO) tweet I saw: "The holy grail in startups is discovering a problem that everyone has a different solution for, and no one is happy with it. There are still way more of these markets than we realize." Email is a good example of this - everyone had their tricks for how to navigate through their inbox, but no one's happy with them; Superhuman and Hey are both tackling this area.

In our case, the browser is broken. One symptom of the broken browser is everyone having dozens of tabs open all the time, each of them becoming tiny squares in the tab bar. Everyone has their systems for managing tabs, but I've never heard anyone telling me, "it works well for me." At best, they'd say, "it's not the best thing, but it works." Many hate how slow and crowded their browser is. The fact that so many people have this problem convinces me there is a huge market opportunity.

When Chrome first came out more than a decade ago, knowledge workers didn't need to open so many tabs. There were fewer work apps, and the computers with 1GB of memory (compared to the standard 16GB nowadays) couldn't support that many web pages anyways. As a result, it should be expected that an optimal UX experience back then would be suboptimal now. The tab bar, what seemed like a scalable and optimal UX, is broken because you'd add an infinite number of things to it without a good mechanism to find, organize, or clean them up.

People often ask me why can't Google make Chrome better. They probably could - and they might even know how to - but they can't implement the changes. I'll dive more into this in my Founder File.

There are most likely several segments of the market you could choose to attack first. What section of the total customer base did you focus on first to establish product-market fit, and why?

We choose to target busy knowledge workers who spend more than 2 hours a day in their browser. We chose professionals over students and other user groups because we are mostly solving work-related problems in the browser. They must spend many hours in the browser because Motion is a browser extension.

We didn't perform any customer research until we launched our MVP. All we did was solving problems we had ourselves in the browser (actually, our team was solving all the issues I had). After we launched the MVP and started having users, we used the PMF Engine to determine which user groups loved us the most. (It turns out, they are all pretty similar to me - busy professionals who spend hours in the browser each day who care a lot about productivity and value time preciously). We'd target people from these groups for user interviews and find out what other problems they have when working in the browser.

"The holy grail in startups is discovering a problem that everyone has a different solution for, and no one is happy with it. There are still way more of these markets than we realize.”

Solution: Manual User Onboarding Helps You Figure Out What To Build Next

How did you build your solution to maximize its relevance with the customer and ensure product-market fit?

This goes back to the prioritization and focus topics I discussed earlier - zoom in on one specific problem we are solving for our target customers and solve it well. The hardest part of this is ignoring irrelevant customer requests and sometimes even "firing" customers. After you release a product, you'll inevitably get all kinds of users, many of them not your target customer, who try to use your product to solve problems you aren't targeting. When prioritizing features, feedback from these customers should be ignored.

This is not to say that you shouldn't pay attention to customers who try to use your product for a different purpose; in fact, maybe it's time to expand on your customer base and solve more problems. It's also possible that your product isn't a good solution for the problem you are trying to solve or customers you are currently targeting, but is great for another customer segment. An example of this is video game streamers on Justin.tv. However, it needs to be a conscious decision to pursue another set of users and problems: you are pivoting.

What are the things you did that don't scale to better shape your product development?

Recently, one of the most important things we started doing that helped our product development is manual onboarding. The product iteration cycle became so much faster because we'd immediately recognize every UX issue, bug, or problem users have. Watching a user using a product is so much better than reading data/statistics on tools like Amplitude and Mixpanel - this is not to say the latter isn't important, but they serve a different purpose. Data tells you *what* is not working; talking to users tells you *why* it is not working.

Honestly, we didn't have many tactics here - we haven't focused too much on marketing. I'm sure this is an area we need to focus on more as we grow. Nearly all of our initial users come from just a few channels: Bookface (YC's internal forum for founders), Product Hunt, and Hacker News. Everyone else came from word-of-mouth referrals.

Data tells you *what* is not working; talking to users tells you *why* it is not working.

Team: Optimizes For Speed In Decision-Making

How did you handle conflicts between you and your co-founders when making product decisions at critical junctures to arrive at product-market fit?

We followed this video by Michael Seibel on how to make product decisions.

We'd have a multi-hour-long standup every Monday morning, decide what to build that week, and release code on Saturday evening (we take Sundays off). Michael's framework makes it painfully obvious what should be prioritized.

Sometimes, we'd disagree. In these cases, I try to keep the argument as short as possible: if I think I only have a 55% chance of being right (i.e., marginally better than a coin flip), I'd give up the argument and optimize for speed, because the most important thing for a startup is speed. Only when I believe I have an 80%+ chance of being right to do I start fighting hard for my opinion; these happen maybe once in a few months - it's pretty rare for the three of us to be very confident and have opposite opinions at the same time.

What key qualities did you look for in key early hires to increase your chances of discovering product-market fit, and how did you prioritize what types of hires you needed to make first?

The most important qualities I look for are speed of execution, being highly logical, and willingness to work on any area (e.g., Customer Support), not just the role they are hired for. We are actually in the process of hiring our first employee right now: a product designer.

When a startup is at a very early stage like us, the founders should do everything: engineering, product, customer support, growth, etc. Except for engineering, the other areas are skills that you can easily pick up in a day (you are probably bad at them, but the bar to start executing is low). We can't "just" pick up another skill: design, especially UI and graphics. This is why our first hire is going to be a designer.

Our team is still small - just the two co-founders and me; they shouldn't need too much motivation to make our startup succeed. However, because they are technical, they can sometimes be detached from users; it's very motivating when users email you how much they love your product and how they've uninstalled other products already, so I forward these emails to my co-founders to share the excitement.

Professionally, I've had to scale myself to do everything non-coding. As the non-technical co-founder on the team, my job is to be responsible for everything else, including product, design, customer support, marketing, fundraising, legal, finance, recruiting, and other matters. (It's important to note here that even though I'm the one responsible for them, we make decisions together as a team; I'm just the one making sure busy work gets done and we meet deadlines). I'd teach myself necessary skills in these areas within a day (by reading lots of materials online; YC has many great resources), and then practice these skills live with Motion; I'd learn more and improve on them over time.

The most important qualities I look for are speed of execution, being highly logical, and willingness to work on any area (e.g., Customer Support), not just the role they are hired for.

Takeaway: You Must Choose The Right Problem To Solve

What are the key lessons you have learned so far from your journey to achieve product-market fit?

The biggest (and the most painful) lesson we've learned is how to choose a problem to work on. When we first started our journey, we were very attached to the startup idea we came up with; we wanted to build a commission-free betting exchange (we also thought we had a great founder-product fit because we were traders). This seemed like a plausible idea (in fact, I still think it's plausible); however, the issue is that we didn't have a problem in mind: were we trying to solve the problem of high commission, user experience, or a variety of betting topics? We weren't sure. It's dangerous to start with a solution instead of a problem because then you try to fit a problem into your solution - that's not how the world works.

What's the hardest problem you're facing now after solving the prior one(s)?

Growth is our biggest challenge right now - startups aren't startups without a need to grow fast. I'm confident we can solve this; we've never had any growth experience before, but I'm sure we can figure it out.

It's dangerous to start with a solution instead of a problem because then you try to fit a problem into your solution - that's not how the world works.

Three Cool Founders You Should Know About:

Qi: Here are three founders you should check out next!

David Gu, Founder of Perfect Recall: Perfect Recall is the note-taking app for your Zoom calls.

John Ling, Founder of Encarte: Encarte is building one-click checkout for all online stores.
Jeffrey Erickson, Founder of Viable Fit: Viable Fit helps companies discover hidden insights in your help desk, customer survey, and live chat data.

Previous F2F Case Studies:

Previous Startup Spotlights:

Latest Forbes Articles:

If you enjoyed this article, feel free to check out my other work on LinkedIn. Follow me on Twitter @fredsoda, on Medium @fredsoda, and on Instagram @fred_soda.

Founder to Founder

Discussion about this post