Product Deep Think

Assess whether and how to build a consequential feature. This is a conversational research exercise: do not edit code or create files unless the user later asks for a plan or implementation.

Interaction Mode

Default to one coherent pass after confirming the problem statement. Do not stop after every analytical lens for ceremonial approval. Pause only when the user's answer would materially change who the product serves, the product boundary, or the recommended direction. If the user explicitly asks for an interactive workshop, work through the lenses one useful question at a time.

Lead with discoveries, not phase narration. Keep intermediate updates short and translate abstractions into concrete user behavior.

1. Establish the Problem

Separate the pain from the proposed feature:

• who experiences it, in which workflow, and how often;
• what they do today, including manual workarounds and tolerated failure;
• what happens if Stella does nothing;
• what outcome would demonstrate improvement.

Confirm this framing once when it is genuinely ambiguous. Do not make the user answer questions the repository or evidence can resolve.

2. Autopsy the Status Quo

Understand why the current process persists before redesigning it. Account for regulation, liability, professional norms, migration, training, political ownership, integration, and parallel safety systems. Apply the Schuster check: is the idea better after switching costs, or merely cleaner on a blank page?

3. Test Stella's Product Boundary

Evaluate the idea for:

• 5–50 lawyer firms without dedicated workflow administrators;
• a credible path to 2,000–5,000+ lawyers;
• buyer, administrator, and daily-user incentives;
• international jurisdictions, terminology, formats, RTL, and legal-system differences;
• privileged data, auditability, trust, and graceful failure;
• open standards, self-hosting, and provider replaceability.

Inspect the current repository and nearby plans so the recommendation extends existing product primitives instead of inventing a parallel system.

4. Research the Market and Structural Analogs

Because product and competitor capabilities change, verify current claims with web research and cite direct, authoritative sources. Separate documented facts from inference and unknowns.

Compare:

• legal-sector table stakes, strengths, complaints, and switching paths;
• adjacent categories that solve the same structural problem;
• interaction models and mental models worth importing, rather than cosmetic feature copying;
• genuine differentiation Stella can sustain rather than a temporary feature gap.

5. Rebuild, Then Reconcile

Describe the clean-slate ideal and its remarkable version. List inherited assumptions and distinguish real constraints from convention. Then bring back path dependence: identify which parts survive now, which require compatibility, and which should only shape the long-term architecture.

Offer at least three shapes when materially different options exist:

• the smallest coherent version;
• the stronger durable version;
• what not to build yet.

Make the tradeoffs explicit and recommend one.

6. Apply the Maintenance Filter

Assess ongoing complexity, operator burden, tuning, failure behavior, likely follow-up demands, extensibility, and the ability to explain the feature in three sentences. Prefer a smaller model with truthful states over a flexible system whose edge cases require permanent manual discipline.

7. Verdict

Return Build, Reshape, Defer, or Kill, with:

• the problem and affected user;
• evidence from the repository and current market;
• options considered and why the recommendation wins;
• the smallest valuable scope and explicit non-goals;
• three guardrails that must carry into planning;
• failure/maintenance risks and success signals;
• a one-sentence pitch to a skeptical managing partner.

Keep the synthesis compact enough to act on. Move to /plan only after the product boundary is coherent and the user asks for a durable plan artifact.