Which Project Should I Work On?

June 5th, 2017

What if you have a list of personal projects you want to work on and want to know which ones will provide the best return? Today, I try to guide you in the right direction.

Recently, a fellow reader reached out to me and mentioned he had a product he was making and he has a number of ideas to implement. He wanted to know which ideas should be his primary focus.

I'm assuming this is a side project outside of his regular 9-to-5 job. If not, that's even more awesome.

As a developer, we are always coming up with ideas on how to do something better, write something original, or just make our lives easier.

But how do we evaluate projects and determine which ones will fail and which ones will succeed?

Today, I'll review a number of ways  on how to move forward with your project, validate it, and how to build it for your future users. Others may have a different approach, but it seems this has done well for me in the past.

Consolidate Ideas

First, collect all of your notes and place them into a central-ish location. What do I mean by "central-ish?"

I currently use a number of tools to keep everything within arm's reach. These tools you use should be as handy as possible when ideas strike.

When these ideas enter your mind, consolidate them into your primary, secondary, or even tertiary tool.

To consolidate my projects, I currently use a combination of digital and analog tools.

It's definitely better than using a bunch of napkins and Post-It's on your desk.

Once you have all of your thoughts and ideas consolidated, this gives you an at-a-glance or 50,000-foot view of your projects.

This collection of ideas will start to shift, move, gel, and form something you can wrap your head around and get a better feeling of what is required to make a full-blown product.

Validate Your Ideas

When you come up with these ideas, something (or someone) triggered it for you to pursue it.

Whatever that trigger was, write it down. Have a collection of these triggers. You may notice that some of these ideas start to relate to one another.

The whole concept behind validating an idea is to save you time. Before you dedicate yourself to a life of solitude writing a product, you need to confirm whether it's worth the initial effort to invest time into building it. Will there be a payoff in the end?

For example, over the past six months, I've been thinking about writing and self-publishing an eBook. I haven't started it yet, mind you, but I have a general concept of what the book would include.

Recently, I've received a number of comments from readers asking if I could explain how to implement this particular topic on their site.

These comments just became my validation.

If one-to-three people comment that "you should" do something, that's your validation. It's a subtle nudge to let you know more people would be interested in what you have to offer.

If one person is interested in it, I can guarantee that in this world of billions, there may be a couple more individuals who would be interested in your product.

Of course, you don't want to wait for someone to ask you to write or build something (that may take forever).

There are other ways to validate your idea.

Provide a solution to a common problem and you have a product to build.

Build Your Product

Everyone has ideas. There are millions of people who say "I have an idea to build..." and that's as far as it gets. Their idea fizzles and dies.

Execution is king in the coding world.

This is probably the most critical piece of generating your product: converting your idea into an actual product. You (or someone you know) needs to write code!

But how do you know what to include in the product and what to focus on first?

Based on your ideas from above, I'm pretty sure you have a solid list of what to include in an MVP.

No, not the most valuable player. It stands for Minimal Viable Product.

The thought behind this concept is you want to create a product with the minimal amount of features to get out in front of people.

Why would you want to do this? There are a couple of reasons why.

1. Kitchen-Sink Think

I've been guilty of this as well. "I am going to create the ultimate product with everything in it!"

Yeah...that kind of thinking where you include everything (but the kitchen sink) will doom a project from the start.

It's great to PLAN to include everything (in phases), but not on a first release.

Honestly think it through and understand what's important in your initial roll out.

Don't get a "Kitchen-Sink Think."

2. Introductions First

Building everything into a product could potentially overwhelm your users and possibly scare them off ("Your product is too complicated").

Introduce them to a smaller list of features.

Once users understand your product when it's initially rolled out, you can knock their socks off by gradually adding more features in a future release.

Over time, your product will grow as well as your community of users and understanding of the product. They will take the journey with you and your product.

3. Better Product Roadmap

With a smaller set of features in your initial product and a healthy list of ideas for future releases, this gives you a good, clear picture of your product's entire lifecycle.

Base your roadmap on features currently in the product with features you want to include from your idea list (i.e. integration with other systems) along with user feedback ("I want this feature").

Pick your Product's Features

One simple technique I use when writing software is to envision your product's feature list as an end result.

Almost like reverse-engineering your ideas?

This is where your idea list and mindmapping comes into play.

To create your MVP,

  1. Take your idea list and create features out of them. Pretend you're a marketing executive and get sales-y. For example, one idea would be to make an API for a to-do list. The "marketing speak" would be: Integration with various To-Do lists. This will generalize your features.
  2. Once you have your feature list, start prioritizing these features with a 1 (MUST have to fundamentally work) to a 5 (bell or whistle; not important).
  3. Once you prioritized your features from step 2, execute on them!
    1. Priority 1 - Focus on these to release an MVP.
    2. Priority 2-3 - These will become roadmap features in a future release.
    3. Priority 4-5 - If they are small enough and users request them, work them into a future release.

Continue this cycled approach by adding more creative thoughts, ideas, and user feedback to expand your product's features and roadmap.

Once you present your initial product to users, Priority one's definition will transform into "what features need to be in the next release."

Conclusion

In this post, I've explained a way to take your ideas, validate them, and prioritize them into features when creating an MVP.

For a majority of developers who work from 9-to-5, there are times when you don't have enough energy to even LOOK at a computer in the evening after a rough day of work let alone work on side project.

For those who have the fire in them and have the ability to create products during their off-hours, this post should give you the most bang for the buck.

You want to create the smallest amount of value to your users while minimizing the effort as a part-time developer.

I wish you success in building your product and hope to use it in the future. ;-)

How do you build a product? Do you reverse-engineer your ideas into features? Post your comments below and let's discuss.