Hatching a Problem into a Product.

Photo by Daniel Jericó on Unsplash.

Where do I find a problem?

You face problems. I face problems. We all face problems. Endless problems. Problems of cooking, eating, public transportation, working, getting to work, getting back from work, consuming entertainment, sleeping, sitting, standing, walking, running, visiting the doctor’s office, buying groceries, buying presents, buying furniture, assembling furniture, cleaning up.

It helps to start with a problem that is personal to you. You see things as your own first consumer and critic. Look at every facet of your life, and see what feels downright painful or frustrating. Or, better yet, put other people in the middle of your problem-spotting. Ask people around you what annoys them, or what gives them joy. Spot a way to eliminate their pain, or to add more joy. Pick problems that change people’s lives, and enough people’s lives. Look for a hefty market (i.e., there are enough people who face the problem), and a valuable one (i.e., the pain/joy is big enough that people would pay for the answer).

Define “better.”

Is my problem worth going after?

Before falling in love with the problem, convince yourself that it warrants your time and attention. Is the problem original? Does a large percentage of the population face the problem? Is your concept (your solution) original? What feels ground-breaking? What could change people’s lives? Where are the gaps? What looks like unfinished work?

Research the competition. What specific portion of the problem did they bite off, how did they set about the solution, how did they infiltrate the market, and how did they get people to pay for their concept (and, of course, how much)? Understand the slice of the market they’ve cornered, understand how they sell, how they acquire users, and how they price their products.

Even if the field is well-trodden, look for your concept to be “better” in some tangible, measurable way for the user. “Better” can mean faster, cheaper, longer lasting, portable, more versatile, more user-friendly, more compact, more automated, easier to maintain, etc. “Better” has to mean better for the user. Find something — some hook — that differentiates your concept, in the user’s eyes, from everything else out there.

Build a prototype.

What if I can’t yet build the complete thing?

Commit to building a proof-of-concept. It does not matter if your fledgling prototype is pieced together with band-aid, glue, and duct-tape. It does not matter if it’s incomplete. Do it, anyway. Rip the idea out of your head and turn it into something that is somewhat-real in your hands. It may take many failed attempts, but land with something that you can show as evidence of your concept.

A prototype is a working concept that you can put in front of real users without cringing (not too much). Your prototype needs to have a working set of your core set of features, and should embody your competitive differentiator — the secret sauce of what makes you “better.” Your prototype might leave a lot to be desired — it might be slow, it might be glitchy, it might look amateurish, it might not be billboard-worthy. That’s okay. Embellishments can wait. Your prototype serves a purpose. First, it proves you can do it, it proves your concept can work. Second, you now have something significant enough that you can observe real users using it in the wild.

Go for a pilot.

What if nobody wants it?

A pilot is the first moment of public reckoning. A pilot is scary, but good scary. This is when you let real users touch, feel, and experience your somewhat-real prototype. A pilot is not a dinner-table exercise with friends and family. A pilot is a concerted, thoughtful, multi-week, real-world experiment to gather invaluable data on the value, practicality, and the usability of your solution from the people who matter — real, unbiased, vocal users. The pilot is an indispensable opportunity to measure, iterate, evaluate, and tweak.

You get to see if users are as enamored of the idea as you are. You find out what users like and dislike. You get to watch user joy or user frustration unfold in front of your eyes. There’s nothing quite like it. You feel equal parts helpless and gratified. You find out if you solved the problem for the people you set out to solve it for. You understand what hills you still need to climb, to turn your prototype into a product. You discover what you’ve been dreading to discover, whether people will want to part with their hard-earned money for the thing you’ve built.

Decide whether to go to market.

Do I build a company?

The pilot will tell you.

You review the data from the pilot, to decide what the real product ought to be, to determine whether you need to pivot from your original idea. You evaluate the reality of your wishful thinking, but with unbiased (read, not your Mom’s) opinions in your hands for the first time. User data can reveal a lot about the multiple aspects of your concept, chiefly, where the flaws lie in your thinking and execution.

You might find the pilot data too bleak to start a company. You might find the pilot data promising enough to have a go at starting a company. You might be astonished at the pilot data, and pivot to a different problem or a different concept.

This is when you decide to go to market. Or, not.

Go to market.

Starting a company, are we?

