Devlog: 2026-04-20 — Customer Signal Roles Reframe

What Happened

During a chunk-#2 selection conversation following Phase 8.5 W2-4 close-out and the deferral of the Greg-demo (Backlog #32, path c eliminated 2026-04-20 per "Watermark TPO does not use PowerFill"), the Product Owner surfaced a strategic frame that materially recasts how PSSaaS reads "customer signal" for product prioritization. This devlog banks the reframe as durable agent memory before it gets lost between sessions.

Discovery

What we assumed (operating frame through Phase 9 + 8.5):

• WTPO/MWFI is the design partner + first adopter (per ecosystem/strategic-context.md §4.1) — load-bearing for product strategy
• Chunk-selection priority follows what WTPO needs next
• "New customers first, migrating customers second" (per ADR-007) is the audience prioritization
• Three chunk-#1 attempts (BestEx founding-era → Pipeline Management 2026-03-17 → PowerFill) all eventually demoted by WTPO signal — read as "we keep mispredicting customer needs"

What's actually true (PO direction 2026-04-20):

• WTPO is a test partner whose business is still forming — building relationships + taking on capital, with the holding-company restructure (MWFI Holdings LLC eventually purchases Watermark Capital) pending. Not in production-scale operation.
• WTPO is correctly load-bearing for plumbing validation: PSSaaS↔PSX integration mechanics, multi-tenant runtime, AVD↔SQL MI, Keycloak auth, embedded SDK
• WTPO is NOT load-bearing for product-feature-prioritization signal because the business model is itself emergent and may not represent any stable customer archetype
• The actual production customer base — and the load-bearing product-strategy signal — is existing PowerSeller Desktop App customers, who would need migration-pull motivation to leave on-prem
• The three chunk-#1 demotions weren't a prediction-quality pattern — they were a signal-class-conflation pattern: the input signal was indexed on a partner whose load-bearing class is plumbing-not-product

The real signal: migration-pull from existing Desktop App customers. Two PO-named pain points:

• BI-style drill-down reporting — Desktop App doesn't have this; modern BI is a clear "leave the old world" signal
• Data-ingestion / normalization friction — current Desktop App onboarding requires a human to map 100+ fields, set up value translations and transformations, write a ton of syntax. PSX ingestion pipelines are the cloud-native pattern that solves this; PSSaaS could leverage or repackage the pattern to eliminate the daily-friction tax

Customer Role Recalibration

