Topic: Product-market fit

This is a recap of our discussion with Nikhyl Singhal, VP of Product at Facebook, former CPO at Credit Karma, and former Director of Product Management at Google. 

Watch the full talk at pear.vc/events and RSVP for the next!

Product management can be an elusive topic, especially as its definition changes as the company grows. Early on, product management is focused on helping the company get to product market fit. Once the company achieves it, product management can change dramatically depending on the type of product or service, the organizational structure, and the company’s priorities. We brought Nikhyl Singhal to demystify the product management process and share insights on when, how and why to add product management into your company.

Jump to a section:

In the “Drunken Walk” Phase, Product Managers Should Really Be Project Managers

For Founders Working on Product Market Fit, Maintain Healthy Naivete

If You’re Not a Product Person, Find a Co-Founder Who Can Own Product Market Fit

Introduce Product Management When Founders Shift Priorities

Look for Product Managers Who Can Scale with the Organization

---

In the “Drunken Walk” Phase, Product Managers Should Really Be Project Managers

While employees at early stage companies may have Product Manager as their title, they should really be owning project management and execution.

Product management, or the goal of helping that company get to product market fit, should be owned by the founders. 

It’s partially an incentive problem. Founders, as Singhal notes, are usually the executives with a larger share of ownership.

“They’re the ones that the investors have really placed money in and the extended team in some ways just aren’t at the same level in scale as the founders,” Singhal says.

However, execution and distribution are team responsibilities–and Singhal considers them much more of a utility than a strategic function. Understanding the allocation of responsibilities in founders versus product managers in early stage companies can be crucial to success.

“I actually embrace this and I [would] suggest, “Look, there’s no shame in saying that we need to bring in product managers to really own a lot of the execution.”

For Founders Working on Product Market Fit, Maintain Healthy Naivete

For early stage founders, Singhal says not to discount naivete. He recounts from his own experience that while others had insider perspectives or felt jaded, his own beliefs helped propel him through company building, ultimately helping him found three companies in online commerce, SAAS, and voice services. 

“I think that the lesson, if I were to pick one, is that healthy naivete is a critical element to finding product fit and actually fortitude around some of those ideas that are, ‘Hey, the world should work this way,’” Singhal reflects. “‘I don’t quite understand the industry, but I want to focus on that user, that business problem, and go forward on it.’”

If You’re Not a Product Person, Find a Co-Founder Who Can Own Product Market Fit

“The speed to be able to go through product fit is so essential for being able to efficiently get to the destination in the final course of action for the company,” Singhal says.

Thus, while it’s possible for founders to take other roles early on, purely outsourcing product fit to the rest of the team is still not a wise decision.

“If you’re not the person who’s owning product fit and you agree that product fit is sort of job number one, what I would say is—find a co-founder who can be essentially the owner of product fit. The reason why I use the term co-founder is for the economics to work.”

Introduce Product Management When Founders Shift Priorities

One issue founders often face with product management is determining when to introduce it. Introducing it too early may lead to conflicts internally, while introducing it too late means the company may have missed out on the prime time for strengthening execution. 

Again, product management is dependent on the founders’ backgrounds. For founders who have backgrounds in product, as long as there is clarity and predictability around what will happen, the company may proceed without product managers. The most common case for introducing product management, however, is when founder priorities need to shift from product fit to scaling the organization.

“This could be establishing new functions,” Singhal notes, “Or fundraising or thinking through acquisition. Marketing is also an important area, or thinking through company culture if the company starts to scale. At this point, if you fail to bring in product management, you’ll see dramatic reductions in efficiency.”

Look for Product Managers Who Can Scale with the Organization

For early product manager hires, companies should consider both the growth curve of the company and the growth point of the individual. Especially for companies that may be in hypergrowth, it’s important to have a mindset that “what’s gotten us here isn’t what gets us there.” This means the product management team must be adaptable. 

Being aware of how product management interacts with other functions is also crucial. 

“Product tends to essentially sit between the power functions of the organization as it deals with scale and growth,” Singhal says. It could be between marketing analytics and product engineering, or sales and product, depending on what the company’s business model is. 

Lastly, founders need to examine their own career trajectories in transitioning product power to teammates. It can be a tough emotional decision, Singhal acknowledges, but this question should be asked early on.

