Before starting any project, even a small personal one, it’s important to start with its ‘why?’. There are several reasons for that.

First, generally speaking, for every project you need to answer three questions: why, what, and how. It is always better to start with ‘why’ because while answering it you will better define its requirements, scope, features, etc. (‘what’ of a project) and without that, it will be difficult to work on ‘how’.

Second, every project has a ‘price’, even if you are doing it yourself without spending a penny. It is called opportunity cost: instead of this project, you may be doing something else with a better return on investment (your time). It could be a different project or an altogether different kind of activity.

Third, due to optimism bias, we tend to think that the project will be easier to do and take less time than it will in reality. Sometimes it is true with very small tasks, but I have yet to see a project that was as straightforward as it seemed at the beginning.

Finally, you will understand whether you need to do it. I have seen dozens of projects that either lost steam before completion or after being completed they were hardly used. In most cases, it turned out that either there was no real need for this project in the first place or the problem was much more difficult and nuanced than expected and the cost/benefit analysis was not in favor of finishing it.

There are many ways to get to the ‘why’ of a project. For instance, the customer development process involves a deep dive into this topic, although it is involved. If we are talking about a relatively small project (be it something new or a feature in an existing project), I tend to use the questions below to get to the ‘why’. They start a conversation and I go deeper where necessary. General observations:

  • Depending on a project it may take from a couple of hours to days and weeks to answer these questions and the depth will vary a lot. The larger the project, the deeper you need to go, and answering one question will lead to new ones. This exercise is beneficial even for very small projects, which can be completed in several hours or days, since answering these questions will likely yield multiple insights and direct the development.

  • A rule of thumb: it is ok to spend at least 5% of the project’s time on planning. Depending on a project and the consequences of miscalculations at the beginning, this bar can be much higher. In any case, I would be suspicious if it takes less than that.

  • It is important to write them down. Something that is not written down has a much higher risk of being misinterpreted, forgotten, or distorted later (by others and even by you).

1. What problem does the project solve?

Give a short description of the problem and its context.

2. Whose problem does it solve? / Who are the target users?

Who will use it? For a pet project audience of one (you) can be good enough, otherwise, it is better to hypothesize about users' main characteristics, his or her portrait. For a new feature in an existing project, it is often a subset of existing users.

3. How do you know that the problem exists?

The best way to confirm that the problem exists (and that the project is indeed has a right to exist) is to see it in data, issues of interpretation aside.

The next best thing is users' feedback: if users repeatedly tell you that something is a problem, it is better to listen. Caveats:

  • Users and use cases differ. Sometimes user can represent a very small part of the user base but be very vocal about his problem, inflating its importance. It does not mean that the problem does not deserve attention, but there can be more pressing problems.

  • Users may try to tell you not only what the problem is, but how to solve it. Both pieces of information are useful, but they are not absolute: if users tend to identify their problem correctly, they are not always able to assess how to solve the problem or its difficulty (from the users' perspective it is always ‘fast and easy’ fix), plus they do not know limitations of your system.

  • Do not ask users if something is a ‘good idea’ or if they find it useful. In general, it is better to ask users about how they solved the problem in the past and not how they will do it in the future.

4. How do users solve this problem now or solved it in the past?

Beware if the answer here is that they do not solve the problem now. It usually means one of two things: either you have not researched enough or the problem does not exist. Even absolutely novel products solve an existing problem.

Note: Questions 5-7 pinpoint requirements for the new project.

5. What is bad in current/previous solutions to the problem?

Describe how the existing solution is not optimal for the users. If it is, do you really need this new project?

6. What is good in previous/existing solutions?

Even bad solutions have something good in them. These are the minimal requirements for the product, what not to lose.

7. What kind of improvement in users' life do we expect from the project?

This is the expected utility of the project for the end-user. Usually, it is based on inefficiencies of existing solutions (question 5 above).

8. How will you know that the project is successful?

This is an important question, which defines the target result of the project. For instance, for a pet project the bar can be as low as “I use this project daily for …, which saves me … hours per …” or “I add this project to my portfolio to make it more interesting to clients or potential employers”. For other projects, the success metric may look like the number of daily users, subscriptions, revenue, etc.

9. Can the problem be solved without developing a new project (manually or with an existing project)?

There are two sides to this question:

  • Prototyping and validating: can this project idea be tested and researched deeper without building the product (manual or semi-manual solutions, mockups, no-code platforms, etc.).

  • Competition: can the same expected utility be achieved manually, by modifying use cases in existing solutions or augmenting them? If so, it may be better to try them, they may prove to be a sufficient solution and eliminate the need for a project.

10. What will be the return on investment?

This topic deserves its own post, which I will get to in the future. Here is just a brief overview.

At any given point in time you can do different things. Doing one thing means you are not doing another (opportunity cost mentioned at the beginning). So you need to prioritize, choose between the projects. To do it you need to calculate their return on investment (ROI). There is no one size fits all solution for ROI, sometimes you need to go with your gut, but you still should try quantifying the project as much as reasonably possible.

You need to quantify two parts: costs and returns. The best option is to do it in money, but other options with the same units of measurement can also work. If you are going to compare different projects it is much more precise to use one unit of measurement.

It does not hurt to be more pessimistic. Imagine the project requires twice the planned resources or has two times smaller utility. This will make the ROI two times smaller. Will the project make sense then? Should you still do it?

If after answering these questions the project still looks good, it passed the project passes the ‘why’/‘what for’ test, then it is time to plan and prototype it properly.