AgentSkillsCN

working-backwards-pr-faq

以客户为中心的产品探索与验证框架。当你要推介一款新产品或新功能、为重大举措争取高管支持,或当你怀疑团队正在“为解决问题而造出解决方案”时,可运用这一框架。

SKILL.md
--- frontmatter
name: working-backwards-pr-faq
description: Define new products and features by starting with the customer experience instead of technical constraints. Use this when starting a zero-to-one product, deciding which feature to prioritize next, or seeking executive alignment on a complex proposal.

The "Working Backwards" process centers on the PR/FAQ: a mock Press Release and a list of Frequently Asked Questions. It forces clarity of thought by requiring you to describe a finished product and its benefits before a single line of code is written.

The Working Backwards Framework

1. The Press Release (PR)

The PR is a one-page document written for the customer. It describes the product as if it were launching today. It must be factual and data-rich, avoiding marketing hyperbole.

The Three "Money Paragraphs":

  • The Summary: A short description of the product and what the core benefit is.
  • The Problem: A crisp definition of the specific customer problem this product solves. Quantify the problem with data or customer insights.
  • The Solution: A description of how the product elegantly solves that problem.

Essential PR Elements:

  • Hypothetical Launch Date: Choose a date that signals the expected complexity (e.g., next month vs. next year).
  • The "Target Customer": Avoid broad categories. Be specific about who this is for (e.g., "high-volume professional sellers in urban areas" instead of "all merchants").
  • Customer Quote: A hypothetical quote from a customer explaining how the product changed their life or business.

2. The Frequently Asked Questions (FAQ)

The FAQ is a multi-page document that addresses the "behind the scenes" details. It is divided into two sections:

  • External (Customer) FAQ: Questions a customer would actually ask. "How much does it cost?" "How do I switch from my current provider?" "What happens if my internet goes out?"
  • Internal (Stakeholder) FAQ: Difficult questions from leadership or engineering. "Why shouldn't we just use a third-party API?" "What is the fatal flaw in this logic?" "What are the specific engineering risks?"

3. The Concentric Circle Review

Do not write a PR/FAQ in a vacuum. Use a "product funnel" approach:

  1. Author Draft: Write and self-edit. If the idea looks bad on paper, discard it immediately.
  2. Small Group Review: Share with immediate peers for feedback.
  3. Leadership Review: Present to senior stakeholders to test the logic and "disagree and commit."
  4. Iterate: Most successful products go through multiple versions of the PR/FAQ before being approved for development.

Examples

Example 1: A New Delivery Tracking Feature

  • Context: Improving customer satisfaction with shipping.
  • Input: "We want to improve tracking."
  • Working Backwards Application:
    • PR Headline: "Amazon Announces Real-Time Map Tracking for All Deliveries."
    • Problem Statement: Customers currently only know their package is "out for delivery," forcing them to stay home all day to avoid theft.
    • Solution: A live GPS map showing exactly how many stops away the driver is.
  • Output: A document that forces the team to solve the privacy and GPS-latency engineering hurdles before committing resources.

Example 2: A Specialized B2B Search Tool

  • Context: Choosing between "Search for Everyone" vs. "Search for Engineers."
  • Input: "Our search is mediocre."
  • Working Backwards Application:
    • Customer Definition: Instead of "all users," the PR focuses on "Technical Leads looking for deprecated API documentation."
    • PR Focus: A specialized filter for version-specific syntax.
  • Output: Realization in the FAQ that the "all users" approach would obfuscate the most valuable data for the highest-paying customers.

Common Pitfalls

  • Working Backwards from Revenue: Never start with "How do we hit our $10M goal?" Start with "What does the customer need that would result in $10M of value?"
  • The "Product Tunnel": Assuming every PR/FAQ must be built. The goal of the process is to kill bad ideas early. A successful PR/FAQ process should result in many discarded documents.
  • Marketing Hyperbole: Using words like "revolutionary" or "game-changing." Stick to factual descriptions: "The service reduces load times from 5 seconds to 200 milliseconds."
  • Ignoring the Fatal Flaw: Using the FAQ to hide risks instead of exposing them. A good FAQ proactively addresses why the project might fail.
  • Starting with Constraints: Focusing on "We only have three engineers" during the PR phase. Write the ideal customer experience first, then solve the resource constraints in the Internal FAQ.