“I think that it’s almost a psychological question around: what is the person’s career ambition as a founder? Do they see themselves as moving into a traditional executive role? Shall I call it CEO or head of sales or head of product? If the goal of the person is to expand beyond product, then I think that the question really deserves quite a bit of weight,” Singhal says.

This is an excerpt from partner Nils Bunger’s talk for Pear Accelerator S20.

Pear Accelerator is a small-batch program, where our partners and mentors work hands-on with exceptional founders through the journey to product-market fit. Learn more: pear.vc/pearx

The tricky thing about finding product-market fit is that it’s easy to be misled (and to convince yourself) by false signals. As Ajay mentions in his talk, the worst case scenario is when customers are lukewarm about your product. They will seem excited about it and talk about the features they want, but when push comes to shove, they won’t buy the product, no matter how many features you add at their request.

The hard truth is: that’s because they don’t actually need or love it. If this is happening to you, you haven’t found product-market fit.

Again, from Ajay’s talk, if your users love your product, they’ll tell you.

So how can you get to that point of love? How can you set yourself up for success and avoid getting caught in the feature spiral of death — where you’re building and shipping but no one is buying?

Customer development. Or, verifying your insight before building your MVP. This talk is about how you do that, step by step.

Jump to a section:

The Mindset

How to Form A True Problem Hypothesis

How to Win Your First Validation Meetings

How to Extract Real Insight From Your Meetings

Tying It All Together

OMG It’s Starting to Work!

---

The Mindset

“Fall in love with the problem, not the solution.”

— Uri Levine, co-founder of Waze

You first have to understand that customer development is not sales. You’re not selling your product yet. You’re not trying to convince potential customers that you have the correct solution.

Customer development is anthropology. You’re studying your customers. You’re trying to answer the question — do these people actually have a problem? How do they describe it? What would it take to solve it? You’re trying to probe and get real data to confirm whether your insight about a solution is correct.

And to do that, you need to deeply understand the problem your customers have.

Prepare to spend a lot of time here, going in a circle from hypothesis to validation back to hypothesis over and over again. It might feel frustrating, but it’s far better to be stuck in this loop, learning about your problem, rather than being stuck in the product feature loop where you’re wasting time, money, and energy building things that don’t work. You want to stay in the customer development loop until you achieve repeatable sales or clear cut metrics that say that you’re onto something.

Form A True Problem Hypothesis

A problem hypothesis has these basic parts:

• Problem: A concise, specific statement of the problem you solve
• Audience: Focused set of people who you think desperately have this problem
• Reasoning: What makes this problem something that people in the audience need solved?

The problem is “the what.” The two key points for a well-articulated problem statement is that it is (1) specific to something that is solvable and (2) in your customer’s language. If you don’t have either of these, you don’t actually know what the problem is.

For the audience, the most important thing is to be narrow and tight — who has the problem most acutely? Keep narrowing down your ideas until you have defined a concentrated pool of users with the most acute need.

For any amateur chefs out there, you can think of this like a reduction sauce — start with a big pot of some kind of juice and stir over the stove for many hours, slowly evaporating all the water and slowly concentrating the flavor of that juice. What’s left behind is the deep essence of the ingredients.

You want to be finding your group of customers with the deepest, most desperate need for a solution.

Finally, you need to double check yourself and make sure you have sound reasoning for your hypothesis. Do you know why your audience wants or needs that problem solved? Again, specificity is the key here.

If you don’t have a good idea of why people might need a problem solved (perhaps your reasoning is a bit circular — “this customer has this pain and they want it solved, because it’s painful”), it might not really be a problem in the first place. There are plenty of problems people have that they’re okay with tolerating, because solving them is more effort than it’s worth. Or, you’ve just made up a problem that doesn’t exist.

You’re looking for an urgent problem, or if you’re on the consumer side, you’re looking for people who are just itching for something new.

Win Your First Validation Meetings

Once you’ve got a solid hypothesis, you have to validate it. That means you need to collect data from unbiased people who don’t know you, which means you will need to lean into cold outreach.

While customer development isn’t sales, during this phase, you will need to put on your shameless salesperson hat a bit to get the meetings you need.

There’s no single answer to how you should reach out. This is actually a core part of your learning during this whole process. You will need to know the unique answer for your company: how do you reach the right people and what are you saying that activates them?

Your approach should have three key things:

• A high response rate
• Consists of your target audience
• Generates a steady volume of meetings