Determine how you will sell your product, through which channels (whether you have a direct-to-consumer product, a business-to-business product, etc.), how you will scale to more customers, how you will acquire new customers, what it costs to acquire customers, how you will price your product, how you will remain in business in the long haul, and more.

Adopt a user-first approach to ground yourself in reality. Ask yourself the right questions to pierce through the happy fog of your own enthusiasm.

• Who are you impacting, when, how much, and how often?
• Is the market niche, or is it broad?
• Is the market saturated with similar products?
• Is your product a one-time-use or a repeat-use thing?
• How do you build-for-one, but scale-to-many?
• What is the cost of ownership of your product?
• What is the plan for user support for your product?
• What are the fastest ways to acquire the most users?
• How long will it take to acquire these users?
• Once you acquire users, do you need to re-acquire them?
• Are there enough users willing to pay for what you’ve built?
• How much are these users willing to pay for your idea?
• Can you bankroll your company until you acquire enough users?

Build to solve real problems, build for scale, build to last.

Summary.

At every stage — the problem stage, the prototype stage, the pilot stage, the product stage — never forget the user.

• Spot a problem. Ask your users about their problems.
• Define “better.” It must be better for the user.
• Build a prototype. Think of what you want the user to see and feel.
• Go for a pilot. Get user feedback in the wild.
• Decide whether to go to market. Let the pilot data guide you.
• Go to market. Build what users want, and want to pay for.

Build to touch as many people’s lives as possible, as deeply as possible, and as often as possible.

With a user-first approach to go to market, you cannot go wrong.

Where do I find a problem?

You face problems. I face problems. We all face problems. Endless problems. Problems of cooking, eating, public transportation, working, getting to work, getting back from work, consuming entertainment, sleeping, sitting, standing, walking, running, visiting the doctor’s office, buying groceries, buying presents, buying furniture, assembling furniture, cleaning up.

It helps to start with a problem that is personal to you. You see things as your own first consumer and critic. Look at every facet of your life, and see what feels downright painful or frustrating. Or, better yet, put other people in the middle of your problem-spotting. Ask people around you what annoys them, or what gives them joy. Spot a way to eliminate their pain, or to add more joy. Pick problems that change people’s lives, and enough people’s lives. Look for a hefty market (i.e., there are enough people who face the problem), and a valuable one (i.e., the pain/joy is big enough that people would pay for the answer).

Define “better.”

Is my problem worth going after?

Before falling in love with the problem, convince yourself that it warrants your time and attention. Is the problem original? Does a large percentage of the population face the problem? Is your concept (your solution) original? What feels ground-breaking? What could change people’s lives? Where are the gaps? What looks like unfinished work?

Research the competition. What specific portion of the problem did they bite off, how did they set about the solution, how did they infiltrate the market, and how did they get people to pay for their concept (and, of course, how much)? Understand the slice of the market they’ve cornered, understand how they sell, how they acquire users, and how they price their products.

Even if the field is well-trodden, look for your concept to be “better” in some tangible, measurable way for the user. “Better” can mean faster, cheaper, longer lasting, portable, more versatile, more user-friendly, more compact, more automated, easier to maintain, etc. “Better” has to mean better for the user. Find something — some hook — that differentiates your concept, in the user’s eyes, from everything else out there.

Build a prototype.

What if I can’t yet build the complete thing?

Commit to building a proof-of-concept. It does not matter if your fledgling prototype is pieced together with band-aid, glue, and duct-tape. It does not matter if it’s incomplete. Do it, anyway. Rip the idea out of your head and turn it into something that is somewhat-real in your hands. It may take many failed attempts, but land with something that you can show as evidence of your concept.

A prototype is a working concept that you can put in front of real users without cringing (not too much). Your prototype needs to have a working set of your core set of features, and should embody your competitive differentiator — the secret sauce of what makes you “better.” Your prototype might leave a lot to be desired — it might be slow, it might be glitchy, it might look amateurish, it might not be billboard-worthy. That’s okay. Embellishments can wait. Your prototype serves a purpose. First, it proves you can do it, it proves your concept can work. Second, you now have something significant enough that you can observe real users using it in the wild.

Go for a pilot.

What if nobody wants it?

