This is a mobile version, full one is here.
13 October 2020
Lack of Problem Is the Problem
Do you know the most typical mistake startup founders make when they pitch their ideas to investors? According to Jake Mendel from Silicon Valley Bank, they often focus on the solution they propose instead of the problem they are trying to solve. Inability to identify the problem is the common cause of startup failures. However, it’s not only them. Look at your project and try to answer “What’s wrong with the world now?” and then “How is this product fixing it?”
Something has to be wrong. Otherwise the project doesn’t make sense. Neither for its founders, nor for its programmers and users.
Open the README file in your repository and read its first paragraph. Does it answer the question? Does it identify the problem? Is it obvious to your users what exactly you are solving? It should be.
You may say, “startup founders are looking for money, that’s why they need this problem statement to impress investors, but we already have the budget and don’t need to impress anyone, we just need to create yet another version of our mobile app so that our users continue ordering pizzas and our director keeps paying us,” and you would be right about not needing the money. You will get the money no matter what, whether your README file has a properly formulated problem statement or even if no such file exists. Who am I kidding? In most cases, even if we don’t have a repository we will still be paid well!
This is true, but I think that money is not the fuel of
the software economy
anymore. It’s people. Not just people, but
motivated people—this is what software teams are now fighting for.
Getting a budget for a project, especially if you are
in a big enterprise (where all interesting projects will be eventually),
is not difficult. A much bigger task is to acquire and retain a team that is
able and willing to deliver results.
First, you pitch to investors. Then, you pitch to programmers. The second pitch is more difficult than the first one. Highly qualified software experts motivated to work full-speed for your project—is the new capital in this modern economy.
How do we acquire and retain them? We formulate the problem. We make sure the problem is new, big, ambitious, challenging, and noble. If we can do that, they will join and will stay … motivated.
I would even say that the primary responsibility of a team leader is keeping an eye on the problem statement and making sure it’s good enough for the team. When something goes wrong with morale, discipline, or performance—these are the symptoms of a defective problem statement. In most cases. And the only person responsible is the team leader, who has to fix it by opening the README file and specifying, in the first paragraph, what is wrong with the world right now and how our product is going to fix it.
Do it now.