Then, it’s really a numbers game. Aim for 10 first meetings per week, and then aim to keep increasing that number with iteration. Iterate your message. Iterate your audience. Keep reaching out.

You’re learning about your customers here and you’re also learning about your message, where your customers hang out, and what they respond to. These insights are just as valuable as the meetings themselves.

Extract Real Insight From Your Meetings

Alright! You finally get to talk to customers! But what do you say? How do you get good data from them? Nils offers this simple section structure:

• First 10 minutes: Broad questions to learn the unexpected.
• Middle 10 minutes: Specific questions. Learn about your problem statement.
• Last 10 minutes: Reconcile and zoom out. Did what you hear in parts 1 and 2 match up? Why or why not?

Broad Questions Phase

During the broad questions phase, your goal is to learn context about the user and the general area of your company. Find out about the incentives and biggest problems on their mind before being influenced by your ideas.

Some example questions:

• What do you do here?
• Who else do you work with most closely?
• How do you spend most of your time?
• What’s the most important thing for you to accomplish?
• What’s the biggest challenge you have in your job now?
• What are the top 3 problems you face?
• Have you bought products to help some of these problems?

Do not tell them about your product idea, or what problem you’re after in this phase. Just try to understand how your prospect thinks about their day and what they need to accomplish.

During this phase, because your questions are broad, you’ll likely get some broad answers in response that won’t be very actionable for you. Make sure to spend some time drilling down into these answers. Pick one of the problems they talk about that seem relevant to you and ask for more details, peel back the onion a bit.

Specific Questions Phase

Your goal in this phase is to gain data points specifically about your problem hypothesis. Does this person have the problem you came up with? How badly do they have that problem?

Some example questions, and what you’re really after in asking them:

• Have you ever had <your problem hypothesis>? Tell me about that.
• How do you deal with it now?
  → Why You’re Asking: If this is a real problem, they’re probably doing something to deal with it already. And if they’re not, it’ll be useful for you to find out why.
• How painful is this problem for you? How often do you have it?
  → Why You’re Asking: If this doesn’t come up that often, then it’ll probably not be a priority for them to buy or find a product about it.
• Have you ever looked for a solution to this problem? Have you bought anything?
  → Why You’re Asking: If they have this supposed problem but then haven’t thought about it enough to try doing a simple Google search for solutions, maybe they just don’t care about it all that much.
• Would <direct competitor> solve your problem? Why haven’t you bought it?
  → Why You’re Asking: Don’t be scared of this one. Remember, you’re not trying to sell a product, and in any case, you will have to assume in the future that your customer is going to know about your competitors—so you might as well ask them about it for your own competitive intelligence.
• If you could solve this problem, what would change?
  → Why You’re Asking: Why does solving this problem really matter to this customer? Why does it make their life 10x better to not have to deal with it? This is what your product is going to need to solve for.
• How valuable is that change?
  → Why You’re Asking: Value is much better than talking about pricing. You’re now trying to get as close as you can to a quantified version of the answer to the previous question. Does it cost them a lot of time? Money? Does it allow them to save on not hiring extra people?

Reconcile and Zoom Out

Now you want to reconcile what the customer has said in both the broad and specific phases to double check that your data is valid. If your customer answered your specific questions in a way that makes it seem like you’re onto something, but didn’t bring the problem up on their own in the broad phase, you’ll really want to dig in and understand why. Maybe the pain isn’t as intense as you (or they) think it is, or maybe they think of the problem you came up with more as a piece towards solving those larger problems.

Finally, you’ll want to zoom out and understand how your customer buys products or solutions to their problems. Ask:

• What would be the next step if you had a product that solves this problem today?
• Do you actually buy these kinds of products?
• If you tried such a product, what would you want to see to keep using it?

You want to try to make this part as concrete as possible for the customer, almost as if it really does exist. Walk through their new customer journey with this product in their life. You’re looking for that “WOW” moment, as described in Bob Tinker’s talk.

Tying It All Together

Do at least 5 user interviews with the same type of audience you outlined. If you’re not finding an acute, concentrated pain, go back to your problem hypothesis and revise either your audience, or your problem, and run through it all again.

If you are starting to find an acute pain, do 5 more user interviews and drill down to the next level of questions. Show some product mockups and see if the pattern you’ve been seeing holds up.

Ask about discrepancies between your interviews. For example, if the previous four of the five previous customers said something was extremely important, but your next five don’t mention it, just ask them about it — “These other three guys had this big issue around XYZ and that didn’t seem to come up here. Is there a reason? I’m curious about the differences between what you do and what they do.”

OMG, it’s starting to work!

The strangest thing happens when this process starts working: you’ll find yourself trying to have a customer development “anthropology” conversation, and your customer is trying to turn it into a sales conversation.

People start leading you, instead of you leading them. They want to buy this thing now, they want to know how they can try it out, they want to bring their colleagues to a meeting. It’s the WOW moment. If you can get it repeatedly with 3–5 customers, then it may be time to develop your MVP!

Two options for this phase:

1. Create a “no-code” solution with phone / email / spreadsheets / whatever, and try selling the solution to a few.
2. Try turning 3 of your most promising interviews into “design partners” to help co-create a solution. Try to get some written agreement in place.

In any case, we always recommend building the tiniest MVP you can, enough to go through a “build/measure/learn” loop, per Eric Ries.

We wish you luck and hope that all of you get to this magic moment! It’s our favorite part of the journey.

This is an excerpt from Ash Rust’s talk for Pear Accelerator S20.

Pear Accelerator is a small-batch program, where our partners and mentors work hands-on with exceptional founders through the journey to product-market fit. Learn more: pear.vc/pearx

---

First things first: the most important thing over and above everything else that you can do to get to product love is to launch and get live. Live, as in: people outside of your team can use this product end to end, and at least one person has done so.

Once you’ve gotten live though, you need to “Test, learn, observe and iterate,” as discussed in our Product Market Fit lesson. After all, you’re aiming to make something that customers want to rely on and use fanatically. The only way you can get there is to learn from customer engagement. To learn most efficiently, you need to set effective goals for yourself.

Here’s a systematic process for doing so, from long time startup mentor, Ash Rust.

Jump to section:

Determine your North Star metric and supporting metrics

Set numeric, specific, and achievable goals

Assign owners to each goal

Start goal setting as early as possible

---

Determine your North Star metric and supporting metrics (no more than 3!)

First, you’ll want to determine your North Star metric. This is the metric your team will rally around.

Some examples: if you’re a SaaS business, your metric is usually some form of revenue. If you’re a marketplace, you might think about transaction volume. If you’re a pure consumer business aiming to monetize with ads, then you will likely consider something like daily active users.

While it’s very important to pick the right metric, you’ll also have to accept that it won’t be perfect. Since one metric won’t tell the whole story, you’re allowed to go one step further — but don’t go much further than that. Three supporting metrics is more than enough, and you don’t need an expensive analytics suite to calculate them.

Ash recommends breaking your business down into three sections, with a corresponding chosen metric for each: distribution, engagement, and churn.

Set numeric, specific, and achievable goals

To get your metrics moving in the right direction, you’ll need to break them further down into their own components, and set goals around these components. Meeting these component goals should ultimately tier up to moving your metric toward the North Star goal.

To get started increasing revenue, for example, you’ll probably need to start generating some leads. To start generating some leads, you’ll need to start interviewing customers to get a sense of what they want, so you’ll need to start scheduling some initial meetings. Set your first goals around these tasks.

It’s key that all your goals are numeric, specific, and achievable.

For example, rather than having a goal such as “interview customers,” you’ll want to go a little bit further and say, “How many customers do we want to interview?” Is it 5? Is it 10–15?

Achievability is also important — if your goals are too outlandish, your team won’t take them seriously. Don’t set a goal for a $100 million contract to be signed this week. Set a goal that is much more reasonable that you can track against, perhaps something like “schedule first meeting with big wishlist client.”

However, don’t go too easy either. You still want to make sure the goal is impactful for your North Star metrics. For example, “schedule 5 meetings” is more of an impactful goal than “send 20 cold emails”, as it gets you closer to increasing that North Star metric of revenue.

Assign owners to each goal

Once you’ve set your numeric, specific, and achievable goals, it’s time to build your roadmap to achieving them. Assign owners to each goal and provide resources for them to complete it within a reasonable deadline.

At the early stage, the timeline shouldn’t be too far out, since things are changing so rapidly. Quarterly goals will not make sense. Ash recommends starting out with 3–5 goals every two weeks, but you’ll definitely need to adjust depending on your business. If you are a consumer web tool, for example, you might find you’ll need to set weekly goals, because you need lots of feedback to iterate as fast as you can. On the other hand, an enterprise company may need to use monthly goals, due to fewer customers and long sales cycles.

