Project Doggo

Every member wants a different Kagi

Kagi wants to delight every member.

But one member's essential feature is another member's clutter. Some requests are too niche for the shared product. Others would make an already powerful interface harder to understand. Even a feature worth building must compete for a small team's limited development time, then somehow become discoverable after it ships.

The problem is not a lack of good ideas.

One roadmap cannot become every member's ideal Kagi.

Shipping the feature is only half the job

Kagi may spend months designing, building, and releasing exactly what a member asked for.

But if members cannot find it, recognize it, or figure out how to apply it to their problem, the request comes back as if the feature were never built.

Now a developer has to stop and explain the product one member at a time.

A feature that members cannot discover keeps costing developer time after it ships.

Before Kagi can answer, it has to understand

Most requests do not arrive ready for the roadmap.

Screenshots are missing. The expected result is unclear. Important context arrives several replies later. Someone must reproduce the problem, search for duplicates, ask follow-up questions, and reconstruct what the member is actually trying to accomplish.

Only then can Kagi decide whether the answer is an existing feature, a workaround, a personal customization, or something the shared product should become.

A reasonable answer can still disappoint

Kagi developers use software too. They understand why every reasonable request cannot be fulfilled.

That does not make waiting any less disappointing.

A developer may agree that a request is worthwhile and still be unable to reach it for months or years. Until then, the member must tolerate the problem, study Kagi's machinery, find a workaround, or keep asking.

A small team is a good reason not to put every variation on the roadmap.

It is not a satisfying answer for the member who needs that variation today.

Kagi cannot build every variation into the shared product.

But members should not have to wait for the shared product to get the Kagi they need.

The condensed Problem has concrete evidence - missing screenshots, unclear expectations, context arriving several replies later, developers explaining shipped features, and members waiting months or years. But it still reads as a synthesis rather than a situation unfolding.

Before finalizing the pitch, consider opening the Problem with one compact scene that connects the member's frustration to the developer's interruption. The regional-search case is a strong candidate:

A member searches for a site they know exists and gets nothing. They do not know that their region setting suppressed it. The report reaches Kagi without the active region, the expected result, or the tests needed to distinguish a setting from a bug. Before anyone can help the member, a developer has to reconstruct the search.

This scene is based on the observed reports in ../evidence.md, especially M03. The member's failed search and regional workaround are observed. The combined developer-intake sequence is a concise synthesis of the broader evidence and must not be presented as a verbatim journey from one source.

Do not invent a named persona merely to satisfy the PPPP "Picture" pattern. Use a traceable observed case, label any adaptation, and let the concrete situation do the work.

1. Open with the member's transformed experience

A member says what is wrong, confusing, or missing. They do not have to understand the cause, know Kagi's terminology, or propose the right feature.

They leave with a tangible result:

• a working adjustment to their Kagi;
• an existing capability applied to their situation;
• a personal workflow that fits their need; or
• confirmation that the shared product needs to change.

The payoff is not merely receiving an answer. Their Kagi works better now.

2. State the governing promise

Every member request should lead somewhere useful. Yet every member request should not become developer work.

A request does not disappear merely because it does not belong on the roadmap. It reaches the right outcome.

3. Turn a rough problem into a useful result

Members are best positioned to describe what is wrong or what they need to change. They should not have to design the solution.

The desired outcome becomes clear, existing capabilities and related issues are considered, and the request reaches one of two broad destinations: a personal result or a shared-product issue.

4. Give personal needs personal results

When Kagi can already support the outcome, the member gets that capability applied to their situation. When a personal variation can solve the need, it remains personal rather than becoming shared-interface complexity.

The member gets a faster result without waiting for roadmap prioritization, implementation, release, documentation discovery, or a developer explanation.

5. Turn product problems into stronger product signal

When the shared product needs to change, the interaction still leads somewhere useful. The developer receives:

• the problem the member encountered;
• the outcome they were trying to reach;
• relevant context gathered up front;
• what was already attempted;
• related discussions and documentation;
• reproduction evidence where available; and
• the boundary between current and expected behavior.

The report arrives closer to a development decision, not the beginning of an interview.

6. Let repeated feedback compound

A new report should not create another isolated thread when Kagi already knows about the underlying issue. It can direct the member to an existing resolution, connect them with a known issue, add a reproduction case, reveal another affected configuration, or strengthen the evidence behind an existing product need.

Each new report should add evidence, not restart the investigation.

7. Recover developer time without giving members less care

Developers spend less time asking for missing context, explaining existing capabilities, finding duplicate feedback, evaluating personal variations for the shared roadmap, and translating vague dissatisfaction into something actionable.

Members still receive thoughtful help. More importantly, they receive a result. Developers can focus on genuine defects, recurring unmet needs, difficult design tradeoffs, and engineering work only Kagi's team can do.

8. End on the two-sided payoff

Members get faster results. Developers get better questions.

Members leave with a Kagi that works better for them. Developers receive better evidence about where Kagi should improve for everyone.

The remaining section in the 30x500 Pain-Dream-Fix framework is Fix. It must introduce Doggo as credible relief, not merely restate the Dream or list features.

A useful Fix structure to explore:

1. A member invokes Doggo from the point where Kagi is not working for them.
2. Doggo starts with the reported problem rather than requiring the member to design an outcome.
3. It gathers the missing context and checks current Kagi documentation, settings, behavior, and related feedback.
4. It distinguishes between an existing capability, a personal variation, a known issue, and a new shared-product problem.
5. It previews a personal change or workaround before the member applies it.
6. When developer work is necessary, it prepares an inspectable report and leaves product judgment with Kagi's developers.

The Fix must answer the credibility questions the Dream creates:

• Can Doggo explain current Kagi behavior accurately?
• Can it distinguish a hidden capability from a product defect?
• Can it find meaningful duplicates rather than discussions that merely share words?
• Can members and developers inspect and correct its reasoning?
• What can it change directly, and what requires member confirmation?
• How does it avoid confidently teaching incorrect behavior?
• What development and maintenance burden does it create?
• What is the smallest useful experiment?

The evidence ledger validates the Pain and supplies cases against which Doggo can be tested. It does not prove Doggo's performance. Until a prototype or manual trial demonstrates these outcomes, describe the mechanism and its expected results as hypotheses.

Doggo resolves what does not require a developer and prepares what does.

PPPP adds a final Push after the pitch proves the Fix. The proposal should explicitly tell Kagi's developers what decision or action it wants from them.

The strongest likely ask is not a commitment to build all of Doggo. It is a narrow validation step that can generate the proof the pitch currently lacks:

Let me test Doggo against a fixed set of real Kagi feedback cases and show whether it can produce useful member results and developer-ready reports without hiding product problems.

Before finalizing this section, define:

• who is being asked to approve or participate;
• the smallest representative set of feedback cases;
• what Doggo will do manually, with a prototype, or with live Kagi access;
• the success and failure criteria;
• the time or access required from Kagi; and
• the decision the results will enable.

The Push should be specific enough that the reader knows what to do next, but proportionate to the proposal's current validation status.