Thinking Out Loud

How to solve the only problem you have

How to solve the only problem you have

Here are some fake problems you think you have :

  • What shall we call this?
  • What color is the logo?
  • Should we include (insert desirable feature here)
  • Which blog platform is best?
  • Facebook or Google advertising?
  • Is C++ better than PHP?
  • Should we get an office?

Here is the only real problem you have :

  • Does this idea solve a problem for people who are willing and able to give me money?

How to solve the only problem you have :

Take stock of what you have in front of you. I assume that you have an idea – one that you generated out of your own genius, or something that your cousin told you at a party, or some variation on an idea that someone else turned into a business.

Try to write it out in one or two sentences.
Here’s an example…

“I’m going to sell an Android App to predict future weight loss, based on a person’s past failed diets.”

Will this idea solve a problem?

Yes, you say, of course it does. But, think about it – how do you actually know that it solves a problem? Maybe people don’t want to think about past failures. Maybe they don’t want to record numbers every day. Maybe they don’t want to know their future. You need to find out.

Will people pay to solve this problem?

Let’s assume that you’ve asked a bunch of people if they would like to be able to predict their future weight loss. A few say this sounds great. But maybe, when time comes to actually purchase your app, they decide that they really want to spend money on chocolate rather than some shiny new software to tell them they’re going to fail again anyway.

You need to come up with a way to ask them to actually pay for your solution – you will never know if you have an executable idea without doing this.
If people hand over money, you know you have a market for your product.

Is it possible to make this work?

Don’t ever ask software people if something is possible. Of course it’s possible. Every coder knows that they can make anything happen – given enough time and money (and enough bubblegum and string). Some of them probably can make magic happen.
So they will invariably say something like “Sure, this is awesome, and I reckon we could build this in a few months, and for too not much money. Half up front, and half on launch.”

Do not do this :

At this point, a lot of first-time entrepreneurs say “Woohoo, some people I know agree that this is a cool idea, and a developer said he could build something like this for $40K. I should go ahead and just do this thing!” Commit to the dream.


Do this instead :

Figure out the things that are special about your idea. Do this by listing all the awesome features, and then one by one, take features off the list, and stop at the point where, if you remove one more feature, the whole idea evaporates in a puff of smoke. What you are left with is your core feature set.

Don’t design pages or screens at this stage. No colours, no branding, no perfect layouts. Sketch up every single one of those core features in terms of an interaction between your application and the user… e.g. (a) record my weight, (b) create a list of common meals, (c) record what I ate today, (d) note the result, (e) join a support group, (f) delete last years results, (g) scrub and start again.

Each of these “touch points” (computer/human interactions/interfaces) needs to address :

  • How do you get to this interaction (e.g. from a floating always-on menu, or in response to a particular set of circumstances)
  • What is the user input (e.g. a whole number of kilos, no decimals)
  • How the app responds, what to expect (e.g. displays projected loss based on a mathematical formula.. pokes out it’s tongue.. calls an ambulance…)

Along the way, make sure to ditch anything that really isn’t needed to define/test the concept. For example, you really don’t need to have a secure login system. For now, you can just take it as read that when you launch, that would be desirable. For a first pass, choose something simple like entering a unique username. You do not need to add an avatar, nor link up with Facebook or Tumblr – irrelevant, strike it from the list.

Then do this :

You have your “core features”. Now you need to answer the next piece of the puzzle… can this be built?

Don’t ask a software engineer if it’s possible (see note above). Sidle up to a coder. Offer them a small but reasonable amount of money, or a piece of the action. Ask them to build a proof-of-concept model, based on your “touch points” flash cards. Nothing fancy, no colours or polished wording, just the basics.

The only brief should be “build something really simple, using any coding language you like, and any database, that demonstrates positively that all of these features (“touch points”) can be implemented on (platform like desktop, tablet, iPhone). It can be ugly as sin, but if something doesn’t work, then they have failed to build anything useful for you.

In most cases, you can get a rough working prototype in a few days, because you have a short list of well-defined expectations. No guesswork required, no need to pick just the right shade of lavender for the backgrounds. If you outsource through one of the freelance services, it’s not going to be expensive. But feel free to ask your geeky cousin who’s still in high school, as long as he knows how to write functional code. You’re not going to use this for your launch product. Don’t sweat the details.

Then do this :

If your geeky cousin or cheap contractor was not able to make something that jumped through your short list of essential hoops, then you have scored a victory. What, you ask, but isn’t that a failure?

It is a definite WIN if you can scrap an idea early, which can’t be executed. Take the afternoon off, open your notebook, cross that idea of your list, turn the page to the next awesome idea, and start over. The name of the game is to reduce your risk and generate revenue – it is not the process of forging on regardless with an unworkable or impractical idea.

You have now addressed the question ofCAN this idea solve a problem for people who are willing and able to give me money?”

Then do this :

If you get this far (a well-defined group of people think it’s a good idea and addresses a pain point. You have reduced the concept to a few core ideas, and you have tangible proof that it can be implemented at least on a rudimentary basis), then the next thing to do is discover if there is a real product/market fit.

The thing you are trying to discover at this point is :
“CAN this idea solve a problem for people who are willing and able to give me money?”

You have a rough functioning prototype. You have covered all the pain points of your defined audience.

Ask people to pay (yes, pay for the shitty prototype rough system you have). To fork over their chocolate budget.

You will probably have to come up with some sort of equally rough and unpolished sales pitch and marketing message. You may choose to buy AdWords, or retain a sales person to generate some leads.

If you can do that, then you have created your MVP (Minimum Viable Product). Take note of the fact that the working software you have to play with at this point, the really simple Android App (or HTML web app approximation that kinda works on a phone) is going to be NOTHING LIKE the final product.

And, really take note of the fact that the MVP is not just the software – your MVP is the problem, the software solution, the story, and a price point that generates real sales – in equal parts! Actually, all you need to demonstrate is a willingness to pay. If people click on the “pay now” option, then you can always have a response like “Thanks for your enthusiasm, we will contact you when the launch happens, and here’s a discount coupon.”

You may think that if you had a final, complete, polished version that it would sell a zillion copies in 24 hours, but the truth is that if you can’t sell the rough prototype, then it’s going to be an uphill battle to sell a polished final.
But, if you can sell this rough prototype, then selling a polished final version at launch will go 100 times easier!

If you have validated your MVP, then you have solved your only real problem.

The rest is downhill coasting. Well, not exactly downhill, but now you’re armed with confidence that you have something revenue-positive, with a definite market, and that the idea is executable.

You can go back to figure out the naming, branding, logo colours, blog platform, etc etc etc . You probably should do a second cycle of prototyping before committing to your final beta-release version. Some AB testing, some UI / UX, some hardware costings, etc etc etc

The goal is to deliver your MVP to the marketplace ASAP.

“Here’s something we built for you. Would you like to buy it?”


Add comment