Every goal absolutely needs an owner. You cannot have more than one owner for a goal, because it diffuses accountability. You can’t afford to waste time playing blame games instead of understanding immediately why that goal was missed. Remember—rapid learning is this stage is everything. If you’re having disagreements about who should be the owner of a goal, then alternate between different weeks (or whatever your timeline is).

The owner of the goal should be the one responsible for coming up with a plan to achieve that goal, complete with an estimate of resources that they’ll need. The manager will be responsible for providing those resources.

All of this creates clear accountability for all parties, which is crucial to iterating efficiently.

Start goal setting as early as possible

Final point: you want to start these processes as early as possible, even if your team consists of just you and your cofounder. If you don’t hold yourself accountable, you allow it to become the cultural norm for your future team. It gives your future team members the idea that certain people or groups are subject to exceptions from the achieving goals.

Once you’re growing, the easiest way to instill a goal-setting mindset is to allow your team to set their own goals. As long as they are specific, numeric, and achievable,you shouldn’t have a problem. Even if their first goals are extremely easy or not quite impactful, that’s okay. You can help them iterate and refine their goals as time progresses. The key is to get everyone into the habit of doing it.

This goes for yourself too! While we give much advice here, the key thing in the end is to get going. In the same vein as your product, the most important thing to do is get live. Be thoughtful about your goals, but don’t get paralyzed. Take your best shot at setting some goals, and iterate from there.

This is an excerpt from partner Ajay Kamat’s talk for Pear Accelerator S20.

Pear Accelerator is a small-batch program, where our partners and mentors work hands-on with exceptional founders through the journey to product-market fit. Learn more: pear.vc/pearx

---

One of the challenges with product market fit is that it’s challenging to define. If you look online and read blog posts, there are dozens of different ways to describe product market fit, and each of these descriptions applies to wildly different stages of companies. Even ‘early-stage’ has a wide range of definitions.

So, let’s be clear about what stage we’re focusing on as we publish our method for finding product-market fit.

The advice here is for companies generally in the same phase as our Accelerator companies (where we give this talk) — typically ground zero, with 0.5 as your “end of summer” goal.

Jump to section:

A Few Words on the Superhuman Method

The Pear PMF Method For Ground Zero Companies

(1) Understand your insight

(2) Verify your insight

(3) Build your MVP

(4) Test, observe and iterate

---

A Few Words on the Superhuman Method

The seminal piece of startup advice for product-market fit is Rahul Vora’s engine to find product/market fit for Superhuman.

However, many of our Accelerator founders aren’t fortunate to have the same conditions as Rahul:

…in practice, because of my previous success as a founder, we didn’t have problems raising money. We could have gotten press, but we were actively avoiding it. And user growth wasn’t happening because we were deliberately choosing not to onboard more users. We were pre-launch — and we didn’t have any indicators to clearly illustrate our situation.

Moreover, while the 40% metric is a famous benchmark, what happens if your denominator is 0? What if you don’t have any product yet to ask users ‘How would you feel if you could no longer use ___?’ Rahul suggests that you only need 40 users to get directionally correct data from the exercise, but maybe you’re not even at 40 “real” users yet.

With Superhuman, Rahul knew that they were building an email product already. In many cases, at the Accelerator stage, our founders might not necessarily know what their product is going to be. They’re really a step before that, so there isn’t anything to ask about. They’re trying to find out what the ‘email product’ to build even is.

If this sounds like you, there really is one goal, and one goal only: find a product that a few customers need and love, and ultimately will pay for, and evidence that there are many more similar customers.

You don’t need to figure out if it’s possible to scale it yet. Focus on product love.

What you might see here is that this is essentially the same question that Rahul is after in the Superhuman story — he’s segmenting and drilling down his user base to find that specific group of people who really need and love Superhuman and would be disappointed if they could no longer use it.

The difference is, as a “stage 0” founder, you’re starting from scratch to find your very first version of a product that might attract enough users to begin measuring.

Our own four-step methodical process to getting to that first initial product is normally reserved for our exclusive batch of Accelerator companies.

The Pear PMF Method For Ground Zero Companies

1. Understand your insight
2. Verify your insight
3. Build your MVP
4. Test, learn, observe and iterate

