From a product perspective, quality is not a defect count; it is whether users complete valuable tasks and want to return. Technical metrics need to be interpreted through scenarios, outcomes, and trust.
The Product Quality Perspective Skill evaluates behavior through customer outcomes and product risk, preventing a green dashboard from standing in for user value.
The membership-upgrade example ties customer tasks, pricing and entitlement rules, payment failure states, conversion signals, and acceptance gaps to business decisions.
Awesome QA Skills organizes Skills by language and testing stage. The series overview covers repository structure and shared installation options; this guide stays with Product Quality Perspective.
Read the source Skill first
The main prompt covers Inputs, Applicability Check, Product Questions, Output Contract, Evidence and Boundaries. Those headings are navigation; the project artifacts still provide the facts.
This Skill has no separate examples directory. The sample below is derived from its entry point, main prompt, and eval constraints.
Related Skills
Product Quality Perspective starts with user tasks and business trade-offs. These Skills add collaboration, QA evidence, or experience detail:
| Skill | When to use it | What it adds |
|---|---|---|
| Multi-Role Quality Synthesis | Product, QA, Technical, and UX material needs to be combined | Preserves role evidence and disagreement in a decision-ready summary |
| QA Quality Perspective | Product risks need to be tied to coverage, gaps, and release evidence | Checks whether test conclusions support a specific release judgment |
| UX Quality Perspective | A user task is blocked by comprehension or failure recovery | Connects the issue to states, impact, and verifiable actions |
| Technical Quality Perspective | Business rules depend on interfaces, data, or recovery | Connects business risk to runtime consequences and technical evidence |
| Project Delivery Perspective | Scope, dependencies, or verification windows affect the date | Tracks delivery conditions without making Product or QA approvals |
What Product Perspective contributes across the workflow
Product, QA, and UX use the same development stages but ask different questions. For a membership-upgrade change, Product keeps asking what it means for users and the business; it does not turn every stage into a test checklist.
| Stage | Product question | What the team receives |
|---|---|---|
| Requirements analysis | Are user value, business rules, scope, and acceptance clear? | Product report, rule gaps, open questions, and responsible roles |
| Test strategy | Which journeys and failure outcomes deserve protection, and are trade-offs explainable? | User/business risk priorities and evidence needed for a decision |
| Test strategy review | Do excluded or downgraded risks have a Product rationale and accepter? | Findings, impact, and revisions to strategy trade-offs |
| Code review | Can the change be traced to user value, business rules, and acceptance criteria? | User-impact questions and evidence requests for Development or QA |
| Test case writing | Do cases protect key journeys and business rules? | Product priorities, missing rules, and verifiable outcomes |
| Test case review | Do expected results represent outcomes users can perceive? | Coverage gaps, business ambiguity, and missing materials |
| Test reporting | How do tested, untested, and blocked work affect user and business decisions? | Product impact, residual risk, and release questions |
| Test report review | Do conclusions trace to user value, rules, and real evidence? | Risk, information gaps, actions, and confidence |
The Product output contract includes summary, facts, evidence, findings, risks, information gaps, questions, actions, and confidence. It explains product impact but does not turn a recommendation into a test pass or release approval.
Separate the three perspectives on one input
| Shared input: delayed payment callback | Product Quality Perspective | QA Quality Perspective | UX Quality Perspective |
|---|---|---|---|
| Requirements, PR, regression record, payment logs, timeout recording | Confirm waiting rules, duplicate-charge risk, and business approver | Check whether timeout, retry, and reconciliation ran and have evidence | Check whether users understand processing/timeout states and can recover |
Membership-upgrade evidence should answer product questions
Review membership-upgrade scope, failure states, and acceptance gaps through user value and business rules. The examples tie product questions to user actions and business outcomes.
| Product question | Evidence | Judgment |
|---|---|---|
| Does the user understand the benefits? | Benefits copy, pricing page, usability record | Missing explanation can affect conversion and complaints |
| Can the user continue after payment fails? | Callback, order state, retry record | The failure path determines duplicate-charge risk |
| Is trial eligibility stable? | Rule document, account data, boundary cases | Eligibility drift can damage trust |
Put user tasks, business rules, and evidence together before asking the Product owner to make a trade-off.
Return to the user task when metrics move
Lower conversion, more refunds, and rising support complaints need explanations tied to a specific task. Keep signals, hypotheses, and next checks together.
| Signal | Candidate explanation | Next check |
|---|---|---|
| Membership upgrade conversion falls | Price change, unclear benefits, or payment failure | Segmented funnel, payment logs, user interviews |
| Refund rate rises | Delayed benefit delivery or misunderstood rules | Order state, benefit delivery time, support tickets |
| Complaints fall | Entry point is hidden and users stop trying | Entry-point exposure, abandonment, new-user feedback |
Retain the signal source and unverified assumptions. The Skill organizes options; the Product owner decides scope and release conditions.
Carry the same product risk from requirements to release
Product judgment should travel through development handoffs, not appear as a paragraph added just before the release meeting.
| Development step | Inputs | Question | Handoff |
|---|---|---|---|
| Requirements review | Membership rules, pricing, benefits, user tasks | What must the user accomplish, and which outcome is unacceptable? | Business rules, acceptance gaps, open questions |
| Design and development integration | UI states, API contract, order-state transitions | Are success, processing, failure, and retry defined consistently? | State table, boundary rules, integration record |
| Testing and defect review | Cases, order samples, payment logs, support feedback | Which risks have evidence and which remain product assumptions? | Risk list, evidence index, follow-up tests |
| Release review | Build ID, funnel data, residual risk, owners | Does this scope support release, and who accepts remaining risk? | Product decision record and follow-up actions |
For a delayed payment callback, Product confirms whether users see “processing” and the maximum wait; Development explains order state, callback idempotency, and benefit delivery; QA retains timeout, retry, and reconciliation evidence. “Payment is broken” is too vague to tell anyone what to do next.
Acceptance rules can be made concrete:
- After successful payment, order state and membership benefits eventually agree; duplicate callbacks do not grant benefits twice.
- While payment is processing, the page explains the state and next step without prompting another payment.
- After payment failure, the order is not marked successful and the user can retry safely or contact support.
- Trial eligibility, price, and benefits use the same business-rule version; test data and release material record their sources.
The following product-quality record is hypothetical; it demonstrates structure and does not describe a real project result.
stage: test-report-review
user_task: User upgrades membership and receives benefits
business_rule: Duplicate callbacks for one order grant benefits only once
facts:
- A successful-payment example for build-2026-09-24-01 is saved
- The timeout example has only a screenshot, with no order state or callback log
evidence:
- checkout-success-report.html
- order-1234-event-log.json
inference:
- Timeout recovery does not yet support a claim that duplicate payment is prevented
unknown:
- Maximum wait for a processing order and support fallback
risk: high
action: Add timeout, duplicate-callback, and reconciliation records; then confirm waiting copy with Product
owner: Payment lead / Product lead
confidence: mediumDuring integration, Product can check whether business_rule appears in the API contract and acceptance criteria; QA can trace evidence to run records; the release owner can review unknown, risk, and owner without searching chat history. The summary can be brief, but the fields must connect to the next action.
Adaptable prompt
Use the product-quality-perspective Skill.
Stage: test report review (test-report-review)
Task: Review membership-upgrade scope, failure states, and acceptance gaps through user value and business rules
Version and environment: [requirement / build / environment]
Inputs: [file paths or links]
Scope: [included and excluded journeys]
Constraints: [accounts, data, time, compliance]
Report summary, facts, evidence, findings, risks, information gaps, open questions, actions, and confidence. Focus on user tasks, business rules, acceptance criteria, and business impact. Cite the source for each judgment. Mark unsupported content as a gap or assumption; do not report code correctness, test pass, or release approval.Keep product quality grounded in completed user tasks
A membership-upgrade review should cover UI states, benefit comprehension, payment completion, and failure recovery. Start with the main task, key rules, and unacceptable failures such as duplicate charges, delayed benefits, or lost trial eligibility.
Metrics also need to map back to tasks. A conversion drop may come from pricing or payment failure; fewer complaints may mean the entry point disappeared. Retain user signals, business rules, and unverified assumptions so the Product owner can decide whether to change scope or release conditions.
Who should use this Skill
Product managers can check whether acceptance criteria reflect user tasks. QA can add business risks and unacceptable failures. Delivery leads can include conversion, trust, and scope trade-offs in release review. When evidence is missing, keep the question open rather than inventing a user conclusion.
Review a product assessment before handoff
| Review item | What to retain | If missing |
|---|---|---|
| User task | Target user, key path, and unacceptable failures | Ask for confirmation; do not invent a rule |
| Business rules and scope | Sources, inclusions, exclusions, and acceptance criteria | Record the rule gap and affected scope |
| Evidence and judgment | Orders, logs, feedback, acceptance records, and linked conclusions | Separate facts, inference, and assumptions |
| Product risk and action | User/business impact, owner, next step, and confidence | Do not compress risk into “overall manageable” |
| Responsibility boundary | Product impact only; no code correctness, test pass, or Go/No-Go | Ask the relevant role for its assessment |
Install and invoke
Install the individual Skill. The series overview carries the longer installation explanation.
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-workflows/product-quality-perspective -gInvoke it with “Use the product-quality-perspective Skill,” then attach the real artifacts.
Common questions
Will the Skill identify why conversion fell?
No. It separates candidate causes such as price, payment, benefits, and entry points, then lists the evidence needed.
What if there is no user-research data?
Start with requirements, analytics, support tickets, and order records. Mark risk assumptions and schedule research to confirm them.
Can a Product quality conclusion replace release review?
No. It provides user and business evidence; release review still considers test, technical, and operational risk.
When is product risk ready for a decision?
Key tasks, business rules, and failure recovery need sources; remaining risk needs an owner, accepter, and due time.
Run Product Quality Perspective against real user tasks, business rules, and order evidence, and retain inputs, output, and review notes. The example provides structure; project evidence must come from the project.
References
- Awesome QA Skills project:https://github.com/naodeng/awesome-qa-skills
- Awesome QA Skills series overview:https://inaodeng.com/en/blog/ai-testing/introduction_of_awesome_qa_skills/
- Awesome QA Skills: Product Quality Perspective Skill source:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-workflows/product-quality-perspective
- Product Quality Perspective Skill details:https://inaodeng.com/en/qaskills/product-quality-perspective/