Whenever one wants to create a new product or start a toy project, one will quickly try to find the best way to build it. What are the best technologies? The best design systems and framework?
Counterintuitively, this is one of the worst questions to ask yourself at the beginning of a project!
Preferably, one should try to answer the following questions :
- Do I want to create something valuable or play around with new technologies?
- What problem am I trying to solve for my customers?
- Who are the customers?
- Can I arrange a discussion with some customers? If so, did they mention the problem I was trying to solve by themselves (cf. The Mom Test)?
Wonder How do I know?
Fourty-nine repositories. Guess how many turned out to be successful businesses?
Do I want to create something valuable or play around with new technologies?
You must answer honestly. Because although every choice is reasonable, no clear answer will lead to a very disappointing waste of time.
If you want to try the new JS framework, fire up your code editor and create an app that will allow you to explore as far as you want. Sometimes it will be a hello world, sometimes you will have a full-stack and deployed application—your choice, no wrong answer.
On the other hand, if you want to create something valuable, start with your idea's business end.
You can start with a lousy product on a promising market, but no good product will transform a small market into a great one.
What problem am I trying to solve for my users?
Every time I create something new, I fall right into this trap and wait a few days (sometimes a few weeks :X) before taking the time to answer this critical question.
As a tech and product guy, I often find myself with a very well-built product that does not solve anything. Oops.
That's why each time I try to win this battle with myself and get to the point where I can define the problem I am solving using a 20 seconds sentence.
You might wonder why 20 seconds? Because the other trap I fell for numerous times was to give a very long and passionate answer about such a product's possibilities. Most of the time, people react positively to someone expressing a project with passion and ambition, especially when they don't commit to anything! Their unconscious (or conscious) need to please us even make them pile up with features and ideas. Naively, we perceive that as a validation of our product (spoiler, idea validation is worthless, search for problem validation).
Who are the Customers?
Like the problem, you cannot sell your product if you don't know who to target.
Let's say you are building an enterprise tool. Are your customers the HR services? The managers? The employees?
Be careful not to mix customers (the ones who decide and pay) with final users. In B2C, they often are the same person, but they rarely are in B2B.
At this point, you found your market (i.e., problem + customers)! You are on a good path!
How can you know if your problem is worth investing time and money in?
Well, you can't know for sure, but a good starting point is to talk with your customer (again, not your user).
Can I talk to my customers?
Well, I hope so because if you can't, you will have a hard time selling your product!
So your first action must be to find an acquisition channel that will allow you to create a steady flow of leads. If you can't, you are probably attempting to solve a problem that is not interesting enough for your customers.
Once you have plenty of people to talk to, be very careful to ask good questions.
My mindset for such interviews are the following :
- Never ever mention your product.
- Your central goal is to know more about the life of your interlocutor.
- Do not try to steer the discussion. Embrace the truth!
- Do not seek validation or approval. Even better, use them as triggers to refocus your interlocutor on her problem, not your solutions.
- Once they talk about a problem, I always ask if they tried to fix it yet. If so, how much they spend (in time or money) to fix it. If they didn't try to fix it, you are probably hitten a "not-so-problematic" problem ;)
But I really want to build something?
If, like me, you are a software engineer, it's called... your job!
Build something that someone else wants and get paid to do so. Of course, if you are willing to code on everything except your client's product, it's time to look for another company ;)