Skip to main content
Back to Insights

Product Development

What We Look for Before Promoting an Idea Into a Product

June 27, 20262 min read

Ideas don''t start as products

Every product we operate started in an experiments backlog, not as a product. That's a structural rule, not a suggestion: a new idea is required to start as an experiment -- research, early validation -- and it only gets scaffolded as a real product after it's scored against an internal evaluation framework and passed a gate that's actually enforced in tooling, not just a conversation.

Why a real gate, not just judgment

Judgment alone has an obvious failure mode: founder enthusiasm for a new idea is a terrible filter, because it's strongest for the idea you just had and weakest for the unglamorous idea that's actually working. A written evaluation framework forces the same questions to be asked of every candidate idea, in the same order, regardless of how excited anyone currently is about it.

What actually gets evaluated

Without getting into the specific scoring criteria, the shape of the question is consistent: is this solving a real, validated problem (not a hypothetical one), is it different enough from what we already operate to be worth the attention split, and is there evidence beyond "it seems like a good idea" that someone would actually use it.

Why this is enforced by tooling, not memory

The promotion from experiment to product is gated by a script, not a mental note. That matters because "we'll formalize this properly later" is exactly the kind of intention that quietly never happens once a product already has users and momentum. Enforcing the gate in tooling means the evaluation has to happen before a product gets its own real infrastructure, not retroactively once it's already too entangled to walk back cleanly.

What this looks like from outside

Both of the products we currently operate, Findora and IITM Grade Suite, went through this same evaluation before either one had its own dedicated product scaffold. Neither is presented as a side project that happened to work out -- each one specifically passed a real, repeatable check for "is this worth running as a product," not just "did someone build it."

This is also why client work and products are run as genuinely separate divisions, never blended -- see About for how that separation works in practice.