Personas

╔══════════════════════════════════════════════════════════════════════════════╗
║                    TARGET AUDIENCE & USER PERSONAS                           ║
╚══════════════════════════════════════════════════════════════════════════════╝

Last updated : 2026-07-19
Audience     : Operators, product thinking, services copy, onboarding design
Related      : strategy.txt · Mission & Services · Platform Strategy · Workflows
Public site  : site/docs/personas.html (built from this file)

──────────────────────────────────────────────────────────────────────────────
WHY THESE EXIST
──────────────────────────────────────────────────────────────────────────────

These personas capture the three most realistic buyer / operator archetypes
for PMS. They keep product decisions grounded in real operating context —
not abstract feature checklists.

Use them when:

  • Prioritizing features or production workflows
  • Walking a business process "in their shoes" (rent close, WO bill, statements)
  • Writing copy for services, marketing, or first conversations
  • Evaluating "should we build this?" against proportionality
  • Structuring onboarding, stewardship, or pilot month design
  • Positioning menu paths and language for less-trained operators

If a persona doesn't exist for a situation, ask:

  "Which of these three most directly experiences this pain?"
  …and continue from there.

──────────────────────────────────────────────────────────────────────────────
TARGET AUDIENCE (SUMMARY)
──────────────────────────────────────────────────────────────────────────────

Primary fit (sweet spot):

  • Typically 5–30 doors (product works up to ~150)
  • Family-owned, inherited, or informally syndicated portfolios
  • Side portfolios alongside other careers — not full-time PM software buyers
  • Overwhelmed by enterprise SaaS pricing / complexity
  • Want clear rent, expense, and owner records — not a "platform"

Probably not a fit (today):

  • Large PM companies needing full tenant portals and marketplace integrations
  • Operators who want zero human involvement (pure self-serve SaaS)
  • Anyone expecting a mobile-first consumer app out of the box
  • Buyers who insist on multi-year history reconstruction before go-live

North star framing: docs/strategy.txt §2 (Who we serve).
Mission framing:    Wiki → Mission & Services → Who we help.

──────────────────────────────────────────────────────────────────────────────
HOW TO USE PERSONAS FOR PRODUCT & WORKFLOWS
──────────────────────────────────────────────────────────────────────────────

When designing or reviewing a production capability, run this short loop:

  1. NAME THE JOB
     e.g. "Close June rent and send owner packages"

  2. PICK THE PRIMARY PERSONA
     Diane / Raj / Elena — who feels this pain most days?

  3. WALK THEIR WEEK
     When do they open the menu? What do they already know?
     What must they trust without opening Excel?

  4. TRACE THE PATH
     Menu keys → scripts → ledger truth → statement / PDF
     (see Wiki → Workflows and docs/workflows-finance.txt)

  5. ASK PROPORTIONALITY
     Would AppFolio / Excel / a black-box dashboard serve them better here?
     If yes, we are overbuilding or under-explaining.

  6. WRITE THE SUCCESS LINE
     One sentence they could say at the kitchen table:
     "Numbers match; I can defend every line."

Do not invent a fourth persona for every edge case. Stretch one of the three
first; only add a new archetype when pain and buyer path truly diverge.

──────────────────────────────────────────────────────────────────────────────
PERSONA MAP → CORE LOOPS (THINKING AID)
──────────────────────────────────────────────────────────────────────────────

  Capability / loop              Diane cares      Raj cares       Elena cares
  ─────────────────────────────  ───────────────  ──────────────  ──────────────
  Cold-start go-live             family meeting   evenings only   pilot month
  Monthly INV- + collect         "did we get it?" 11pm recon      team handoff
  Soft-void / re-post            rare but scary   weekly reality  training cost
  Work order → bill owner        cousin asks why  forgotten bill  ops discipline
  Owner statement PDF            kitchen table    send & sleep    client package
  Inspectable scripts / SQL      cousin the CPA   audit himself   train operators
  Flat setup + stewardship       vs AppFolio/door time > features ROI math
  Export / exit rights           trust            backup habit    peace of mind

Finance contract (binding): rent invoice → collect → owner ledger → statement.
Work orders: expense → complete → bill owner → ledger. No invented history.

──────────────────────────────────────────────────────────────────────────────
1. DIANE — "THE FAMILY ACCOUNTANT (BY DEFAULT)"
──────────────────────────────────────────────────────────────────────────────

Portfolio   : 18 doors — East Valley Phoenix
              Inherited from parents, now split among four cousins
Day job     : HR manager; "accidentally" became the bookkeeper in 2019

The pain of the quarterly house meeting:

  • Every April, cousins gather around her dining table with printed
    Excel sheets they swear they updated
  • Numbers never add up; someone misread a line as "income" when it
    was a refund
  • She wants statements she can defend without opening
    rent_2023_FINAL_REAL_v3.xlsx

The PMS story:

  • Cold-start approach: loads current doors, rents, go-live month
  • Within two cycles: generates owner statements by property — PDF,
    readable by someone without a calculator
  • At the next meeting, numbers match the ledger
  • One cousin: "You actually did it this time."
  • Diane: says nothing, pours coffee

