PDBen-Auto / practical guides

Four product-research questions that reports alone do not answer

Use the guide that matches the evidence you already have. Each workflow keeps the source boundary visible, distinguishes facts from estimates, and ends with an artifact a product team can review.

Amazon product researchVoice of CustomerSellerSprite BIDesign patent riskGo / No-Go decision

How do I turn Amazon reviews into product requirements?

Start from written reviews, not only sentiment scores. Preserve review IDs, dates, variants, ratings, original text, and evidence limits before grouping recurring friction.

  • Separate negative issues from positive purchase drivers.
  • Link every theme to supporting review records.
  • Translate the signal into product, packaging, fit, listing, and validation actions.
Read the worked review case →

How do I avoid inflating an Amazon market with duplicate ASINs?

Keyword results are discovery evidence, not an automatic TAM. Define the market boundary, retain excluded candidates, require detailed-data coverage, and aggregate sibling listings at the parent ASIN level.

  • Classify direct, adjacent, excluded, and review candidates.
  • Keep the denominator tied to the accepted scope.
  • Label SellerSprite values as third-party estimates.
Read the SellerSprite BI case →

How do I pre-screen design patent risk before tooling?

A product name or image-similarity result is not enough. Read the complete drawing set, compare high-salience visual relationships, separate risk types, and make redesign directions testable.

  • Explain what solid and broken lines appear to protect.
  • Change structure, silhouette, proportion, and component relationships.
  • Re-search the preferred concept before tooling.
Read the design-around case →

How do I build an auditable Amazon product Go/No-Go?

Market demand, customer pain, supplier feasibility, unit economics, and cash constraints often arrive with different definitions. A typed evidence contract makes the handoff reviewable before a private decision engine is asked to score it.

  • Validate required fields and reject sensitive data locally.
  • Bind the evidence bundle to a request hash.
  • Return a bounded handoff when the private engine is unavailable.
Read the Gateway case →
Shared method The public Skills are designed to compose: market scope → customer evidence → design/IP pre-screen → supplier and financial validation → signed decision handoff. Public examples are synthetic or redacted; the workflows do not include hidden telemetry, covert tracking, or backdoor behavior.