A pilot is the first moment of public reckoning. A pilot is scary, but good scary. This is when you let real users touch, feel, and experience your somewhat-real prototype. A pilot is not a dinner-table exercise with friends and family. A pilot is a concerted, thoughtful, multi-week, real-world experiment to gather invaluable data on the value, practicality, and the usability of your solution from the people who matter — real, unbiased, vocal users. The pilot is an indispensable opportunity to measure, iterate, evaluate, and tweak.

You get to see if users are as enamored of the idea as you are. You find out what users like and dislike. You get to watch user joy or user frustration unfold in front of your eyes. There’s nothing quite like it. You feel equal parts helpless and gratified. You find out if you solved the problem for the people you set out to solve it for. You understand what hills you still need to climb, to turn your prototype into a product. You discover what you’ve been dreading to discover, whether people will want to part with their hard-earned money for the thing you’ve built.

Decide whether to go to market.

Do I build a company?

The pilot will tell you.

You review the data from the pilot, to decide what the real product ought to be, to determine whether you need to pivot from your original idea. You evaluate the reality of your wishful thinking, but with unbiased (read, not your Mom’s) opinions in your hands for the first time. User data can reveal a lot about the multiple aspects of your concept, chiefly, where the flaws lie in your thinking and execution.

You might find the pilot data too bleak to start a company. You might find the pilot data promising enough to have a go at starting a company. You might be astonished at the pilot data, and pivot to a different problem or a different concept.

This is when you decide to go to market. Or, not.

Go to market.

Starting a company, are we?

Determine how you will sell your product, through which channels (whether you have a direct-to-consumer product, a business-to-business product, etc.), how you will scale to more customers, how you will acquire new customers, what it costs to acquire customers, how you will price your product, how you will remain in business in the long haul, and more.

Adopt a user-first approach to ground yourself in reality. Ask yourself the right questions to pierce through the happy fog of your own enthusiasm.

• Who are you impacting, when, how much, and how often?
• Is the market niche, or is it broad?
• Is the market saturated with similar products?
• Is your product a one-time-use or a repeat-use thing?
• How do you build-for-one, but scale-to-many?
• What is the cost of ownership of your product?
• What is the plan for user support for your product?
• What are the fastest ways to acquire the most users?
• How long will it take to acquire these users?
• Once you acquire users, do you need to re-acquire them?
• Are there enough users willing to pay for what you’ve built?
• How much are these users willing to pay for your idea?
• Can you bankroll your company until you acquire enough users?

Build to solve real problems, build for scale, build to last.

Summary.

At every stage — the problem stage, the prototype stage, the pilot stage, the product stage — never forget the user.

• Spot a problem. Ask your users about their problems.
• Define “better.” It must be better for the user.
• Build a prototype. Think of what you want the user to see and feel.
• Go for a pilot. Get user feedback in the wild.
• Decide whether to go to market. Let the pilot data guide you.
• Go to market. Build what users want, and want to pay for.

Build to touch as many people’s lives as possible, as deeply as possible, and as often as possible.

With a user-first approach to go to market, you cannot go wrong.

Spot a problem.

Where do I find a problem?

You face problems. I face problems. We all face problems. Endless problems. Problems of cooking, eating, public transportation, working, getting to work, getting back from work, consuming entertainment, sleeping, sitting, standing, walking, running, visiting the doctor’s office, buying groceries, buying presents, buying furniture, assembling furniture, cleaning up.

It helps to start with a problem that is personal to you. You see things as your own first consumer and critic. Look at every facet of your life, and see what feels downright painful or frustrating. Or, better yet, put other people in the middle of your problem-spotting. Ask people around you what annoys them, or what gives them joy. Spot a way to eliminate their pain, or to add more joy. Pick problems that change people’s lives, and enough people’s lives. Look for a hefty market (i.e., there are enough people who face the problem), and a valuable one (i.e., the pain/joy is big enough that people would pay for the answer).

Define “better.”

Is my problem worth going after?

Before falling in love with the problem, convince yourself that it warrants your time and attention. Is the problem original? Does a large percentage of the population face the problem? Is your concept (your solution) original? What feels ground-breaking? What could change people’s lives? Where are the gaps? What looks like unfinished work?

Research the competition. What specific portion of the problem did they bite off, how did they set about the solution, how did they infiltrate the market, and how did they get people to pay for their concept (and, of course, how much)? Understand the slice of the market they’ve cornered, understand how they sell, how they acquire users, and how they price their products.

