I’ve been thinking a lot about when to stop working on an idea.
There’s a familiar product instinct that says weak ideas should be identified early, killed quickly, and denied the chance to waste more time. That instinct is useful.
Taken too far, though, it creates a different problem: you can become very good at predicting why things won’t work without ever staying with them long enough to discover what they might teach you.
I’ve had two projects make that tension more visible to me. One was a board game. The other was an AI product concept.
Neither ended up being quite what I originally thought I was building.
The first game
Age of Agon was the first board game I seriously tried to design.
The earliest version was not very good. I had ideas I liked, but I didn’t yet understand enough about game design to know which ones would create interesting decisions once people actually started playing.
So I kept working on it.
I changed systems, rewrote cards, tested things that failed, created artwork and graphic design, learned how to build prototypes, started using AI as part of the creative process, and playtested enough to develop a better sense for the difference between something that works mechanically and something that stays interesting after repeated play.
Eventually, Age of Agon became a real, playable game.
I’m still not convinced that version is worth publishing. It works, but the experience starts to feel a little thin after enough plays.
If I judged the project only by whether that specific game became a commercial product, the return would look pretty limited.
But that would miss most of what happened.
I now have another game, Makers of Mythos, with substantially more strategic and commercial potential. I’m also building a new version of Age of Agon that takes some of the original ideas in a much stronger direction.
Neither exists without the first one.
The original project paid me back in something other than revenue.
It paid me in capability.
The product that stopped needing to be a product
Signals followed a different path but taught me something similar.
I originally imagined Signals as software: a system that could collect information over time, preserve hypotheses, monitor changes, connect weak signals, and help me reason about complex decisions without continually losing context.
That made sense because AI had some obvious limitations. Long-running context was fragile. Deep research could fall apart across sessions. Maintaining a complex thesis over time required a lot of external scaffolding.
A dedicated product seemed like the natural answer.
Then the technology moved.
AI became much better at long-form research, persistent threads, tool use, maintaining complex context, and returning to earlier reasoning without dropping the thread.
Recently I found myself using the Signals process to analyze Adobe, Salesforce, Intuit, Workday, Atlassian, and ServiceNow in one sustained conversation. We formed hypotheses, compared companies, tried to disprove our own ideas, built scorecards, set monitoring alerts, and carried the reasoning forward over time.
At some point I had to acknowledge that a meaningful portion of the software I thought Signals needed no longer seemed necessary.
If I were starting it today, I probably wouldn’t build the same application.
That doesn’t mean the idea failed.
The valuable part turned out to be somewhere else.
What emerged was a methodology: form a thesis, compare it across multiple cases, triangulate evidence, attack the thesis before defending it, make deeper research something an idea has to earn, define what would invalidate the reasoning, and revisit it as new evidence arrives.
The software could shrink while the idea became more useful.
The idea survived. The product didn’t have to.
A project can change what it pays you back in
I think part of the problem is that we tend to evaluate projects according to the payoff we imagined at the beginning.
A game should become a published game.
A product idea should become a product.
A business should make money.
But projects can create other kinds of return.
They can produce learning. They can build capability. They can create option value by making future projects possible. They can generate reusable artifacts, relationships, credibility, or simply a much better understanding of where not to spend your time next.
Most of those returns are difficult to forecast.
Before designing my first game, I couldn’t accurately estimate how much better it would make me at designing the second one. I didn’t yet have the perspective required to make that prediction.
That creates a strange paradox:
If you require every project to justify itself only through outcomes you can already foresee, you may eliminate some of the projects most likely to expand what you’re capable of foreseeing.
But “I’m learning” can become an excuse
There’s an obvious danger in this argument.
It’s easy to romanticize failure after the fact.
Anyone can spend years on an unsuccessful project and then say the experience was worthwhile because they learned something.
Sometimes that’s true.
Sometimes it’s sunk-cost rationalization with better branding.
The opposite extreme isn’t much better.
There’s a certain satisfaction in identifying every flaw in an idea before investing much effort in it. Sometimes that’s wisdom.
Sometimes you’re simply becoming extremely efficient at remaining exactly as capable as you already were.
So I’ve started thinking about projects across two questions:
Is this becoming more likely to produce a worthwhile outcome?
Is it still producing meaningful new capability or future options?
If either is increasing, continuing may be rational.
If both have flattened, continuing probably isn’t persistence anymore. It’s inertia.
Foresight has limits
I still believe in killing bad ideas.
I still believe in asking whether a problem is durable, whether technology is about to erase it, whether the economics make sense, and whether there is a realistic path to success.
But foresight should have some humility built into it.
You can often predict flaws.
You are much worse at predicting what you will become capable of after wrestling with those flaws for a while.
That doesn’t mean build everything.
It means that “this probably won’t become what I originally imagined” is not always the same conclusion as “this isn’t worth doing.”
Sometimes the wrong thing is what teaches you how to build the right one.
And sometimes the most valuable outcome of a project is realizing that the thing worth keeping was never the product at all.