The First Step to Developing your Big Idea

We’ve been getting a particular phone call a lot. It’s an exciting phone call. And in some ways it’s a very specific call, in that it usually goes the same way each time. “Daniel,” they’ll say, “I’ve got a great idea for an app!”

And I can’t help myself. I catch their energy through the phone. This is the stuff that inspired 3E Dev, and what motivates us to keep going everyday. But it’s a little bit so much better now, being asked to help other people bring their new ideas to life.

I dive in. “That’s awesome! What’s your idea?”

Then as they’re talking, and I’m listening, something funny starts to happen. All that energy from before? It’s still there, only now it feels a little distracted. It sounds like maybe there isn’t one idea but a lot of ideas, working together, building off of one another, tangling each other up until it’s hard to say for sure what the central idea is—what problem this app is trying to solve and how it’s trying to solve it.

Why do I care so much about this? Because I know I can help if I can just understand what it is we’re trying to do. If I can understand the problem this app is trying to solve, I can help this person develop the best way to solve it. If I can repeat that central idea back, and get solid confirmation (“Yes! You got it, Daniel! That’s it!”) I know that we can make something happen.

But until that point there’s not much we can do.

See, in order to develop a successful product, we need to be able to clearly define a problem statement, which is the specific problem this app will solve, stated in no more than about fifty words. From this problem statement we can better determine where we’re coming from, where we’re going, and how best to get there. A problem statement will help guide:

  • Development
      • What components do we need?
      • What features will be included now and which will be included later?
      • How will they be implemented?
  • Marketing
      • Who is our target audience?
      • How does this app come to life in ad and product copy?
      • What does it sound like?
      • What does it say?
  • Strategy
      • What sets this app apart from competitors?
      • How will it function and grow?
      • Does it earn money? How?

There’s so much a clearly defined problem statement can help with that its importance cannot be understated. And yet I realize that for a lot of us, distilling our ideas down into a statement like this can be difficult. So I want to take a moment to break the process down, showing exactly how I go about extracting an effective problem statement from a big idea.

I find it easier to understand a process when there’s a model to follow along with, so I’ll demonstrate everything on a problem that’s very real to us at 3E: football squares. (For those of you unfamiliar with the game, you can find a great crash course here.)

1. Brainstorm the Pain Points

The first step when developing a problem statement is to identify all of the problems associated with the task you’re looking to improve. We call these problems pain points.

Pain points are actions that slow us down, take a lot of time, introduce error into a task. Pain points can be small or large. The important thing is to identify them all, or as many as we can, because doing so will give us a more complete picture of the problem we’re trying to solve.

If you’re a business owner developing an app to help your customers or your teammates with a task, you’ll want to consider them when identifying the paint points. Maybe there are issues with ordering or shipment tracking that all of your customers talk about.

If you’re an entrepreneur developing a new app, your pain points will be those experienced by the target demographic you’re looking to pitch this app to. Players of football squares, for example.

Even in football squares (or maybe especially in football squares) there are plenty of pain points. I took a minute to brainstorm all that I could think of, really getting into anything and everything that slows me down, takes time, or introduces error, at any point in the process of playing football squares.

Don’t feel like anything is too small to include. It’s really important to identify all problem areas. In the next section we’ll start to organize these points and make more sense of them.

 

2. Bucket the Pain Points

Now that we have a list of all of our pain points, we need to make sense of them. We’ll do this by bucketing each point into one of two categories: Most Painful and Least Painful.

This is a pretty straightforward exercise. But like we established in the last step, your approach will be slightly different depending on your situation, whether you are an entrepreneur or a business owner.

If you are an entrepreneur, developing this app for customers, ask yourself:

  • Which of these pain points are most painful for my customers?
  • Which of these pain points are least painful for my customers?

If you are a business owner, developing this app for your business, ask yourself:

  • Which of these pain points are most painful for me or my teammates?
  • Which of these pain points are least painful for me or my teammates?

In this example, we’re developing an app for customers, so we’ll consider these questions in reference to them. Which of these pain points are most painful for players of football squares? Filling in the board is pretty time consuming, so that’s definitely a major pain point. Which of these points are least painful? Probably identifying the winners, that’s usually pretty obvious.

We’ll keep going back and forth like this, organizing all the major pain points in our list.

You may find yourself at a point where everything left in the list is only a minor inconvenience, a less painful point. This is totally fine. If this happens, just group all the remaining points into the Least Painful bucket.

 

3. Summarize the Buckets

So we have these buckets, but now what? How do we make the leap to actually identifying the problem?

Well, from this visual we can understand what’s really problematic, and therefore what our app should primarily focus on. This area of focus will be the problem our app is trying to solve. It will be the basis of our problem statement. We’ll form this statement by summarizing the pain points grouped together in the Most Painful bucket, and then moving into the Least Painful bucket, trying to address as many points as possible, but giving priority to the Most Painful points.

In our football squares example, we see that the Most Painful points of the game involve set up (creating the board, selecting the numbers, filling the board in) and management of the game (sharing the board with other players). We’ve identified that set up, facilitation, and management of a game of football squares—score keeping, anything associated with winnings and payment—present the most significant pain points. This is our problem statement:

The problem is managing and facilitating the football squares game, from creating the board to paying the winners.

At this point in my phone calls, there’s a breakthrough. I’ve sifted through all of the excited information I’ve been hearing, and finally found a solid answer to my initial question, “What’s your idea?” Simply put, the idea in this case is an app that helps manage and facilitate the football squares game, from creating the board to paying the winners.

See how much it grounds the idea, and opens it up to potential builds? At this point, I’m able to clearly understand the problem my partner’s looking to solve. I can already start to visualize solutions for it, and questions I need answered before we go further. Such a tight frame creates stability and allows for more exploration down the line.

The problem statement is a simple sentence, but it takes a little effort to really refine it. And at the end of it all, you have a better framing for your idea that will help guide next steps and all future development.

In the next post, we’ll talk about the ideal next step, market research, which will help you further refine your idea and sharpen your focus for the future.