Customer / Partner	Previous Role	Reframed Role (2026-04-20)	Load-bearing FOR	NOT load-bearing for
WTPO / MWFI Holdings	Design partner; first adopter; load-bearing for product strategy	Test partner / R&D collaborator (business still forming)	Plumbing validation: PSSaaS↔PSX, multi-tenant runtime, AVD↔SQL MI, auth, embedded SDK, production-adjacent infra at real-data scale	Product-feature prioritization; chunk-selection priority; representativeness of any stable customer archetype
Existing PowerSeller Desktop App customers	"Second priority" per ADR-007	Primary product-strategy index — migration-pull is the chunk-selection criterion	Daily-friction signals (what hurts in on-prem tooling); migration-blocker signals (what's missing in cloud)	Greenfield SaaS UX for net-new customers (their workflows are calcified around Desktop App patterns)
Greg (contract president)	Risk module oracle; chunk-selection consultation	(Unchanged) — plus: load-bearing for "what does WTPO actually do" disclosures when they happen	Risk module validation; chunk-selection consultation; A54/A66/A69 technical consultation	Existing-customer migration signals (different customer base than Greg's primary contact pattern)
Tom (senior dev)	Maintains Desktop App; legacy knowledge source	(Unchanged) — plus: load-bearing for existing-customer pain signal (he's the one who hears it from current customers); Phase 10+ cutover-shape	Legacy-knowledge questions; Desktop App config patterns; what existing customers complain about; cutover-shape	Cloud-native architecture choices
Joe (IT/Infra)	Infrastructure, customer migrations, security	(Unchanged) — plus: load-bearing for existing-customer migration mechanics + Backlog #32 path-b data-sourcing	Customer migration mechanics; identifying migration-candidate customers; sanitized customer data sourcing	Feature design
Lisa (CEO + MWFI CEO)	Strategic direction; market knowledge	(Unchanged) — plus: load-bearing for V1 feature surface per pre-existing §7.4 open question	Market-strategy decisions; customer-relationship escalations; V1 feature scope	Daily-friction product details

What's NOT Changing

• WTPO is still the right partner for PSSaaS↔PSX plumbing, runtime, and infra validation. Phase 8.5's auth + embedded-SDK work continues to ride on this partnership.
• ADR-015 (Desktop App Coexistence) — desktop app + SaaS App coexist indefinitely; no forced migration timeline.
• ADR-021 (PowerFill Port Strategy) — chunk-by-chunk extraction with parity validation remains the migration approach.
• The Process Discipline canonical is unchanged. Three-Category Criterion + Single-Probe Confidence + Backlog Re-Read Pass + Cross-Boundary Cutover Verification Recipe all continue to apply.
• The chunk-selection-from-signal process is unchanged. The signal source changes.

What IS Changing

• Chunk-selection criterion: From "what does WTPO need next?" to "what most efficiently lures existing Desktop App customers into the cloud?"
• Phase 8.5's strategic positioning: Reclassified from "Greg-demo plumbing" to foundational infrastructure for the BI-drill-down-reporting migration-pull objective. Work product unchanged; framing upgraded.
• ecosystem/strategic-context.md §4.1 (MWFI characterization): "Design partner and first adopter" framing is superseded for product-strategy purposes. Original document preserved as kickoff-day artifact (March 16, 2026); this devlog is the canonical update.
• ecosystem/strategic-context.md §8 (Tier Assessment): Outdated. Reporting moves from Tier 3 (build-or-buy commodity) to Tier 1 (BI-drill-down is the migration lure). Import/Export moves from Tier 3 (commodity) to Tier 1 (data-ingestion-modernization is the second migration lure). BestEx Tier 1 framing was already corrected by the 2026-03-17 priority pivot. Pooling Tier 1 framing was correct in retrospect (PowerFill chunk #1).
• ADR-007 (Target Audience): "New customers first, migrating customers second" framing is incomplete. Existing Desktop App customers (migration pull) should be the primary product-strategy index for chunk-selection; new-customer onboarding remains a design constraint. ADR-007 amendment proposal pending.

Top-of-menu chunk candidates under the new criterion

(Captured here for chunk-selection continuity; NOT a commitment — see Backlog #32 + Greg + Joe + Tom for actual chunk-#2 disposition.)

Candidate	Migration-pull thesis	Status
BI drill-down reporting — content layer	"Cloud version has reports the Desktop App can't do, AND the ones it CAN do but better + accessible from anywhere + shareable"	Phase 8.5 built the plumbing; chunk-#2 candidate is content — more dashboards, per-customer authoring, saved-view sharing — not new infrastructure
Cloud-native data-ingestion / normalization service	"Cloud version eliminates the 100+ field mapping ritual via self-serve mapping UI / pre-built per-LOS templates / PSX-style auto-detection"	NEW build; could leverage PSX ingestion-pipeline pattern; cleanest "obvious daily-friction-reducer" for migration appeal
Pipeline Management (the 2026-03-17 spec)	"Track post-purchase the way you track today, but accessible from anywhere + auditable + multi-user"	Spec drafted (977 lines); never implemented; ~9 months stale (auth / PSX-contract / PowerFill-learned-conventions need refresh) before kickoff-ready
BestEx (revival of founding-era implementation)	"Best-execution analysis, in the cloud"	Implemented + parked (12-of-24 steps + 8 simplified TODOs); power-user feature; not daily-friction-reducer; harder migration argument than BI or ingestion
PowerFill (already done)	"Pooling, in the cloud"	Done as chunk #1; high-stakes-low-frequency; weaker pull than BI or ingestion for typical Desktop App customer

Broader Insight

The structural lesson worth banking: PSSaaS spent ~6 months treating WTPO's emergent-business needs as load-bearing for product-strategy signal when WTPO was actually load-bearing for plumbing-validation signal. Three chunk-#1 attempts (BestEx founding-era → Pipeline Management 2026-03-17 → PowerFill 2026-04-20) all hit the same demotion shape because the input signal was indexed on a partner whose business is itself still forming.

This is a candidate process-discipline antipattern shape worth banking for second-instance corroboration: "Signal-Class Conflation Across Partner Roles" — a partner can be load-bearing for one signal class (plumbing, technical-collaboration, runtime-validation) without being load-bearing for another (product-feature-prioritization, market-fit-validation, daily-friction). The conflation arises when one customer/partner is the most visible source of "customer signal" in the project's working context AND product-strategy decisions are being indexed on their needs AND the partner's business itself is in flux. All three conditions present = high probability of conflating signal types.

Counter (proposed): at chunk-selection or major-prioritization moments, explicitly enumerate which partners are load-bearing for which signal class, and verify the signal driving the decision matches the partner's load-bearing class.

Not yet promoting to canonical process-discipline.md (single-instance origin per the canonical-promotion convention); banking for second-instance corroboration. The Single-Probe Confidence sub-instance caught earlier in this same chunk-#2 conversation (PSSaaS Collaborator missed implementation state for BestEx + Pipeline Management when treating spec docs as canonical project state) corroborates a structurally adjacent shape — "treating one signal source as comprehensive when it's not" — but doesn't yet hit the partner-role-conflation specifically.

Cross-references

• devlog/2026-03-17-priority-pivot.md — Act 2 of the chunk-#1 history; first instance of the WTPO-demotion pattern (now reframed as a signal-class-conflation pattern, not a prediction-quality pattern)
• ecosystem/strategic-context.md — March 16, 2026 kickoff snapshot; §4.1 + §7.4 + §8 + ADR-007 all superseded for product-strategy purposes by this devlog
• handoffs/pssaas-session-handoff.md Backlog #32 — chunk-#2 conversation downstream of this reframe + Joe's data-sourcing
• agents/process-discipline.md — banking "Signal-Class Conflation Across Partner Roles" for second-instance corroboration before canonical promotion