One of the best startup lines out there is, "fall in love with the problem, not the solution."
When starting a company, the most important first step is understanding what problem you are looking to solve. A problem you're looking to tackle can be big or small, emotional or physical, logistical or organizational - really centered around anything. Your problem statement is your thesis, it is your roadmap, it is your guiding light that will lead you through the dark and chaotic tunnel that is the startup world.
A problem statement is going to give potential users, investors, and other stakeholders a glimpse into what your company is setting out to achieve. While it doesn't outline the solution nor how you will get there, it gives context as to why you are doing what you are doing.
A problem is what pretenses a solution. Think about it - water filters are to solve a lack of clean water, forks are to solve your need to efficiently eat your food without getting your hands dirty, a towel solves your problem of being wet. If you can't articulate what problem you are solving, well it is likely that nobody will be interested in your solution.
Now, when it comes to a problem you are looking to solve for a startup, the core of the issue is the problem, or pain-point, of your potential customer. It isn't about just solving any problem, it is about solving the single problem that is experienced by many. So it is important to keep your end users in mind before writing your problem statement.
Alright, so now that we have our steps, let's break them down, one by one.
This is your first step, and sometimes the hardest part because of how many variables are involved. Often times your solution you have in mind will be addressing multiple problems. It is important that you really focus on just one - hone in on the core problem that you are looking to solve. How do you choose which problem specifically to focus in on? Well, often times your answer is going to be the biggest problem.
It's important to make your problem sound like a real problem, something that is super painful. So when you think about phrasing your problem, use numbers and data to back it up! The more personalized you can make it, the more real and painful you can make it sound.
Make sure your problem isn't just conjecture, make it something relatable. Nobody wants to just read a statement that they don't care about - show the reader how the pain-point they are reading is something that they can relate to. This goes back to making sure that the problem you are tackling is big, but it also centers around phrasing the problem in a way that anyone can relate to, or at least recognize.
This is where it gets super tough - you need to be SUPER specific. A general problem is one that nobody will listen to, it comes off as though you haven't done your proper research. If you get super specific, you can show the tangibility of your problem. So when making your problem big, make sure you are very specific as to what exactly the problem is.
And now we have fun; give your messaging some massaging! Nobody wants boring, so make it fun and engaging. Focus on the creative part of your problem, how can you articulate the problem in a manner where it not only is clear how big the problem is, but it also seems fun.
There you go, easy, right?
Well, no, it isn't easy. Writing a good problem statement is actually really difficult, because finding the root problem of what you're looking to solve is difficult itself. The important part is that you keep a problem-oriented mindset, so every piece of feedback you get is just one step closer to the right solution. Your problem statement won't be perfect, and it will take many iterations, but slow and stead you'll get there!
A problem statement should be core to your business model before launching your product. If you don't have a problem statement, you need to take a few steps back because you should never move forward on building a product before you've clearly identified the problem you are looking to solve.
Once your product is live, it is still important to keep the problem statement core to what you are doing, let it guide your development roadmap. It isn't of the same importance before you've built your product because now that you have a product, you can let user feedback and real-life use-cases guide your roadmap along with your general problem you are looking to solve.