I meet people all the time who are building a product. Often, they’ll tell me their app or software will be ready in six months. I tell them, “You’re totally wrong here. You should launch your product today, even if you’re not ready, because you’ll learn so much faster.” You only learn when you have real users and real feedback.
You develop a very different approach when you get to use feedback at an early stage. It’s much more effective than building the product to your satisfaction upfront and only then getting feedback. If the product is “done,” you’re much more reluctant to make changes.
Uri Levine: Fall in Love With the Problem, Not the Solution
According to Uri Levine, co-founder of Waze, “If you have heavily invested in the product, you might fall in love with your solution. You shouldn’t! Falling in love with the solution means losing the practice of listening to your users, which is the only way to make progress in your journey toward product-market fit.”
Fall in Love With the Problem, Not the Solution
It is also possible that, if you have heavily invested in the product, you might fall in love with your solution. You shouldn’t! Falling in love with the solution means losing the practice of listening to your users, which is the only way to make progress in your journey toward product-market fit.
In fact, the best time to launch your product is when you’ll be embarrassed by the quality of it. Yes, the product has to be so bad that you’ll be mortified by the feedback. That’s how you’ll learn faster. You’ll do shorter cycles, even at the beginning.
“But if I launch a poor product, I’ll lose my users!” you might worry.
To which I respond: “Which users? You don’t have any yet!” So, it’s OK to disappoint those nonexistent users.
When you eventually figure out your product-market fit, after many experiments, the users will come. And if you don’t figure it out, well, it doesn’t really matter.
The role of your first users is to highlight the way for you. They will show you where to go with your product (and where not to go). If they are disappointed or screaming or churning, it’s not a problem. Their role at this point is simply to point you in the right direction.
When your product eventually becomes good enough, they will forget they were ever displeased.
Move Fast and Learn Things
The other day, I was approached by an entrepreneur trying to build a neighborhood swap site for sharing lawnmowers, power drills, and the like.
“We’ll be building the whole system using artificial intelligence,” the entrepreneur gushed.
“Stop right there,” I responded. “You’d be better off starting small and moving fast. For now, just create a WhatsApp group for exchanging items and listen to the feedback you get. You don’t need to develop a full back-end server and do all the AI yourself at this point. Only once you’ve got your feedback should you start to build the product.”
The founders actually listened to me and started a Facebook group and a WhatsApp group to exchange/swap items in their hometown. This turned out to be unsuccessful, as there was an underlying assumption that proved to be incorrect: The founders had assumed they needed critical mass — enough people in close proximity who were willing to share.
In reality, that wasn’t what was most important. Rather, people were reluctant to share their frequently used items, and there was not enough demand for the infrequently used items, or they were too expensive to share. (There was a request for a Sea-Doo watercraft, which no one was willing to swap.)
The result was that, even without building an AI system to demonstrate anything, they were able to figure out what they needed ... and much faster (in a matter of weeks and not years). The only way to make progress is by listening to your customers.
Validate the Problem, Then Build the Solution
I once heard a story about how Dell started out like most computer companies. In one of the manufacturer’s early meetings, CEO Michael Dell asked his team, “What are we going to do in this company?”
One of the guys wrote on the whiteboard, “We are going to do two things: 1) Build computers and 2) Sell computers.”
Michael got up to the whiteboard and looked at it for a while, and then simply changed the order. “We are still going to do two things,” he said. “We first sell computers and only then will we build them.”
When you have a mindset of failing fast, every idea you have is a hypothesis that you need to validate. In fact, when you think of a problem you would like to address, the first step is to validate if this problem is common and if you understand the perception of the problem from other people (your potential users or customers) rather than just your own “sample of one” perception.
So, rather than building it up front, from the get-go, simulate your software. Give it a manual back end so you can test the value proposition and the users’ feedback before investing too much capital.
Build on the Fly
When we started Mego, the app that helps eliminate standing in line at the post office to get your package, we pulled off the biggest kludge of them all: We didn’t develop a thing. Not a single line of code. No app, no back-end server, no infrastructure at all.
Instead of building an app to scan the note received from the post office and the customer’s ID, we created a WhatsApp group and promoted it on Facebook. If you needed something picked up, you would contact us on WhatsApp. Everything was done manually, which allowed us to gauge market demand early and fast. Essentially, the user would never even know that someone was reading the details and manually scheduling a pickup, rather than automated software. And let’s be frank: users don’t care.
When we started FeeX (which changed its name to Pontera in 2022), the plan was for you to upload a document, then OCR (optical character recognition) software would translate the image into text. In order to test the concept, though, we threw together a website in a hurry and we did all the OCR manually. A document would come in and someone in our office actually read it and wrote out what was in the image.
We did the same thing for Refundit — manually reading and typing in the data, long before we even considered developing the eventual OCR functionality.
Fail Fast
This approach is exactly the same with each part of your journey, whether that’s go-to-market, growth, business model, or business development. While most of the examples I’ve shared in this chapter are about product-market fit, this is still the case for any part of your journey.
When you build your go-to-market plan or your plan to bring users, I often see a one-line item, such as: “We are going to do PR,” “We are going to use Google Ads,” or “We are going to use Facebook to target our audience because we know these are 30- to 40-year-old females who have a degree in X or Y.”
In my mind, all those are very good ideas for conducting worthwhile experiments, but as soon as you figure out that they don’t work, you need to have many more ideas lined up to try. The same is the case with business development; if you think that through business development you can bring a lot of customers (or users), then you would need to try many (and many more than you think) ideas until you find the one that does work.
With Moovit, we were looking for a business development partner to promote the app, and we thought that the best partner would be the bus operators themselves. We had already seen that word-of-mouth and paid user acquisition work, but we were looking for other growth engines.
We reached an agreement with the Metropoline bus operator in Israel to put stickers on the backs of every seat on all of their vehicles. At 9 a.m., the stickers went “live,” and I called our operations manager.
“What do we see so far? Any bump in users yet?”
“So far, nothing,” he replied. “Let’s give it a couple of weeks.”
“No,” I shot back. “If we see nothing today, then there’s nothing there. If there is going to be a change, we’ll see it instantly. We don’t need to wait. If it’s not working, no matter how hard we worked or how complex it was to do, it’s time to put it to sleep.”
This seems to be very different from the product-market fit experiment, but is it? It is still about failing fast; it is about understanding that the results are most likely to be obvious, even if you’ve invested a ton of effort into it.
So, whether it’s a new version of your app or a new campaign, the most important message is to always be ready to move on to the next experiment. Running experiments means that you get a little taste of each part of your journey of failures. You get to test whether your underlying assumptions are correct. Gathering input before you commit to coding could cut a full year of development from your journey. Whether you’ve raised money or are still looking, that’s not an insubstantial advantage.
Excerpted from Fall in Love with the Problem, Not the Solution, copyright © 2023 by Uri Levine. Reprinted with permission from Matt Holt Books, an imprint of BenBella Books, Inc. All rights reserved.