Let’s walk through it.

(1) Understand your insight

Your insight is unique to you. It comes from your particular view of the world. It’s the reason you feel like your idea is possible.

Sometimes we see a founder who seems born to build the specific company that they’re pitching. We call it founder market fit, and it’s the best-case scenario.

Insight comes from four places:

• Experience — you’ve done it, you have worked on this problem before.
• Market knowledge — you’ve studied this problem deeply; you’ve analyzed all the competitors in the space and feel that there’s an opportunity to approach the problem differently.
• Observation — you’ve seen this problem over and over.
• Gut feel — you feel it.

Ideally, your insight comes from some combination of all of these. It’s critical that you feel your insight is unique, that what you bring to the table gives your company an opportunity that the other companies tackling the same problem won’t have.

(2) Verify your insight

Talk to customers, talk to customers, talk to customers. The best founders we see talk to hundreds and hundreds of customers before writing a single line of code. They listen attentively to the already existing problems that these customers have.

Of course, you should go in with your hypothesis of where you can help (your insight), but you’ll want to truly verify that it’s a real problem from actual customers.

There’s a method for doing this the right way too, called customer development. But suffice to say, there is no skipping this step. If you get too excited by your idea and insight and jump to the building, you might invest a lot of time and money to build and sell a product that customers don’t want.

(3) Build your MVP

The tenets of building a true MVP:

• Dead simple product
• Avoid feature creep
• Iterate. Fast.

We know that disruptive founders think big, and we love that. But when you’re just getting started, you need to think minimal. We’ve seen founders build the first version of a product with all the things they dreamed a product should have, but we think that’s the wrong approach.

We advocate for building the product with the minimum number of features you need to test your observed insight. Then, iterate on the product.

When Ajay launched his product, Wedding Party, for example, it didn’t even have an onboarding flow. Visitors would go to a landing page and type in their email address. In the earliest days, the team would email them back. If the user wanted to sign up, the team would call the user, set up their account on the back-end, and give them a login.

“We weren’t trying to prove whether or not they would go through the signup flow. We were trying to prove that once customers got into the product, they would use it. In defining it very clearly, we realized what we had to build and what we didn’t need to build.”

Keep the features very, very tight, and the hypothesis that you’re testing very clear. Set your company up to iterate quickly.

Of course, everyone knows this, everyone’s read about minimum viable products, but we’re reminding you again because it’s insanely difficult to internalize. We’ve seen many founders go through a “failure to launch,” where there’s always something going on before they can get in the hands of customers, some reason to procrastinate because their product won’t really be proving their hypothesis.

We encourage founders to get a product that’s ugly into the hands of a few customers (the ones you’ve talked to in the previous step) and then update it very, very quickly as you learn.

We do get it — it’s tricky to find the right line between minimum viable product and bad product that won’t tell you anything. But at some point, you need to put stakes in the ground. Better to bias toward launching than to wait.

(4) Test, observe and iterate

The number one question all your metrics should be answering: Are people using the product?

Treat these metrics as your product. You don’t need to be optimizing a customer-facing front end yet. You need to be optimizing the metrics that prove your core insight or value proposition. In fact, we might argue that it’s better to have fewer customer-facing features and more developed back-end infrastructure, so you can really understand what’s going on when your customers are using the product. If you don’t have the metrics, then you don’t know what’s happening with the users, simple as that. You’re flying blind.

Because this is the critical question that your company depends on, it pays to be extremely skeptical of it and not give yourself fake gold stars.

When you see something interesting going on in the data, the first question you should be asking is why is it happening? If you see a spike in invitations, is it really because your users love it and invite their friends in a viral loop, or is there spam or a bug going on?

Along the lines of giving yourself too many fake gold stars, avoid vanity metrics, such as the number of signups. These are fun to look at, but they don’t actually tell us anything about the underlying health of the product’s usage.

The key point is to be honest with yourself and take a hard look at what’s going on in terms of the usage of your product.

If people love it, they will absolutely tell you.

The worst-case scenario is really when users are lukewarm about your product. They might say, “Yeah, it’s cool. It’s nice.” It’s very tempting to take this as proof of love, but this is not what you want. Again, if your users love it, they’ll tell you.

Think about the products you’ve bought in your life that you loved, and how you reacted. You tell other people about it — because how can they be living life without this product? That’s what you need to be looking for in your usage. Nothing less.