Back to Details

define-hypothesis

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Hypothesis

假设

A hypothesis is a testable prediction about how a change will affect user behavior or business outcomes. It transforms assumptions into explicit statements that can be validated or invalidated through experimentation. Well-formed hypotheses prevent teams from building features based on untested beliefs and create shared understanding of what success looks like.
假设是关于某项变更如何影响用户行为或业务成果的可测试预测。它将假设转化为明确的陈述，可通过实验验证或推翻。严谨构建的假设能避免团队基于未经验证的想法开发功能，并让团队对成功标准达成共识。

When to Use

适用场景

  • After problem framing, before committing to a solution
  • When designing experiments or A/B tests
  • When team members have differing assumptions about user behavior
  • Before investing significant engineering resources in a feature
  • When pivoting direction and need to validate the new approach
  • 完成问题界定后，确定解决方案之前
  • 设计实验或A/B测试时
  • 团队成员对用户行为存在不同假设时
  • 投入大量工程资源开发功能之前
  • 调整方向并需要验证新方法时

Instructions

操作步骤

When asked to create a hypothesis, follow these steps:
  1. State the Belief Articulate what you believe will happen. Use the structured format: "We believe that [action/change] for [target user] will [expected outcome]." Be specific about the intervention . vague hypotheses can't be tested.
  2. Identify the Target User Define who this hypothesis applies to. A hypothesis about "users" is too broad. Specify the segment: new users in their first week, power users with 10+ sessions, churned users returning, etc.
  3. Define the Expected Outcome What behavior change or result do you expect? Frame it in terms of user actions (complete onboarding, make a purchase, return within 7 days) rather than internal metrics when possible.
  4. Set Success Metrics Choose a primary metric that directly measures the expected outcome. Include secondary metrics that provide context and guardrail metrics that ensure you're not causing harm elsewhere.
  5. Describe Validation Approach How will you test this hypothesis? A/B test, user interviews, prototype testing, cohort analysis? Be specific about sample size, duration, and statistical requirements.
  6. Document Risks and Assumptions What could invalidate this hypothesis beyond the test results? What are you assuming to be true that you haven't validated?
当需要创建假设时，请遵循以下步骤：
  1. 阐述核心观点 明确你认为会发生的情况。使用结构化格式：“我们认为，针对[目标用户]采取[行动/变更]将带来[预期结果]。”请具体说明干预措施——模糊的假设无法被测试。
  2. 确定目标用户 定义该假设适用的用户群体。仅针对“用户”的假设过于宽泛，请明确细分群体：注册首周的新用户、会话次数10+的核心用户、回流的流失用户等。
  3. 定义预期结果 你期望看到哪些行为变化或成果？尽可能从用户行为角度描述（完成入职流程、完成购买、7日内回访），而非仅使用内部指标。
  4. 设定成功指标 选择一个直接衡量预期结果的核心指标。同时包含提供上下文的次要指标，以及确保不会在其他方面造成负面影响的保障指标。
  5. 描述验证方法 你将如何测试该假设？A/B测试、用户访谈、原型测试、群组分析？请具体说明样本量、时长和统计要求。
  6. 记录风险与假设前提 除测试结果外，哪些因素可能推翻该假设？你有哪些未经验证的默认假设？

Output Format

输出格式

Use the template in 
references/TEMPLATE.md
to structure the output.
使用
references/TEMPLATE.md
中的模板来组织输出内容。

Quality Checklist

质量检查清单

Before finalizing, verify:
  • Hypothesis is falsifiable (possible to prove wrong)
  • Success metric has a specific numeric target
  • Target user segment is clearly defined
  • Validation approach is practical and time-bound
  • Pass/fail criteria are unambiguous
  • Hypothesis doesn't assume the solution works
最终确定前，请验证：
  • 假设可被证伪（有可能被证明是错误的）
  • 成功指标具备具体的数值目标
  • 目标用户群体定义清晰
  • 验证方法切实可行且有时间限制
  • 合格/不合格标准明确无误
  • 假设未预设解决方案有效

Examples

示例

See 
references/EXAMPLE.md
for a completed example.
可查看
references/EXAMPLE.md
获取完整示例。