Will Your Great Idea Work?

If you’re thinking about introducing a new product or service into the world, it’s helpful to have a solid framework to structure your approach. The model I’m proposing is born out of a synthesis of the many wonderful resources I’ve read along with my own first-hand experiences as both an entrepreneur and start-up adviser. It is designed to force you to focus on truly understanding the problem before you spend your valuable time and resources designing a solution or developing a broader business case. At another time and in another space I will expand on why following these steps are so important, and how they will help you make better use of the many great resources available.

One other note: while this model is relevant to any entrepreneur, it is particularly directed at the person(s) who has been hit with a spark of genius and has the guts to put that into action. Often, you are so enamored with the solution that has serendipitously appeared, as if in a vision, that you take the problem for granted. This can have dire consequences, no matter how “lean” and “agile” you are willing to be. Contrary to how “conventional wisdom” seems to be moving nowadays, pre-planning, research and analysis can help mitigate future design flaws, as long as it’s done correctly and you’re asking the right questions. On to the model.

• What is the user pain? This is still the right place to start. Always start with the problem, but spend some time here and be sure it’s a real problem. And do a little research
• What studies/research papers/articles/3rd party analyses exist that identify this specific pain and, perhaps, provide statistics, causes or recommended solutions?
• What comes up when you Google various search terms related to the problem/pain? Are there existing solutions? Interesting blog posts? Experts? Take notes – they may be worth contacting down the line
• Try stating this pain as an assumption or hypothesis and then come up with reasons that would falsify this hypothesis. Keep these mind as you develop your prototype.
• What is the cause of the pain? A very common mistake is to jump from the problem to the solution. “Shopping for groceries is a real pain, so I’ll build a website so that people can shop online.” This solution only makes sense if the cause of the pain is that people don’t like leaving their houses to shop for groceries, or that they cannot get a diverse selection. Understanding the true cause will inform your solution. And, as with the pain, make sure to differentiate whether your stated cause is itself a hypothesis or a fact. Hypotheses need to be validated while facts can be taken as given.
• To better understand cause, map out the current customer process. No detail is too small – who do they interact with? How do they interact? Phone, email, fax, text? What time of day? Are they with anyone?...you get the point
• Identify where along the spectrum are the greatest sources of pain and why. Quantify in terms of a measure of cost (time, money). Prioritize those pain points from greatest to least (ie 80% of pain is caused by 20% of the steps). You may be proposing a solution that is only marginally impactful and, thus, less likely to be adopted
• What is the cost of the pain? Cost is a key driver of adoption. People can understand tangible cost – in terms of time of dollars – and then properly assess whether they are willing to pay for a solution. If you can’t identify a true cost (other than “it’s annoying”) then you should think long and hard about developing your solution. And pointing to the success of Facebook, Twitter and Instagram are not good enough answers.
• Try to quantify all costs in time or dollars and establish a baseline (ie an efficient process would result in $X and Y hrs to the customer, while the current process adds Z% of overage)
• Are costs recurring or one-time? Ie does the customer incur this inconvenience once and then forget about it or does it occur over and over?
• What are the direct (I pay) and indirect (someone else pays or it costs me in non-apparent ways) costs? Show me the money Lebowski
• What types of users have this pain? Now it’s time to go from general (social media users) to specific (photographers who regularly upload 2+GB of high-res photographs to various social media profiles for commercial purposes). This is especially hard since we’re often conditioned to think in terms of demographics (women ages 25-34 who shop online). The proper way to think about this aspect is to link the cause to the person. Even if it’s hard to target this person at first, that’s ok. Find enough of him or her and you’ll be able to generalize demographic trends that will inform your customer acquisition strategy. But the important thing is to ensure that these people are the FIRST people you’re speaking with when designing your product. They should get it at the outset – if they don’t, it’s unlikely the faceless masses will.
• Create a more detailed view of each constituency. This connects to step 2 in understanding the cause of the pain. Here you understand how your users live their lives. Try to create a few relevant personas
• What are the key drivers that would push someone to need help (think about it as trying to properly order cause and effect)?
• The goal would be to say, if you have the following 5 or 10 attributes you are likely to be in my target group
• Don’t confuse resulting attributes with predictive attributes (Eg assuming that women are your likely target. A woman is the target of a bra manufacturer because their product is specific to women. They may or may not be the target of an e-commerce site just because research, and my grandfather, suggests that they like to shop.)
• Build your solution and your business case – Now you’re ready for Steve Blank’s customer discovery, Eric Ries’ MVP and iteration and all the great minds of the interweb who can guide you on the VC pitch deck

You may often hear that the most successful entrepreneurs just start building. They aren’t seized by analysis paralysis. But I bet if you dig deeper you’ll find that they are able to do so because they are solving problems that they are already innately familiar with. I’ve always said that Mark Zuckerberg isn’t a billionaire because he built Facebook. It’s because if Facebook fell flat, he would have built 20 more consumer product companies before graduating from Harvard and one of them would have hit. He didn’t need to research his consumers and Google alternative solutions. This type of development was in his blood because he built solutions for problems that he inherently understood. If you are one of the intrepid people who wants to follow your gut into unknown territory, you better do your best to create an accurate map.