Planning season is around the corner, and we just had an offsite with the team. There were a lot of fruitful discussions, and we ended up with a whole bunch of project ideas we can work on.

On my flight back, I started thinking, how do we evaluate these? How do we know which projects we should take on next quarter/next year?

I categorize the decision-making process into six sets of questions, and I would like to share them here.

I am an engineer. So the perspective might be heavily skewed toward an engineer. But hopefully, these discussions apply to other types of projects as well.

1. Does it solve a real problem?

Where is the idea originated from? Is this a request from a customer? If so, it is usually a good sign. But have you evaluated other customers? Is it a problem specific to a particular user, or is it more general? One-off requests are easy to satisfy but can also lead to the product being overly fragmented/complicated to use.

Is it something that you assumed to be useful? If so, have you brought this up with others? Does anyone else see the same pain points? If it is just something you want, it is still a good candidate for a side project over the weekend. But it is not worth putting on the team/company roadmap. It is not worth quitting your job for.

2. Do You Have Buy In?

Do you have customers’ buy-in? Do you have customers committing to use your product once you deliver it? It is easy to commit to a project if the customer can offer engineering resources to help with the development and/or system integration.

Do you have support from your leadership team? If you do, then you will have some free marketing credit from them since they will help you promote it. If you do not, you can still work on it and demo it with a prototype or an MVP. However, the more you invest in that project, the higher the risk. If it becomes successful, you will be a visionary; otherwise, you will be considered stubborn, a joke, or a bad team player.

Can you excite your team? If this project is too big for you, can you convince your team to go on the journey with you?

3. Is It Achievable?

Are you the right person? Is this a problem you have the technical know-how to solve? Or does your team have the expertise?

A project might be a great one for others but not a good one for you. For example, if your team is primarily front-end engineers, even if you have a great project that requires a lot of backend components, it is probably better to pass on the project idea to some other teams.

Another way to consider this is the time investment. How much time and resources do you need to pour into this to make it a reality? A quarter? A year? Are you ok with putting that much time into it and knowing that it might not work out by the end of the day?

4. What Are the Competitors?

If it is a great project that solves some real customer pain points, it is what your leadership team strongly believes in, and it is pretty achievable with your and your teams’ experience, the next question is — are there competitors?

Are there any other teams that are doing similar projects? Are there similar tools within the organization? Are there similar products on the market?

Is there room for you to make some additional impact? Where are your competing teams? What is their progress? How well are they executing the vision? Do you think they will fail? Do you believe that you can do better than them?

Would it be possible to create a partnership? What kind of partnership relationship would that be? Would you be willing to join their team, or can you convince them to join you?

Do you see any obstacles in acquiring the team? What kind of casualties would you anticipate during the merger or acquisition? Would it still be worth it based on these potential losses?

5. Is This an Interesting Problem?

For engineers, sometimes this can also be translated into whether it is a challenging problem. There is usually a sweet spot for any individuals or teams.

The simpler the problem is, the easier it will be to have competition down the road. The easier it is, the more likely it can be preconceived as boring or repetitive work.

If a problem is too hard, we may be unable to deliver it. It may become too much of a grind. It can lead to burnout. It can make people feel unfulfilled, unrecognized, and ultimately leave the team.

The sweet spot is the balance between the two. It is easy enough that we can deliver and feel accomplished. But it is also hard enough that we can feel challenged, can learn, and grow.

6. Is The Timing Right?

Is this the right time to work on the project?

  • Twitch may not be a popular product before the broadband internet becomes so cheap that it is easily accessible for everyone.
  • Wechat would not have been successful without the wide adoption of mobile phones.
  • TikTok would not be possible without the advancement in computing power and AI to make it feasible to understand the content of millions of videos and the interests of billions of users.
  • Oculus may not be a viable product without the foundation of computer vision, chip advancement, battery improvements, etc.

An idea can be a terrible idea in the past but become meaningful now.

So, the next question is — is now the right time? Are we too early?

What are other project dependencies under development? Would we have a higher chance of success if we wait?

Is the market ready? Is it something that customers understand now and need?

On the opposite side, what’s the risk of not delivering? Is there a burning need to have it delivered now? If we wait, would the impact be bigger? Would we cause problems for the company, the customers, or any partners if we wait?

Those are the six categories of questions to ask when evaluating projects. In summary, a perfect project looks like this:

  • There is a clear need from customers
  • There is strong support from leadership
  • There are no alternatives available
  • The team is committed and has the technical know-how
  • The timing is right, and all the prerequisites are there.

But the problem is — such a project would never exist. For example, if there is a clear market need, and if it is easy, there are probably plenty of the competition.

Ideas are cheap. Though we certainly shouldn’t discard any of them. We should compile them into a list and evaluate and rank them. It is never about right or wrong. What we can do is use our best judgment to identify the projects with the highest potential and start from there.

Are you looking for projects for your team? Are you looking for a project for yourself? Are you debating whether or not you should push back on an ask from a product manager? Do you have a new idea for a startup but are hesitant to start?

I hope these discussions will help you with the decision making.

Updated: