Back to Details

business-product-leadership

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Business & Product Leadership

业务与产品领导力

This skill bridges the gap between Business Strategy and Technical Execution. It is designed for Product Owners and Founders who manage both the business viability and the product delivery.
本技能衔接了业务战略与技术执行，专为同时管理业务可行性和产品交付的产品负责人与创始人设计。

📈 1. Business Strategy & Discovery

📈 1. 业务战略与探索

Product Market Research & Market Fit

产品市场调研与市场契合度

Before building anything, validate market demand for the product you intend to create.
  • Identify the Problem: What specific pain point or unmet need does your product solve?
  • Competitor Analysis: Who else is solving this problem? How can you differentiate (Price, Speed, Quality, UX)?
  • Target Segment: Who is your ideal early user, and what triggers them to seek a solution?
  • Validation Methods: Customer interviews, landing page tests, smoke tests — validate demand before writing production code.
在开始任何开发前，先验证你计划打造的产品的市场需求。
  • 明确问题： 你的产品解决了哪些具体的痛点或未被满足的需求？
  • 竞品分析： 还有哪些主体在解决这个问题？你如何实现差异化（价格、速度、质量、用户体验）？
  • 目标细分群体： 你的理想早期用户是谁？是什么触发他们寻求解决方案？
  • 验证方法： 用户访谈、着陆页测试、烟雾测试——在编写生产代码前先验证需求。

Jobs-To-Be-Done (JTBD) Framework

Jobs-To-Be-Done（JTBD）框架

People don't buy products; they "hire" them to get a job done.
  • The JTBD Statement: "When [Situation], I want to [Motivation], so I can [Expected Outcome]."
  • Example: "When I am commuting, I want to listen to educational content easily, so I can feel productive."
  • Focus: Build features that directly solve the core Job, not just what users say they want.
人们购买产品并非为了拥有产品，而是“雇佣”产品来完成某项工作。
  • JTBD陈述模板： “当[场景]时，我想要[动机]，这样我就能[预期结果]。”
  • 示例： “当我通勤时，我希望能轻松收听教育内容，这样我就能感觉高效。”
  • 核心要点： 打造直接解决核心“待完成工作”的功能，而非仅仅满足用户“口头表达”的需求。

Diffusion of Innovations (Rogers, 1962)

创新扩散理论（Rogers，1962）

Understanding how your product spreads through the market determines your release and feature strategy.
Innovators   Early       Early        Late         Laggards
  2.5%      Adopters    Majority     Majority       16%
            13.5%        34%          34%
    |_________|___________|____________|______________|
              ^           ^
           Target       "The Chasm"
           for MVP      (Geoffrey Moore)
Adopter Segments:
SegmentMindsetWhat they need from you
InnovatorsRisk-tolerant, tech-firstAccess, raw capability
Early AdoptersVision-driven, influentialReference story, competitive edge
Early MajorityPragmatic, wait-and-seeProven ROI, whole product
Late MajoritySkeptical, price-sensitiveStandards, support, herd behavior
LaggardsTradition-boundForced adoption or irrelevance
The Chasm (Moore): Gap between Early Adopters and Early Majority is where most products die. Early Adopters accept rough edges; Early Majority demands a complete solution.
Strategic Implications:
  • MVP → target Early Adopters first. They tolerate incomplete products if the core Job is solved.
  • Cross the Chasm by dominating one niche vertical completely (beachhead strategy) before expanding.
  • Feature flags + phased Release align directly with the adoption curve: Innovators → Early Adopters → controlled rollout to Majority.
  • Do not build for Late Majority features until Early Majority is retained.
  • For active release tracking and Go/No-Go decisions per rollout phase, use the 
    diffusion-release-tracking
    skill.
理解产品在市场中的传播方式，将决定你的发布和功能策略。
Innovators   Early       Early        Late         Laggards
  2.5%      Adopters    Majority     Majority       16%
            13.5%        34%          34%
    |_________|___________|____________|______________|
              ^           ^
           Target       "The Chasm"
           for MVP      (Geoffrey Moore)
用户群体细分：
群体思维模式他们对你的需求
创新者敢于冒险，技术优先产品使用权、核心功能
早期采用者愿景驱动，具有影响力参考案例、竞争优势
早期大众务实，观望态度已验证的投资回报率、完整产品
晚期大众多疑，价格敏感标准化、支持服务、从众心理
落后者固守传统被迫采用或被淘汰
鸿沟（Moore提出）： 早期采用者与早期大众之间的差距是大多数产品失败的地方。早期采用者可以接受产品的不完善；而早期大众则要求完整的解决方案。
战略启示：
  • MVP → 首先瞄准早期采用者。如果核心待完成工作得到解决，他们可以接受产品的不完整。
  • 跨越鸿沟：在扩张前，先完全主导一个垂直细分领域（滩头阵地战略）。
  • 功能开关 + 分阶段发布 直接契合用户采用曲线：创新者 → 早期采用者 → 向大众可控推送。
  • 在留住早期大众前，不要为晚期大众打造功能。
  • 如需进行活跃发布跟踪，并在每个推送阶段做出上线/不上线决策，请使用
    diffusion-release-tracking
    技能。

