W-11: Product Ways of Work¶
| Field | Value |
|---|---|
| Document | W-11 |
| Title | Product Ways of Work |
| Status | Draft |
| Owner | CPO (Rizwan Zafar) |
| Approved by | CDO |
| Created | 2026-04-05 |
| Review | Quarterly |
| Depends On | W-01 (Company Operating Rhythm), STD-GOV-135 (Execution Framework), STD-GOV-136 (Performance Management) |
Purpose¶
Define how the Product organisation at Simpaisa operates: how features are discovered, specified, prioritised, delivered, and measured. This document establishes the handoff points between Product and Engineering, the standards for requirement writing, and the cadences that keep product development aligned with company strategy.
If it is not described here, it is not how Product works. If the process changes, this document is updated first.
Scope¶
Covers all product lines: Pay-Ins, Pay-Outs, Remittances, Cards, Merchant Portal, and platform capabilities (APIs, SDKs, webhooks, settlement engine). Applies to Product Management, PMO, Service Delivery, and Integration teams reporting to the CPO.
Product Organisation Structure¶
CDO (Daniel O'Reilly)
└── CPO (Rizwan Zafar)
├── Product Management
│ ├── PM: Pay-Ins / Pay-Outs
│ ├── PM: Remittances / Cards
│ └── PM: Merchant Portal / Platform
├── PMO
│ └── Project coordination, reporting, RAID tracking
├── Service Delivery
│ └── Merchant onboarding, go-live support, SLA management
└── Integration
└── Partner & merchant technical integration support
1. Product Discovery¶
How New Features and Products Are Identified¶
Product ideas enter through five channels:
| Channel | Source | How It Reaches Product | Typical Volume |
|---|---|---|---|
| Merchant feedback | Support tickets, QBRs, CSAT surveys | Service Delivery triages and tags product-relevant items weekly | 15-25 items/month |
| Commercial requests | Sales pipeline, prospect requirements | Commercial submits a Product Request Form in Jira | 5-10 items/month |
| Regulatory mandates | Central bank directives, licence conditions | Global Head Regulatory raises a compliance ticket | 2-5 items/quarter |
| Strategic initiatives | CEO/CDO strategy goals (SG1-SG5) | Quarterly roadmap planning cycle | Per strategy cycle |
| Internal observations | Engineering tech debt, operational pain, data analysis | Any team member raises via Jira or CDO Division Standup | Ongoing |
Discovery Process¶
IDEA → TRIAGE → INVESTIGATE → VALIDATE → PRIORITISE → BACKLOG
(weekly) (1-2 weeks) (1-2 weeks) (quarterly (ready for
+ ongoing) development)
Step 1: Triage (Weekly)
- Every Monday, the PM reviews new inbound items from all five channels.
- Each item is tagged: regulatory (must-do), commercial (revenue-linked), platform (capability), experience (merchant satisfaction), or debt (internal improvement).
- Items tagged regulatory skip to Investigate immediately. Regulatory deadlines are non-negotiable.
Step 2: Investigate (1-2 weeks) - PM gathers data: how many merchants affected, revenue impact, competitive landscape, technical feasibility (quick check with Engineering lead). - Output: a one-page Discovery Brief (template in Confluence) covering problem statement, affected merchants/markets, estimated impact, and initial sizing (T-shirt: S/M/L/XL).
Step 3: Validate (1-2 weeks) - For L/XL items: PM conducts merchant interviews (minimum 3 merchants) or reviews usage data. - For S/M items: PM validates with Commercial and Operations stakeholders via Slack or a 30-minute call. - Output: validated Discovery Brief with recommendation (proceed / park / reject).
Step 4: Prioritise - Validated items enter the quarterly roadmap planning cycle (see Section 10) or are added to the product backlog for the relevant team.
2. Requirement Writing Standards¶
Product Requirements Document (PRD)¶
Every feature sized M or above requires a PRD before it enters the backlog. S items may use an expanded user story with acceptance criteria only.
PRD Template (Confluence):
| Section | Contents | Max Length |
|---|---|---|
| Title | Feature name | — |
| Author | PM name | — |
| Status | Draft / In Review / Approved | — |
| Problem Statement | What problem are we solving? For whom? Evidence (data, merchant quotes, regulatory reference). | 200 words |
| Success Metrics | How will we know this worked? Quantified targets. | 3-5 metrics |
| Scope | What is in scope and explicitly out of scope. | Bullet list |
| User Stories | Full user stories with acceptance criteria (see format below). | As needed |
| Wireframes / Mockups | For UI features: screen flows. For API features: request/response examples. | Attached |
| Technical Considerations | Known constraints, dependencies, integration points, data model changes. PM writes what they know; Engineering completes during refinement. | Bullet list |
| Markets Affected | Which of the 6 markets (PK, BD, NP, IQ, AE, KSA) are affected. | Checklist |
| Regulatory Implications | Any licence or compliance implications. Reviewed by Global Head Regulatory for L/XL features. | Paragraph |
| Rollout Plan | Phased rollout, feature flags, pilot merchants. | Bullet list |
| Open Questions | Unresolved items. Must be empty before the PRD is marked Approved. | Numbered list |
PRD Approval: PRDs are reviewed at the weekly Product Review (see Section 9). Engineering leads review the Technical Considerations section and confirm feasibility. A PRD is not Approved until Engineering has signed off on feasibility and the PM has resolved all open questions.
User Story Format¶
As a [role],
I want to [action],
So that [benefit].
Roles used at Simpaisa:
- merchant — a business using Simpaisa to accept or send payments
- merchant admin — a merchant user with administrative access to the portal
- merchant developer — a merchant's technical staff integrating via API
- operations analyst — Simpaisa internal operations team member
- settlement officer — Simpaisa internal settlement team member
- compliance officer — Simpaisa internal compliance team member
Acceptance Criteria Format¶
Every user story must have acceptance criteria written in Given/When/Then format:
Given [precondition],
When [action],
Then [expected result].
Rules: - Minimum 3 acceptance criteria per story (happy path, one edge case, one error case). - Acceptance criteria must be testable. No subjective language ("should be fast", "user-friendly"). - Include specific values where possible: response times, character limits, error codes. - For API features: include request/response payload examples in the story.
Definition of Ready (DoR)¶
A story is Ready for weekly planning only when ALL of the following are true:
- User story follows the standard format
- Acceptance criteria are in Given/When/Then format (minimum 3)
- Dependencies identified and resolved or planned
- UX mockups attached (for UI features)
- API contract documented (for API features)
- Markets affected are listed
- Story is estimated by the Engineering team (story points)
- PM is available for clarification during the cycle
If a story does not meet the DoR, it does not enter the cycle. No exceptions. This is the primary handoff quality gate between Product and Engineering.
3. Backlog Management¶
Prioritisation Framework: WSJF (Weighted Shortest Job First)¶
Product uses WSJF to prioritise the backlog. Each item is scored on four dimensions:
| Dimension | Question | Scale |
|---|---|---|
| Business Value | How much revenue, merchant satisfaction, or strategic alignment does this deliver? | 1 (minimal) – 10 (transformative) |
| Time Criticality | Is there a deadline (regulatory, contractual, competitive)? | 1 (no deadline) – 10 (imminent deadline) |
| Risk Reduction | Does this reduce operational, security, or compliance risk? | 1 (no risk reduction) – 10 (critical risk mitigation) |
| Job Size | How much effort (estimated by Engineering)? | 1 (XL, many cycles) – 10 (XS, a few hours) |
WSJF Score = (Business Value + Time Criticality + Risk Reduction) / Job Size
Higher score = higher priority. Regulatory mandates always receive Time Criticality = 10.
Backlog Structure in Jira¶
EPIC (product capability or feature area)
├── STORY (user-facing functionality)
│ ├── SUB-TASK (engineering work items)
│ └── SUB-TASK
├── STORY
└── BUG (defect in the feature area)
Jira projects per product line:
- PIN — Pay-Ins
- POUT — Pay-Outs
- REM — Remittances
- CARD — Cards
- PORT — Merchant Portal
- PLAT — Platform Capabilities
How Items Enter the Backlog¶
| Item Type | Who Creates | Approval Required | Notes |
|---|---|---|---|
| Epic | PM only | CPO approval at Product Review | Epics represent significant product capabilities |
| Story | PM creates; Engineering may draft technical stories | PM approval | All stories must have a parent Epic |
| Bug | Anyone (QA, Ops, Engineering, merchants) | PM triages and prioritises | Critical/blocker bugs skip prioritisation and enter next cycle |
| Tech Debt | Engineering creates | PM and Engineering Lead jointly prioritise | 20% of capacity reserved for tech debt per STD-GOV-125 |
Grooming Cadence¶
| Activity | Frequency | Duration | Attendees | Purpose |
|---|---|---|---|---|
| Backlog Refinement | Weekly (Wednesday) | 1 hour | PM + Engineering Lead + 2-3 engineers | Refine upcoming stories: clarify requirements, estimate, identify dependencies |
| Epic Review | Fortnightly | 30 min | PM + CPO | Review epic progress, adjust priorities, assess new epics |
| Cross-team Dependency Review | Fortnightly (Thursday before weekly planning) | 30 min | All PMs + Engineering Leads | Identify and resolve cross-team dependencies for next cycle |
Grooming rules: - Stories must be groomed at least one cycle ahead of when they will be planned. - A story that has not been through refinement cannot enter weekly planning. - Engineering estimates during refinement using story points (Fibonacci: 1, 2, 3, 5, 8, 13). Stories estimated at 13 or above must be broken down.
4. Weekly Planning — Product's Role¶
Simpaisa Engineering operates a Kanban workflow with weekly planning cycles. Weekly planning is a shared ceremony, but Product and Engineering have distinct responsibilities.
Before Weekly Planning¶
| Responsibility | Owner | Deadline |
|---|---|---|
| Ensure sufficient stories meet DoR for the next cycle (minimum 120% of team throughput) | PM | Thursday before weekly planning |
| Confirm priority order of stories | PM | Thursday before weekly planning |
| Estimate all candidate stories | Engineering Lead | Wednesday refinement session |
| Resolve open questions on candidate stories | PM | Friday before weekly planning |
Publish candidate list in Jira (label: cycle-candidate) |
PM | Friday 17:00 |
During Weekly Planning (Monday, 1 hour)¶
| Phase | Duration | Activity | Product's Role |
|---|---|---|---|
| Context setting | 10 min | PM presents cycle goal and priority stories | PM leads |
| Story walkthrough | 30 min | Team reviews each candidate story, asks questions, confirms understanding | PM clarifies requirements, answers questions |
| Commitment | 15 min | Team selects stories they can commit to based on WIP limits | PM confirms priority if team cannot take everything |
| Task breakdown | 5 min | Engineers break stories into sub-tasks | PM available for questions |
During the Cycle¶
- PM is available for clarification within 4 hours during working hours (no blocking the team overnight).
- PM attends daily stand-ups as an observer (does not give status updates; listens for blockers).
- If a story's scope needs to change mid-cycle, PM and Engineering Lead agree and document the change in the Jira story comments.
- New stories may be pulled into the cycle only when existing work is completed and WIP limits allow. The PM and Engineering Lead jointly agree on priority.
Acceptance and Verification¶
- Engineering marks a story as
In Reviewwhen code is complete and tested. - PM verifies acceptance criteria on the staging environment within 2 business days.
- PM marks the story as
Acceptedor returns it with specific feedback (referencing which acceptance criterion failed). - Stories not accepted by end of cycle are carried over and discussed in the retrospective.
5. Stakeholder Management¶
Stakeholder Map¶
| Stakeholder Group | Key Individuals | What They Care About | Update Frequency |
|---|---|---|---|
| CEO & Board | CEO, Board members | Strategic alignment, revenue impact, market expansion | Quarterly (via CDO report) |
| CDO | Daniel O'Reilly | Roadmap execution, cross-division alignment, architecture impact | Weekly (Product Review) |
| CTO & Engineering | CTO, Engineering Leads | Technical feasibility, story readiness, planning quality | Daily (stand-ups) + Weekly (planning) + Fortnightly (review) |
| Commercial | Head of Commercial, Sales team | Pipeline support, merchant feature requests, competitive positioning | Weekly (pipeline sync) |
| Operations | COO, Ops Leads | Operational impact of new features, runbook requirements, training | Fortnightly (review) + pre-release |
| Finance | CFO, Settlement team | Revenue model for new products, settlement flow changes, pricing | As needed + quarterly roadmap |
| Regulatory | Global Head Regulatory, Country compliance | Compliance implications, licence requirements, regulator deadlines | Per feature (PRD review) + quarterly |
| Merchants | Merchant admins, merchant developers | Feature availability, API changes, downtime windows | Per release (release notes) + quarterly (QBR) |
Communication Channels¶
| Channel | Purpose | Frequency |
|---|---|---|
| Jira | Story status, cycle progress, bug tracking | Real-time |
| Confluence | PRDs, release notes, product documentation | Per feature/release |
| Slack #product-updates | Lightweight updates, questions, announcements | As needed |
| Email (merchant-facing) | Release announcements, API deprecation notices, scheduled maintenance | Per release |
| Quarterly Business Review (QBR) | Merchant relationship review, feature adoption, roadmap preview | Quarterly per key merchant |
Escalation Path¶
PM cannot resolve → CPO → CDO → CEO (if cross-division or strategic)
Escalation triggers: - Engineering capacity shortfall threatening a regulatory deadline. - Merchant contractual commitment at risk due to delivery delay. - Cross-division dependency unresolved for more than 5 business days. - Scope disagreement between Product and Engineering that cannot be resolved at PM/Lead level.
6. Release Management¶
Release Types¶
| Type | Description | Cadence | Approval |
|---|---|---|---|
| Cycle release | Features completed in the cycle, deployed to production | Fortnightly (or as flow permits) | PM acceptance + Engineering QA sign-off |
| Hotfix | Critical bug fix or security patch | As needed | Engineering Lead + PM (post-hoc for P1) |
| Major release | New product line, significant platform change, API version bump | Quarterly or as planned | CPO + CTO + CDO |
| Regulatory release | Changes mandated by regulators | Per regulatory deadline | CPO + Global Head Regulatory |
Release Notes¶
Every cycle release produces release notes. The PM is responsible for writing merchant-facing release notes; Engineering writes internal technical release notes.
Merchant-facing release notes template:
# Release Notes — [Date]
## New Features
- [Feature name]: [One-sentence description]. [Link to documentation].
## Improvements
- [Improvement]: [What changed and why].
## Bug Fixes
- [Bug description]: [What was fixed].
## API Changes
- [Endpoint]: [What changed]. [Migration guide if breaking].
## Upcoming Deprecations
- [What is being deprecated]: [Sunset date]. [Migration path].
Rules: - Release notes published to Confluence and emailed to merchants within 24 hours of production deployment. - API breaking changes require minimum 90 days notice before the change takes effect. - API deprecation notices must include a migration guide. - Major releases require a merchant webinar or written walkthrough.
Merchant Communication Timeline¶
| Timing | Action | Owner |
|---|---|---|
| Weekly planning | Inform Commercial of upcoming features (internal only) | PM |
| Fortnightly review | Demo to stakeholders including Commercial and Operations | PM + Engineering |
| Pre-release (T-5 days) | Notify Operations and Service Delivery of upcoming changes | PM |
| Release day | Publish release notes, update merchant documentation | PM |
| Post-release (T+2 days) | Monitor adoption metrics, check support ticket volume | PM + Service Delivery |
| Post-release (T+5 days) | Resolve any post-release issues, update FAQ if needed | PM + Engineering |
7. Product Metrics¶
What Product Tracks¶
Product is accountable for outcomes, not just outputs. The following metrics are tracked monthly and reported at the Product Review.
Adoption & Usage Metrics¶
| Metric | Definition | Target | Source |
|---|---|---|---|
| Merchant activation rate | % of onboarded merchants who process first transaction within 30 days | > 80% | Data warehouse |
| API integration time | Median days from API key issuance to first live transaction | < 14 days | Integration team logs |
| Feature adoption rate | % of eligible merchants using a new feature within 90 days of launch | > 40% | Product analytics |
| Monthly active merchants | Merchants with at least one transaction in the calendar month | Growth target per market | Data warehouse |
| Portal login frequency | Average merchant portal logins per merchant per month | > 4 | Portal analytics |
Transaction & Revenue Metrics (Product Perspective)¶
| Metric | Definition | Target | Source |
|---|---|---|---|
| Transaction success rate | % of initiated transactions that complete successfully (per product line) | > 95% (Pay-Ins), > 98% (Pay-Outs) | Platform monitoring |
| Revenue per product line | Monthly revenue attributed to each product line | Per budget | Finance reports |
| New product revenue | Revenue from products launched in the past 12 months | > 15% of total | Finance reports |
Merchant Satisfaction¶
| Metric | Definition | Target | Source |
|---|---|---|---|
| CSAT (Customer Satisfaction Score) | CSAT per touchpoint (onboarding, settlement, API integration, support). 1-5 scale. | > 4.2/5 average | Survey tool |
| CES (Customer Effort Score) | CES for API integration experience. "How easy was it to integrate?" 1-7 scale. | > 5.5/7 | Survey tool |
| Support ticket volume | Product-related support tickets per 1,000 transactions | Declining trend | Support system |
| Time to resolve product issues | Median days from product-related ticket to resolution | < 5 days | Support system |
Delivery Metrics¶
| Metric | Definition | Target | Source |
|---|---|---|---|
| Story acceptance rate | % of stories accepted by PM on first review (no rework) | > 85% | Jira |
| Cycle goal completion | % of cycle goals fully achieved | > 80% | Jira |
| Roadmap delivery accuracy | % of quarterly roadmap items delivered within the quarter | > 75% | Roadmap tracker |
| DoR compliance | % of stories entering a cycle that met the Definition of Ready | 100% | Jira + PM audit |
8. Cross-Functional Collaboration¶
Product ↔ Engineering¶
This is the most critical interface. Quality of this handoff directly determines delivery speed and rework rates.
| Touchpoint | Cadence | Purpose | Artefact |
|---|---|---|---|
| Backlog Refinement | Weekly (Wednesday) | Clarify stories, estimate, identify technical risks | Refined stories in Jira |
| Weekly Planning | Weekly (Monday) | Agree cycle commitment | Cycle backlog |
| Daily Stand-up | Daily | PM listens for blockers, provides clarification | — |
| Fortnightly Review | Fortnightly | Demo, accept/reject stories | Accepted stories |
| Ad-hoc clarification | As needed (< 4 hour response) | Unblock engineers on story details | Jira comments |
| Architecture consultation | Per PRD (L/XL features) | Engineering reviews technical feasibility, identifies ADR needs | Updated PRD Technical Considerations |
Ground rules: - Product owns the what and why. Engineering owns the how. - Product does not prescribe technical solutions in PRDs (unless there is a specific integration constraint). - Engineering does not change scope without PM agreement. - Disagreements on feasibility are escalated to CPO + CTO, then CDO if unresolved.
Product ↔ Commercial¶
| Touchpoint | Cadence | Purpose | Artefact |
|---|---|---|---|
| Pipeline sync | Weekly (Thursday) | Commercial shares prospect requirements; Product confirms feasibility and timeline | Updated pipeline notes |
| Product Request Form | As needed | Commercial submits structured feature requests | Jira ticket (type: Product Request) |
| Fortnightly Review | Fortnightly | Commercial sees what shipped; can demo to merchants | — |
| Roadmap preview | Quarterly | Product shares next quarter roadmap with Commercial for sales enablement | Roadmap deck |
| QBR support | Quarterly per key merchant | Product provides feature adoption data and upcoming roadmap for merchant QBRs | QBR slide pack |
Ground rules: - Commercial does not promise features or delivery dates to merchants without PM confirmation. - Product provides a "safe to share" roadmap each quarter — items on this list can be discussed with merchants. - Items not on the "safe to share" list are internal only.
Product ↔ Operations¶
| Touchpoint | Cadence | Purpose | Artefact |
|---|---|---|---|
| Pre-release briefing | Per release (T-5 days) | Product briefs Ops on new features, changed flows, potential impact | Release briefing document |
| Runbook handoff | Per major feature | Product provides business context; Ops + Engineering write the runbook | Runbook in Confluence |
| Incident review | Per P1/P2 incident | Product assesses merchant impact, prioritises fix | Incident ticket update |
| Channel Health Review | Monthly | Product reviews transaction success rates with Ops, identifies product improvements | Action items in Jira |
Ground rules: - No feature goes to production without Operations being briefed. - Product-related operational issues are fed back to the PM within 24 hours. - Settlement flow changes require Finance sign-off in addition to Ops briefing.
9. Product Review Cadence¶
Weekly Product Review¶
| Field | Detail |
|---|---|
| Frequency | Weekly (Tuesday, 10:00 Dubai time) |
| Duration | 45 minutes |
| Attendees | CPO (chair), all PMs, CDO, CTO |
| Format | Written pre-read submitted by Monday 17:00. Meeting is for decisions, not presentations. |
Standing agenda:
| Item | Duration | Description |
|---|---|---|
| Delivery status by exception | 10 min | Red/amber items only. Green is silent. |
| PRD reviews | 15 min | New PRDs for approval. Maximum 2 per meeting. |
| Backlog health | 5 min | DoR compliance, grooming coverage, upcoming gaps |
| Metrics snapshot | 5 min | Key metrics that moved significantly (up or down) |
| Decisions needed | 10 min | Priority changes, scope decisions, resource requests |
Monthly Product Committee¶
| Field | Detail |
|---|---|
| Frequency | Monthly (third Tuesday) |
| Duration | 90 minutes |
| Attendees | CDO (chair), CPO, CTO, COO, Head of Commercial, Global Head Regulatory |
| Format | Written pre-read circulated 48 hours before. |
Agenda:
| Item | Duration | Description |
|---|---|---|
| Product performance dashboard | 15 min | All metrics from Section 7, by product line |
| Roadmap progress | 20 min | Quarterly roadmap tracker: on track / at risk / missed |
| Market & competitive intelligence | 15 min | What competitors are doing, regulatory changes, merchant trends |
| New product proposals | 20 min | L/XL Discovery Briefs for committee decision (proceed / park / reject) |
| Cross-functional issues | 10 min | Unresolved dependencies, resource conflicts |
| Decisions & actions | 10 min | Record all decisions and assign actions with owners and deadlines |
10. Roadmap Management¶
Quarterly Roadmap Cycle¶
The product roadmap operates on a quarterly cycle aligned to the company's strategic planning rhythm (W-01).
MONTH 1 of QUARTER MONTH 2 MONTH 3
───────────────────── ───────────── ─────────────
Week 1-2: Discovery & Execution Execution +
validation of next next quarter
quarter candidates discovery begins
Week 3: Draft roadmap
shared with CDO & CTO
Week 4: Roadmap presented
at Product Committee
for approval
Roadmap tiers:
| Tier | Confidence | Meaning | Communication |
|---|---|---|---|
| Committed | > 90% | PRD approved, resources allocated, in cycle backlog or next cycle | Safe to share with merchants |
| Planned | 50-90% | Discovery complete, PRD in draft, resource tentatively allocated | Share internally; Commercial may reference with caveats |
| Exploring | < 50% | In discovery or validation, no PRD yet | Internal only |
Strategy Alignment¶
Every roadmap item must map to one or more strategic goals:
| Strategic Goal | Product Focus Areas |
|---|---|
| SG1: Operational Excellence & Platform Resilience | Transaction success rate improvements, platform stability features, monitoring and alerting enhancements |
| SG2: Institutionalise Execution & Performance Management | Product analytics, merchant dashboards, internal tooling for performance visibility |
| SG3: People, Culture & Organisational Maturity | Developer experience improvements, documentation, self-service capabilities |
| SG4: Market Expansion | New market product adaptations, multi-currency support, local payment method integrations |
| SG5: Revenue Diversification | New product lines (Cards, Remittances expansion), value-added services, premium features |
Rule: No item enters the Committed tier without a documented link to SG1-SG5. Items that do not support any strategic goal are deprioritised unless they are regulatory mandates.
Roadmap Artefacts¶
| Artefact | Audience | Format | Updated |
|---|---|---|---|
| Strategic roadmap | Board, CEO, CDO | High-level themes and outcomes, no dates | Quarterly |
| Product roadmap | Product Committee, Engineering Leads | Epics with target quarters, strategy alignment | Quarterly (reviewed monthly) |
| Cycle-level plan | Engineering teams | Stories in Jira with cycle assignments | Weekly |
| "Safe to share" roadmap | Commercial, merchants | Committed items only, no internal-only features | Quarterly |
11. Merchant Feedback Loop¶
How Merchant Feedback Reaches Product¶
MERCHANT
│
├─→ Support ticket ──→ Service Delivery triages ──→ Tags "product-feedback" ──→ PM reviews weekly
│
├─→ QBR meeting ──→ Commercial captures action items ──→ Product Request Form ──→ PM reviews weekly
│
├─→ CSAT survey per touchpoint (quarterly) ──→ PM analyses themes ──→ Discovery Briefs for top themes
│
├─→ API/Portal feedback widget ──→ Logged in feedback system ──→ PM reviews weekly
│
└─→ Merchant developer community (Slack/forum) ──→ Integration team monitors ──→ Escalates product items
Feedback Processing¶
| Step | Owner | Cadence | Output |
|---|---|---|---|
| Collect | Service Delivery, Commercial, Integration | Ongoing | Tagged items in Jira |
| Triage | PM | Weekly (Monday) | Items categorised: bug / feature request / improvement / out of scope |
| Theme | PM | Monthly | Grouped by theme (e.g., "settlement reporting", "webhook reliability") with merchant count and revenue weighting |
| Prioritise | PM using WSJF | Ongoing | Prioritised backlog items |
| Close the loop | Service Delivery | Per resolution | Merchant notified when their feedback results in a shipped feature |
Feedback-to-Feature Tracking¶
Every feature that originated from merchant feedback must be tagged in Jira with merchant-requested and linked to the originating feedback items. This enables:
- Reporting on "% of roadmap driven by merchant feedback" (target: 30-50%).
- Closing the loop with specific merchants when their requested feature ships.
- Identifying merchants whose feedback consistently aligns with product direction (candidates for beta programmes).
12. Product Documentation Standards¶
Documents Product Owns¶
| Document | Purpose | Audience | Location | Updated |
|---|---|---|---|---|
| PRD | Feature specification | Engineering, QA, Design | Confluence (Product space) | Per feature |
| Release notes | What shipped and changed | Merchants, internal teams | Confluence + email | Per release |
| Merchant guides | How to use features | Merchant admins, merchant developers | Developer portal / Confluence | Per feature launch |
| API documentation | API reference, request/response schemas | Merchant developers | Developer portal (auto-generated + PM narrative) | Per API change |
| Product FAQ | Common merchant questions | Service Delivery, merchants | Confluence | Monthly review |
| Roadmap deck | Upcoming product direction | Product Committee, Commercial, merchants (safe-to-share version) | Confluence + slide deck | Quarterly |
| Discovery Brief | Problem validation and recommendation | Product team, CPO | Confluence (Product space) | Per discovery |
Documentation Rules¶
- No feature launches without documentation. If the merchant guide is not ready, the feature is not ready. Documentation is part of the Definition of Done.
- API documentation is auto-generated from OpenAPI specs, supplemented by PM-written narrative sections (use cases, examples, migration guides).
- Release notes are written in plain language. No jargon. A merchant admin who is not technical must understand what changed and whether they need to do anything.
- Deprecated features must have documentation maintained until the sunset date has passed.
- All documentation is reviewed by at least one person other than the author before publication.
- Documentation uses British English spelling throughout, consistent with Simpaisa's company standards.
Documentation in the Development Workflow¶
PRD (approved) → Stories include documentation tasks → Feature built →
PM writes merchant guide → Engineering updates API docs →
QA verifies docs match behaviour → Release notes drafted →
Fortnightly review includes doc review → Published on release day
Compliance with This Document¶
This document is the authoritative reference for how Product operates at Simpaisa. All PMs, the CPO, and teams interfacing with Product are expected to follow these processes.
Deviations are permitted only with CPO approval and must be documented. Persistent deviations indicate the process needs updating — change this document rather than silently ignoring it.
The CPO reviews this document quarterly and proposes updates at the Product Committee. The CDO approves changes.
Related Documents¶
| Document | Relationship |
|---|---|
| W-01 (Company Operating Rhythm) | Master cadence that this document's meetings must align with |
| STD-GOV-135 (Execution Framework) | How initiatives are proposed, approved, and tracked company-wide |
| STD-GOV-136 (Performance Management) | Company-wide metrics framework that Product metrics feed into |
| STD-GOV-124 (ARB Charter) | Architecture review for features with significant technical impact |
| STD-GOV-125 (Technical Debt Management) | 20% capacity allocation for tech debt |
| STD-GOV-133 (ADR Lifecycle) | Architectural decisions triggered by product changes |