Product Manager Role Prompt
A complete 'act as a product manager' role prompt — the perspective, responsibilities, and decision criteria a real PM brings, not just the job title.
Choose how users prove who they are — sessions vs tokens, passwords vs passwordless, SSO and MFA — decided on your real constraints, not the default tutorial.
Authentication is hard to change once users exist, so the choice deserves more than copying a tutorial. This prompt works the decision on trade-offs: session vs token, where credentials live, whether to support SSO and MFA, how it behaves across web/mobile/API clients, and the recovery and revocation paths — ending in a chosen strategy with its reasoning, not a default.
Define your auth constraints
Note your clients (web, mobile, API), where credentials would live, and whether you need SSO and MFA. The strategy is decided on these real constraints, not a default.
Open this resource in Role Prompt Generator
Load the prompt into Role Prompt Generator and fill in your context. It frames the session-vs-token, password-vs-passwordless, and recovery decisions as a worked trade-off.
Review the chosen strategy
Read the recommended approach with its reasoning, the client behavior, and the recovery and revocation paths, checking each against your constraints.
Tighten the assumptions and re-run
Where a constraint shifts the trade-off, such as a new client type or compliance rule, adjust the context and regenerate so the strategy fits before you build on it.
Decision 1 (MECHANISM) forces a session-based vs token-based choice tied to THIS product's clients, and a RULE bars deciding on 'what's trendy.' Fill in your web/mobile/API mix and sensitivity, run it in ChatGPT, Claude, or Gemini, and it returns a mechanism with the trade-off reasoning. Role Prompt Generator structures that argument; the architecture call stays yours.
Decision 6 (LIFECYCLE) treats account recovery, session expiry, and token/credential revocation as part of the strategy, and a RULE states recovery and revocation are 'not an afterthought.' The output pairs the chosen approach with an explicit recovery/revocation design, so the paths people forget get decided up front rather than patched after users exist.
Use it for the strategy layer — mechanism, credentials, SSO, MFA, multi-client, lifecycle. Its notFor deliberately skips JWT implementation specifics (pointing to the JWT Security Review Prompt) and roles/permissions (the RBAC Design Prompt). It also won't verify your final design; the security review and build decisions stay with you after you run the generated prompt.
A complete 'act as a product manager' role prompt — the perspective, responsibilities, and decision criteria a real PM brings, not just the job title.
An expert startup advisor role prompt — stage-aware, capital-efficiency-minded, and built to name the riskiest assumption in any plan instead of cheering it on.
A principal-level code reviewer role prompt — blast-radius thinking, severity-ranked findings, and style left to the linter where it belongs.
Convert scattered bug notes, Slack messages, or user complaints into structured engineering tasks with reproduction steps, severity, and root cause hypothesis.
'Make it good', 'be detailed', 'keep it interesting' — vague prompts get vague output. The fix is mechanical: replace every fuzzy word with a checkable instruction.
A reusable AI agent task template with variables for objective, context, available tools, constraints, success criteria, failure handling, and output format.
Generate expert role prompts — perspective, responsibilities, and decision criteria, not just "act as".
The full path to a booking and reservation system — model resources, availability, and reservations, design the booking API, set customer accounts, wire calendar and notification integrations, design the UI, review security, then ship.
The full path to a store you own end to end — model the catalog and orders, design the storefront and checkout, add customer accounts and payments, then secure it, test it, and ship.
Design access control before you build it, not after a breach — choose the authentication approach, model the roles and permissions, review the design for gaps, then document the identity model.
Ask AI which option to pick and it names one in the first sentence — no criteria, no options laid side by side, its assumptions hidden. Here's how to make it compare the choices against explicit criteria first, then recommend with caveats you can actually check.
SSO arrives as a checkbox and lands as a lifecycle. Plan the integration before you build it: the identity key, the linking rule that isn't account takeover, what a provider's groups may and may not grant, and what happens when somebody leaves.