How I Decide What to Build

Coming up with ideas is usually not the hard part for me. There are almost always a few things I could build, and most of them seem interesting at first. The harder part is deciding which ones are actually ready.

I used to think that decision was mostly about taste. Pick the best idea. Pick the most interesting problem. Pick the thing that feels most useful. But I do not think that is really the decision anymore.

What I am usually deciding now is whether an idea has become clear enough to survive tradeoffs.

That sounds narrower, but it explains a lot more. Some ideas sound good because the problem is real. Some sound good because the frustration is obvious. Some sound good because they are still surrounded by possibility. But a product only really starts once the idea becomes specific enough that you can make hard decisions without the whole thing falling apart.

I think that is the part I understand better now.

A real problem can still resist productization

One idea I keep coming back to is a kind of personal CRM. The basic idea is simple: help me keep track of how often I interact with someone, and remind me when I have not reached out in a while.

The problem feels real. Relationships usually do not drift because of one big event. Most of the time, people just get busy. Time passes quietly, and then one day you realize it has been months since you last talked to someone you actually care about.

That seems worth solving.

But every time I think about building it, the idea starts expanding. You begin with reminders. Then you want notes. Then some way to group people. Then maybe context, follow-ups, priorities, maybe even messaging or calendar integrations. Pretty quickly it stops feeling like one product and starts feeling like several possible products layered on top of each other.

At first I treated that as a scoping problem. Now I think it is a product problem.

The issue is not just that the idea gets bigger. The issue is that I still do not know what remains after I cut it down. I can see the problem clearly, but I cannot yet see the boundary that turns the problem into a product. I do not know what the smallest version is that still feels whole.

That matters more than I used to think. A product boundary is not just about keeping scope manageable. It is what makes the product legible. It tells you what belongs, what is extra, and what should be left out even if it sounds useful. Without that boundary, every feature discussion becomes vague because there is no center strong enough to decide against.

That is usually when an idea is still too early.

Seeing friction clearly is still not enough

The other idea gets stuck in a different way.

It is a fitness app for the Apple Watch. The goal is simple: I do not want to pull out my phone during a workout, and I do not want the workout to turn into a logging session after every set.

That is the part I dislike about a lot of existing flows. You decide the workout ahead of time, start it on your phone or watch, and then keep logging or confirming things as you go. Even if that flow works, the interaction still competes with the workout. The workout becomes something you keep interrupting so you can record it.

What I want instead is something more invisible. Ideally, the watch would identify the motion I am doing, predict the exercise, and log it in the background. Then at the end of the session, I could correct anything it got wrong and add details like weight.

This idea taught me a different lesson.

Here, the problem is not that the product wants to become too many things. The problem is that I still do not know what the right replacement experience actually is. I can describe what feels wrong about the current flow, but that is not the same as knowing what to make instead.

I think that gap is easy to underestimate. It feels like progress to diagnose the friction clearly. It feels like insight to say exactly what is annoying. But critique is still much cheaper than product shape. Knowing what is wrong is not the same as knowing what should replace it.

That is why this idea still feels unresolved. The direction feels right, but the product is still too hand-wavy. I can point at the problem. I still cannot make enough decisions about the solution.

MapleDays changed what I pay attention to

I think MapleDays made this easier for me to notice.

What stayed with me from that project was not really the speed. It was how much easier the project became once it had one clear job. Before that, a lot of things probably could have belonged. After that, the tradeoffs became much more obvious. It became easier to tell what was core, what was adjacent, and what needed to wait.

That changed how I think about stalled ideas.

Before that, it was easy to treat momentum like a motivation problem. If something was not moving, maybe I was distracted, inconsistent, or not pushing hard enough. After MapleDays, I think momentum often comes from clarity. Once the product has a center, decisions start getting easier instead of harder.

That is a much more useful signal.

When an idea is not ready, every option feels half-right. Every feature sounds reasonable. Every path seems plausible for a while. Nothing settles anything because there is no product center strong enough to absorb the tradeoff.

When an idea is ready, the opposite starts happening. Constraints become helpful. Cutting things makes the product sharper instead of weaker. The next decision still might be hard, but it does not feel arbitrary anymore.

That is probably the threshold I care about now.

What I think I am really deciding

I do not think deciding what to build is mostly about picking the most exciting idea anymore. I think it is about deciding whether an idea has become clear enough that the tradeoffs start telling the truth.

With the personal CRM idea, the problem is real, but the boundary is still unstable. I still do not know what the product becomes once I strip it down.

With the watch idea, the frustration is obvious, but the replacement is still unresolved. I still do not know what the right interaction model is.

Those are different failures, but they point to the same thing. The idea has not become concrete enough to hold decisions.

That is probably why this matters to me now. A lot of ideas sound promising while they are still protected by vagueness. They only really reveal themselves once you start forcing specificity on them. Some get stronger. Some collapse. Some stay interesting, but only as problems, not as products.

I think that is the real filter.

Not just whether the problem is real. Not just whether I care about it. Not just whether the idea sounds smart when I explain it.

The better question is whether the product gets clearer as I narrow it down.

Maybe I will revisit both of them

After building MapleDays, I think I see both of these ideas a little differently.

I have not let go of them, but I am also less tempted to romanticize them. The personal CRM idea still needs a real boundary. The watch idea still needs a real product shape. Those are not small details. They are probably the whole thing.

I may revisit both of them.

If I do, I think the test will be simple. Not whether the ideas are still interesting, but whether they hold up once I force them to become specific. Whether cutting them down makes them clearer. Whether the next decisions start getting easier instead of harder.

That is usually when an idea stops being just an idea.

That is when it starts becoming a product.