Why PMS wins:

  • Proportionality — AppFolio charges per-door with features she'll
    never use; Excel costs brain cells; PMS costs one flat setup +
    optional monthly stewardship
  • The product is open enough that her cousin the CPA can inspect it

Product lens (use when building):

  • Statements must be kitchen-table defensible (by property, clear labels)
  • Cold start only — do not promise multi-year archaeology
  • Language: plain English over SaaS jargon
  • PDF/package quality matters as much as the underlying ledger

──────────────────────────────────────────────────────────────────────────────
2. RAJ — "THE PART-TIME LANDLORD"
──────────────────────────────────────────────────────────────────────────────

Portfolio   : 11 units (mixed residential) — Tempe, Mesa, Chandler
Day job     : Software tester, 9-to-5
              Property management ~8 hours/week (evenings & weekends)

The pain of the 11pm bank reconciliation:

  • Between day job, family, and tenant emails, rent collection
    happens in fragments
  • One payment recorded as "income", another as "a mystery deposit"
  • Work order for water heater gets completed but never billed to
    the right owner ledger
  • Month-end: everything argues with everything else

The PMS story:

  • Wants the simplest path from "I collected rent" to
    "the owner statement makes sense"
  • Runs: rent hub (invoice) → collect → if weird, soft-void + re-post
    → statements hub (generate owner statement)
  • It's a menu. No "dashboard" to learn.
  • Monthly invoice posts to the ledger. Late fees calculate when
    configured. Runs statement on the 3rd, sends PDFs, sleeps.

Why PMS wins:

  • Menu-driven, not SaaS-driven — most platforms are built for
    full-time operators who live inside a web app
  • Raj lives in the real world and only logs in twice a week
  • A bash-menu console over HTTPS is something he can understand,
    audit, and back up without calling support

Product lens (use when building):

  • Happy path must fit a short evening session
  • Error recovery (soft-void, re-post) must be obvious and safe
  • WO complete → bill owner must not be a separate forgotten ritual
  • Low cognitive load: numbered menus, one action = one meaning

──────────────────────────────────────────────────────────────────────────────
3. ELENA — "TOO SMALL FOR APPFOLIO, TOO BIG FOR SPREADSHEETS"
──────────────────────────────────────────────────────────────────────────────

Portfolio   : 34 units across 3 buildings — Gilbert & Queen Creek
Day job     : Managing partner at a three-person PM micro-firm
              (her + two operators)

The pain of the ROI math not working:

  • Enterprise SaaS pricing is per door, per feature tier, per support
    level
  • For 34 units: $300–500/month just for software + two operator
    licenses + annual increases + migration fees
  • Excel is a Rube Goldberg machine held together by shared-drive
    links and prayer

The PMS story:

  • Sees cold-start setup ($1,500–5,000 one-time), monthly stewardship
    ($150–400/mo bundled with hosting) on the services page
  • Books discovery call, loads current structure, does one pilot month
  • Team produces complete owner packages without spreadsheet "close day"
  • Operators love that they can see the scripts that generate the
    numbers; owner clients love that statements reconcile on second try

Why PMS wins:

  • Inspectability + exit rights — enterprise platforms are black
    boxes that make you feel grateful when export finally works
  • Built on MariaDB + bash with full SQL audit trails and documented
    schema
  • Elena knows if she wants to leave, she walks with her books. That
    peace-of-mind justifies the monthly stewardship fee.

Product lens (use when building):

  • Trainability: two operators must learn without a week of SaaS onboarding
  • Pilot-month success is the sales proof
  • Schema, wiki, and scripts are part of the product story
  • Multi-owner / multi-building packages must batch cleanly

──────────────────────────────────────────────────────────────────────────────
COMMON THREAD
──────────────────────────────────────────────────────────────────────────────

  • All three: Enterprise software was never designed for them. It was
    built for portfolios 10× their size where the buyer is a VP, not
    the person who reconciles rent at their kitchen table on a Tuesday.

  • All three value: "Statements you can explain at the kitchen table"
    — not a black-box dashboard.

  • All three would leave if: Pricing went to SaaS-scale, cold-start
    philosophy was abandoned, and they were told "you'll need to import
    history" to use the statement feature.

──────────────────────────────────────────────────────────────────────────────
WHERE THIS DOCUMENT FITS
──────────────────────────────────────────────────────────────────────────────

  strategy.txt              Public north star — audience summary
  Mission & Services        Customer-facing "who we help"
  Platform Strategy         Architecture + positioning one-liners
  Workflows / finance       How the loops actually run in the menu
  First Conversation (PIN)  Sales talk track — map prospect → persona
  Onboarding Playbook (PIN) Pilot month — which persona is onboarding?
  Internal Strategy (PIN)   Pricing & client profile — same three people

Edit this file by hand (not overwritten by update_docs.sh).
Rebuild public HTML: site/bin/build-docs.sh
View in operator wiki: [y] System → [1] Wiki → Personas