Debugging is figuring out why something is not working as expected. Both sides of the equation matter. It could be "not working" because either 1. your expectations are wrong OR 2. there is a reason and you haven't found it yet. Your job while debugging is to pinpoint this reason, develop the logical steps that ultimately explain the actual observations, the reality.
While debugging you have to start with the observations and logically explain why that is the manifested reality. If you think "it can't be this way, it doesn't make sense" well it is. The computer doesn't care how incredulous you feel. It is what it is. The question is what are you doing to do next to figure out why.
If you've done your share of debugging, you're nodding along to the above. Now how does this relate to building a business (e.g indie hacking)?
The goal of indie hacking is to create an independent profitable online business. And your expectation is that you have the x to create such a business (x = skill, work ethic, potential, etc.) . The reality is that you have not been successful yet. i.e. "it's not working."
So what next? You start with your observations about the world and your understanding of how humans work. Then you come up with a hypothesis that you can systemically test.
For example, here are some possible hypotheses for why a business may not be working:
- you are not solving a problem that people actually have.
- you are not solving a problem that people are inherently willing to pay money to solve.
- you are not communicating the value of your solution - you are not helping someone make more money or save time.
- you are not known, you have not earned the trust of your future users or customers (so they're not willing to pay you, yet).
- you are not using the right distribution channels, so you have not reached the right customers.
- you have chosen a solution where the market is not big enough, there aren't enough people with the problem for your business to grow and be profitable.
- your product doesn't work, is buggy, hard to use.
There are many more hypotheses for why a business is "not working". Debugging is an art and a science. The art is about coming up with the right hypothesis to test and the science is about being systematic in your experimentation such that you make progress towards the truth. Towards learning to see the world clearly and learning the reality of your environment.
Business building has another added challenge. The time scale for this experimentation is different than for debugging code. How long is a typically debugging session for code? Several minutes, hours, days, a week at most? Debugging our way through indie hacking may take a tad longer than that. It may take months, even years. But this analogy feels right. Thinking this way can certainly bring systematic discipline to our indie hacking activities.
Personally, this analogy also feels somewhat comforting because while I'm not good at business strategy (yet!), I am good at debugging sh*t, getting to bottom of something, finding the root cause. I hope this mindset also gives you a useful mental model for business building.