MentionRank began as a broad question about how brands appear in AI answers. It became a useful product only after that question was reduced to something people could understand, test and pay attention to. Building it, launching it and eventually handing it over reinforced a lesson I keep returning to: a product becomes valuable through focus, evidence and ownership, not through the number of features around it.
Find the useful version of the idea
Early product ideas are usually descriptions of a possibility, not definitions of a product. They contain several audiences, several problems and a long list of things the software might eventually do. That ambiguity feels exciting, but it makes every design and engineering decision harder. There is no clear way to decide what belongs in the first release because the release has no single job.
MentionRank became easier to build when the promise became concrete: help a company understand whether, where and how it appears in answers generated by the AI systems its customers use. That framing created a useful boundary. Collection, comparison and reporting supported the promise. Features that did not improve that answer could wait.
A narrow product is not a small ambition. It is an ambition expressed in a form that can be tested. Once the core change is clear, depth becomes more valuable than surface area.
- Who needs the answer?
- What decision will the answer improve?
- What evidence must the product collect?
- What can be removed without weakening the promise?
Shipping is a form of research
Planning can reveal contradictions, but it cannot reproduce real use. Before launch, every workflow is evaluated against an imagined user who understands the vocabulary, follows the intended path and values the same details as the builder. Real users behave differently. They skip explanations, bring unexpected inputs and reveal which outputs they actually trust.
The first live version of MentionRank generated better product information than another private month could have produced. It showed where onboarding needed context, which comparisons mattered and where raw data needed interpretation. Those were not cosmetic refinements. They changed where engineering effort deserved to go.
This is why I prefer a complete, constrained first loop over a large unfinished platform. A user should be able to reach the promised outcome, even if the surrounding product is intentionally narrow. Once that loop is real, feedback becomes specific instead of speculative.
Product, engineering and distribution are one system
It is convenient to discuss positioning, onboarding, data architecture and growth as separate workstreams. In a small product they constantly shape one another. A promise on the landing page creates an expectation in onboarding. That expectation determines which data has to be collected. The cost and reliability of collecting that data affects pricing and the frequency of reports.
Treating these decisions as one system prevents local improvements from damaging the whole. A technically impressive capability is not useful if it makes the product harder to explain. A frictionless interface is not honest if the underlying data cannot support the confidence it communicates.
Working across the product rather than inside one discipline also shortens the feedback loop. The consequence of a decision is visible earlier, while it is still inexpensive to change.
- Positioning defines the expectation.
- The workflow turns that expectation into an action.
- The system has to produce evidence the user can trust.
- Distribution determines whether the right people discover that value.
Build for transfer before a transfer exists
An exit makes ownership visible, but transferability matters long before a sale. A product that only one person can operate is fragile. Undocumented accounts, manual deployment knowledge and architectural decisions that live in memory create risk for a buyer, a teammate and the original builder.
Clear repository structure, environment documentation, ownership of external services and repeatable deployment are not administrative work added at the end. They are part of the product. They reduce the cost of maintenance and make strategic options possible later.
The best handoff is unsurprising. The new owner can see how the system works, where it runs, what it costs and how to make a safe change. That level of clarity also improves day-to-day development because the product no longer depends on hidden context.
What I would repeat on the next product
I would start with the decision the product helps somebody make, then design the smallest complete path to that decision. I would put it in front of real users before polishing adjacent features, and I would treat every repeated explanation or manual recovery as a signal that the product still lacks clarity.
I would also make ownership explicit from the first week: source control, services, analytics, deployment and documentation. Those choices rarely produce the most visible demo, but they make every later stage calmer, including growth, collaboration and handoff.
The durable outcome of MentionRank is not a formula for reproducing the same product. It is a way of working: narrow the promise, ship a complete loop, learn from behavior and leave the system easier to own than you found it.