Even if the field is well-trodden, look for your concept to be “better” in some tangible, measurable way for the user. “Better” can mean faster, cheaper, longer lasting, portable, more versatile, more user-friendly, more compact, more automated, easier to maintain, etc. “Better” has to mean better for the user. Find something — some hook — that differentiates your concept, in the user’s eyes, from everything else out there.

Build a prototype.

What if I can’t yet build the complete thing?

Commit to building a proof-of-concept. It does not matter if your fledgling prototype is pieced together with band-aid, glue, and duct-tape. It does not matter if it’s incomplete. Do it, anyway. Rip the idea out of your head and turn it into something that is somewhat-real in your hands. It may take many failed attempts, but land with something that you can show as evidence of your concept.

A prototype is a working concept that you can put in front of real users without cringing (not too much). Your prototype needs to have a working set of your core set of features, and should embody your competitive differentiator — the secret sauce of what makes you “better.” Your prototype might leave a lot to be desired — it might be slow, it might be glitchy, it might look amateurish, it might not be billboard-worthy. That’s okay. Embellishments can wait. Your prototype serves a purpose. First, it proves you can do it, it proves your concept can work. Second, you now have something significant enough that you can observe real users using it in the wild.

Go for a pilot.

What if nobody wants it?

A pilot is the first moment of public reckoning. A pilot is scary, but good scary. This is when you let real users touch, feel, and experience your somewhat-real prototype. A pilot is not a dinner-table exercise with friends and family. A pilot is a concerted, thoughtful, multi-week, real-world experiment to gather invaluable data on the value, practicality, and the usability of your solution from the people who matter — real, unbiased, vocal users. The pilot is an indispensable opportunity to measure, iterate, evaluate, and tweak.

You get to see if users are as enamored of the idea as you are. You find out what users like and dislike. You get to watch user joy or user frustration unfold in front of your eyes. There’s nothing quite like it. You feel equal parts helpless and gratified. You find out if you solved the problem for the people you set out to solve it for. You understand what hills you still need to climb, to turn your prototype into a product. You discover what you’ve been dreading to discover, whether people will want to part with their hard-earned money for the thing you’ve built.

Decide whether to go to market.

Should I start a company?

The pilot will tell you.

You review the data from the pilot, to decide what the real product ought to be, to determine whether you need to pivot from your original idea. You evaluate the reality of your wishful thinking, but with unbiased (read, not your Mom’s) opinions in your hands for the first time. User data can reveal a lot about the multiple aspects of your concept, chiefly, where the flaws lie in your thinking and execution.

You might find the pilot data too bleak to start a company. You might find the pilot data promising enough to have a go at starting a company. You might be astonished at the pilot data, and pivot to a different problem or a different concept.

This is when you decide to go to market. Or, not.

Go to market.

Are we starting a company, or what?

Determine how you will sell your product, through which channels (whether you have a direct-to-consumer product, a business-to-business product, etc.), how you will scale to more customers, how you will acquire new customers, what it costs to acquire customers, how you will price your product, how you will remain in business in the long haul, and more.

Adopt a user-first approach to ground yourself in reality. Ask yourself the right questions to pierce through the happy fog of your own enthusiasm.

• Who are you impacting, when, how much, and how often?
• Is the market niche, or is it broad?
• Is the market saturated with similar products?
• Is your product a one-time-use or a repeat-use thing?
• How do you build-for-one, but scale-to-many?
• What is the cost of ownership of your product?
• What is the plan for user support for your product?
• What are the fastest ways to acquire the most users?
• How long will it take to acquire these users?
• Once you acquire users, do you need to re-acquire them?
• Are there enough users willing to pay for what you’ve built?
• How much are these users willing to pay for your idea?
• Can you bankroll your company until you acquire enough users?

Build to solve real problems, build for scale, build to last.

Summary.

At every stage — the problem stage, the prototype stage, the pilot stage, the product stage — never forget the user.

• Spot a problem. Ask your users about their problems.
• Define “better.” It must be better for the user.
• Build a prototype. Think of what you want the user to see and feel.
• Go for a pilot. Get user feedback in the wild.
• Decide whether to go to market. Let the pilot data guide you.
• Go to market. Build what users want, and want to pay for.

Build to touch as many people’s lives as possible, as deeply as possible, and as often as possible.

With a user-first approach to go to market, you cannot go wrong.