🏗 2. Product Architecture (DDD Integration)

🏗 2. 产品架构（DDD集成）

Connect your business findings to technical design using Domain-Driven Design (DDD).
  • Core Domain: Map the core Job-To-Be-Done directly to your DDD Core Domain. This is where you invest the most engineering effort.
  • Generic Subdomains: If a feature doesn't directly serve the unique JTBD (e.g., User Authentication), treat it as a Generic Subdomain. Buy or use SaaS; do not build from scratch.
  • Event Storming: Use the JTBD outcomes to define the key Domain Events in your system.
使用**领域驱动设计（DDD）**将业务洞察与技术设计关联起来。
  • 核心领域： 将核心的“待完成工作”直接映射到DDD的核心领域。这是你投入最多工程资源的地方。
  • 通用子领域： 如果某项功能不直接服务于独特的JTBD（例如用户认证），则将其视为通用子领域。购买或使用SaaS服务；不要从零开始构建。
  • 事件风暴： 利用JTBD的预期结果来定义系统中的关键领域事件。

🚀 3. Agile Delivery: Ship != Release

🚀 3. 敏捷交付：Ship ≠ Release

To achieve a fast time-to-market (MVP) and reduce risk, strictly separate technical deployment from business launch.
为了实现快速上市（MVP）并降低风险，严格区分技术部署与业务发布。

"Ship" (Technical Action)

“Ship”（技术操作）

  • Pushing code to the production environment.
  • Code is hidden behind Feature Flags or available only to internal testers (Dark Launching).
  • Goal: Continuous Integration without business risk.
  • 将代码推送至生产环境。
  • 代码被隐藏在功能开关后，或仅对内部测试人员开放（暗发布）。
  • 目标：无业务风险的持续集成。

"Release" (Business Action)

“Release”（业务操作）

  • Turning on the Feature Flag for actual users.
  • Can be phased (Canary release: 5% of users -> 20% -> 100%).
  • Tied to marketing campaigns and business readiness.
  • Goal: Deliver value when the market is ready.
  • 为实际用户开启功能开关。
  • 可分阶段进行（金丝雀发布：5%用户 → 20% → 100%）。
  • 与营销活动和业务准备情况挂钩。
  • 目标：在市场准备就绪时交付价值。

🧠 4. Grounded Reasoning: NotebookLM Integration

🧠 4. 基于事实的推理：NotebookLM集成

To ensure technical execution stays aligned with high-level strategy, follow a Grounded Reasoning approach when working alongside NotebookLM.
为确保技术执行与高层战略保持一致，在与NotebookLM协作时，遵循基于事实的推理方法。

Workflow

工作流程

  1. Context Request: Before major technical decisions, prompt the user: "Please provide the latest strategic context or JTBD summary from your NotebookLM for this feature."
  2. Synthesis: User provides context (via copy-paste or summary).
  3. Validation: Evaluate the current C4/DDD design against the provided business evidence.
  1. 请求上下文： 在做出重大技术决策前，向用户提示：“请提供你NotebookLM中最新的战略背景或JTBD摘要，用于此功能开发。”
  2. 信息整合： 用户提供上下文（通过复制粘贴或摘要）。
  3. 验证： 根据提供的业务证据，评估当前的C4/DDD设计。

Rule

规则

MANDATORY: Always prioritize business constraints and Jobs provided by the user from their research notebooks over generic assumptions. If a technical design conflicts with the user's provided strategy, flag it as a Strategic Risk.
强制性要求： 始终优先考虑用户从其研究笔记中提供的业务约束和待完成工作，而非通用假设。如果技术设计与用户提供的战略冲突，需将其标记为战略风险。

🎯 The MVP Playbook

🎯 MVP实操指南

  1. Define the primary JTBD.
  2. Identify the Core Domain required to solve that JTBD.
  3. Design the architecture using C4 Level 1 & 2, mocking or buying Generic Subdomains.
  4. Ship the core feature behind a flag.
  5. Release to a small Early Adopter cohort to validate the market hypothesis and gather adoption signal before crossing the Chasm.
  1. 定义核心JTBD。
  2. 确定解决该JTBD所需的核心领域。
  3. 使用C4 Level 1 & 2设计架构，对通用子领域进行模拟或采购。
  4. 将核心功能通过功能开关Ship到生产环境。
  5. 向一小群早期采用者Release，以验证市场假设并收集采用信号，再跨越鸿沟。