Skip to main content

​
Who this is for

The tenant personas (who configures it, who operates it daily, who reads its reports) and the member persona (the tenant’s end customer). Name the job each one is hiring this module to do.

​
The problem today

What these people do instead right now, and why it costs them. Reference real evidence — the benchmark, a design-partner observation, a regulation — not assumptions.

​
What it does (normative)

The capabilities, at the altitude of “a tenant can…”. Each line here should map to one or more Feature Specs later; if a line has no plausible FS, it is marketing, not scope.

​
Non-goals (normative)

What this module deliberately does not do, in v1 and possibly ever. Include the tempting adjacent things and say where they actually belong. This is the most valuable section of a PRD.

​
Success

How we will know it worked, as numbers with a date. Adoption, usage, latency, or revenue — whichever genuinely reflects value. Vague success criteria produce vague modules.

​
Commercial shape

Which metrics this module meters, how it affects the billable base, which capabilities are plan-gated or sold as add-ons, and any pricing implication that constrains the design.

​
Phases

​
Compliance and risk

Personal data touched, consent and retention implications, and the specific obligations under Ley 21.719 / LGPD this module creates. What we would have to do if a data subject asked to be erased tomorrow.

​
Dependencies

Other modules, ports, or vendors this module needs, and what breaks if they are unavailable.

​
Open questions

Each with who decides and by when.

​
Changelog