Back to Details

commercial-solution-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Commercial Solution Design

商业解决方案设计

Purpose

用途

Bridge the gap between discovery (understanding the problem) and proposal (presenting the offer). Create a credible, high-level solution architecture that demonstrates technical competence and gives the prospect confidence that we understand their problem AND know how to solve it.
This is NOT a detailed project plan — it is a pre-sale solution sketch at the right level of detail to win trust and inform pricing.
衔接需求调研（理解问题）和提案（展示服务方案）之间的鸿沟。创建可信的高层解决方案架构，展现技术能力，让潜在客户相信我们既理解他们的问题，也知道如何解决问题。
这不是详细的项目计划——它是一份售前解决方案草图，其细节程度刚好足以赢得客户信任并为定价提供参考。

Key Distinction

核心区别

  • This is a PRE-SALE artifact, not a project plan.
  • Level of detail: enough to be credible and priceable, not enough to execute.
  • The detailed project plan comes AFTER the deal closes, via 
    project-planning
    skill.
  • Think of this as the "lite version" of 
    project-intake-and-charter
    + 
    project-planning
    , designed to win the deal.
  • 这是售前产出物，而非项目计划。
  • 细节程度：足够可信、可用于定价，但不足以支撑落地执行。
  • 详细项目计划会在交易达成后通过
    project-planning
    skill产出。
  • 你可以把它看作是
    project-intake-and-charter
    + 
    project-planning
    的「精简版」，核心目的是拿下项目。

Scope

适用范围

  • This skill WILL:
    • Map discovered pain points to consulting service categories and solution patterns
    • Design a high-level solution architecture with technology recommendations
    • Define a phased delivery roadmap with effort ranges per phase
    • Specify team composition and seniority mix
    • Identify risks, dependencies, assumptions, and success criteria
    • Recommend an engagement model (T&M / Fixed-Price / Outcome-Based / Hybrid)
    • Produce a 
      solution-brief.md
      per opportunity
  • This skill WILL NOT:
    • Produce detailed technical designs or implementation specs
    • Create detailed project plans, WBS, or schedules (that is 
      project-planning
      )
    • Make pricing decisions (that is 
      commercial-proposal-writer
      )
    • Execute technical work
  • 本技能支持的操作：
    • 将已发现的痛点匹配到咨询服务分类和解决方案模式
    • 设计高层解决方案架构并给出技术建议
    • 定义分阶段交付路线图，标注每个阶段的工作量范围
    • 明确团队构成和职级配比
    • 识别风险、依赖项、假设前提和成功标准
    • 建议合作模式（T&M/固定价格/按效果付费/混合模式）
    • 为每个商机产出
       solution-brief.md
      文件
  • 本技能不支持的操作：
    • 产出详细技术设计或落地实现规范
    • 创建详细项目计划、WBS或进度安排（对应
      project-planning
      技能）
    • 做出定价决策（对应
      commercial-proposal-writer
      技能）
    • 执行具体技术工作

Inputs

输入项

  • discovery-notes.md
     — from 
    commercial-discovery
    (primary source of pain points and context)
  • qualification-scorecard.md
     — from 
    commercial-qualification
    (validates opportunity quality, fit, and branch)
  • discovery-proposal-deliverables.md
     (Branch B only) — outputs from a completed Strategic Discovery engagement. When present, this is the PRIMARY input and overrides discovery-notes as the source of truth for architecture, risks, and estimation. Estimation accuracy improves to +/- 20% or better.
  • commercial-state.md
     — current pipeline context
  • user_input
     — technical constraints, preferences, capacity, or additional context
Branch context note: When the qualification scorecard shows 
branch: B
and a linked Discovery opportunity is 
closed_won
, the solution-design is for the implementation opportunity following the Discovery. In this case, estimation carries lower uncertainty — target +/- 20% instead of the standard +/- 30%, and Phase 0 (Assessment) may be shortened or skipped if Discovery already covered it.
  • discovery-notes.md
     — 来自
    commercial-discovery
    （痛点和上下文的核心来源）
  • qualification-scorecard.md
     — 来自
    commercial-qualification
    （验证商机质量、匹配度和分支）
  • discovery-proposal-deliverables.md
     (仅B分支) — 已完成的战略调研咨询项目产出。当该文件存在时，它是核心输入项，优先级高于discovery-notes，是架构、风险和估算的可信来源，估算准确率可提升至±20%甚至更高。
  • commercial-state.md
     — 当前商机管道上下文
  • user_input
     — 技术约束、偏好、产能或其他补充上下文
分支上下文说明：当资质打分卡显示
branch: B
且关联的调研商机已「成交赢单」时，本次方案设计对应调研结束后的落地实施商机。该场景下估算的不确定性更低——目标误差为±20%而非标准的±30%，如果调研阶段已经覆盖了相关内容，第0阶段（评估）可以缩短甚至跳过。

Solution Design Principles

方案设计原则

  1. Start with business outcomes, map backward to technical requirements.
  2. Phase 0 (Assessment/Quick Wins) is mandatory — it reduces risk for both sides and demonstrates value early.
  3. Prefer proven technologies over cutting-edge unless the client specifically needs innovation.
  4. Always include knowledge transfer — consulting should make the client MORE capable, not dependent.
  5. Right-size the team — resist the urge to over-staff for revenue; a lean, senior team builds more trust.
  6. Make assumptions explicit — every uncertain element must be stated as an assumption, not a fact.
  1. 以业务结果为起点，反向推导技术需求。
  2. 第0阶段（评估/快速见效）是强制项——它能降低双方风险，尽早展现价值。
  3. 优先选择成熟技术而非前沿技术，除非客户明确要求创新。
  4. 始终包含知识转移——咨询服务应该提升客户的能力，而非让客户产生依赖。
  5. 团队规模要适配需求——不要为了营收过度配置人员；精简的高阶团队更容易建立信任。
  6. 明确说明假设前提：所有不确定的内容都必须标注为假设，而非事实。

Workflow

工作流程

1. Analyze Inputs

1. 分析输入项

Review discovery notes, qualification scorecard, and pipeline context. Identify:
  • Primary pain points and their business impact
  • Client's technical maturity level
  • Constraints (timeline, budget, team, compliance)
  • Decision criteria and stakeholder concerns
审阅调研笔记、资质打分卡和商机管道上下文，识别：
  • 核心痛点及其业务影响
  • 客户的技术成熟度水平
  • 约束条件（时间线、预算、团队、合规要求）
  • 决策标准和利益相关者的顾虑

2. Map Pain Points to Solution Patterns

2. 将痛点匹配到解决方案模式

For each pain point from discovery, identify the applicable consulting solution pattern. Consult 
references/solution-patterns.md
for common patterns across Software Engineering, Data Platforms, and AI/ML domains. Each pattern includes typical phases, team composition, risks, and engagement model guidance.
针对调研发现的每个痛点，匹配适用的咨询解决方案模式。参考
references/solution-patterns.md
查看软件工程、数据平台、AI/ML领域的通用模式，每个模式都包含典型阶段、团队构成、风险和合作模式指引。

3. Design Solution Architecture

3. 设计解决方案架构

For each solution component, document:
  • Current State: where the prospect is today (from discovery)
  • Target State: where they need to be (derived from pain + objectives)
  • Key Components: major architectural elements (described in text/ASCII, not visual)
  • Technology Recommendations: suggested stack with rationale (not vendor-locked unless required)
  • Integration Points: connections to existing client systems
  • Risks & Assumptions: technical risks specific to this component
为每个解决方案组件记录以下内容：
  • 当前状态：潜在客户的现状（来自调研）
  • 目标状态：客户需要达到的状态（从痛点和目标推导）
  • 核心组件：主要架构元素（用文本/ASCII描述，无需可视化）
  • 技术建议：推荐的技术栈及合理性说明（除非有要求，否则不绑定特定厂商）
  • 集成点：与客户现有系统的连接方式
  • 风险与假设：该组件对应的特定技术风险

4. Define Phased Roadmap

4. 定义分阶段路线图

Structure delivery in consulting-appropriate phases:
  • Phase 0 — Assessment / Quick Wins (2-4 weeks): Mandatory. Detailed technical discovery, stakeholder interviews, current state documentation, quick wins to demonstrate value. Clear deliverable: assessment report + detailed recommendation.
  • Phase 1 — Foundation / MVP (duration varies): Core infrastructure or architecture setup, visible early wins, working foundation.
  • Phase 2 — Build-out / Scale (duration varies): Main solution delivery, iterative development with regular demos.
  • Phase 3 — Optimization / Handoff (duration varies): Performance optimization, documentation, team training, transition to internal team or support model.
Each phase must include: objectives, key deliverables, dependencies, and estimated effort (person-weeks range).
Every phase must have a clear "done" criteria that could serve as a natural exit point.
Not all phases apply to every engagement. Adjust based on scope and complexity.
按照咨询项目的适配阶段结构拆分交付：
  • 第0阶段 — 评估/快速见效（2-4周）：强制项。详细技术调研、利益相关者访谈、当前状态文档梳理、可快速见效的小成果证明价值。明确产出：评估报告 + 详细建议。
  • 第1阶段 — 基础搭建/MVP（时长不定）：核心基础设施或架构搭建，可见的早期成果，可用的基础底座。
  • 第2阶段 — 功能搭建/扩展（时长不定）：核心解决方案交付，迭代开发+定期演示。
  • 第3阶段 — 优化/交接（时长不定）：性能优化、文档交付、团队培训、过渡到客户内部团队或支持模式。
每个阶段必须包含：目标、核心产出、依赖项、估算工作量（人周范围）。 每个阶段必须有明确的「完成标准」，可作为自然退出节点。
不是所有项目都需要所有阶段，可根据范围和复杂度调整。

5. Specify Team Composition

5. 明确团队构成

Define the consulting team:
  • Roles needed (Tech Lead, Sr. Engineer, Data Engineer, ML Engineer, PM, etc.)
  • Seniority mix (% senior vs. mid vs. junior)
  • Client-side resources needed (data access owners, subject matter experts, decision-makers)
  • Knowledge transfer plan (how the client team ramps up)
定义咨询团队配置：
  • 所需角色（技术负责人、高级工程师、数据工程师、ML工程师、项目经理等）
  • 职级配比（高级/中级/初级占比）
  • 所需客户侧资源（数据权限负责人、领域专家、决策人）
  • 知识转移计划（客户团队能力提升的方式）

6. Estimate Effort

6. 估算工作量

Produce preliminary estimates as ranges using the three-point method:
  • Per phase: person-weeks expressed as optimistic-realistic-pessimistic range
  • Total engagement: aggregate range
  • Key assumptions: factors that drive the estimate up or down
Consult 
references/estimation-guide.md
for benchmarks by service type and estimation methodology.
Estimation accuracy by context:
  • Standard (discovery notes only): estimates carry +/- 30% accuracy. Communicate this explicitly.
  • Post-Discovery (Branch B, Discovery deliverables available): estimates carry +/- 20% accuracy. Note that a completed Discovery is the source of the improved confidence.
使用三点法给出初步估算范围：
  • 按阶段：人周，格式为乐观-中性-悲观范围
  • 项目总工作量：汇总范围
  • 核心假设：影响估算上下浮动的因素
参考
references/estimation-guide.md
查看不同服务类型的基准值和估算方法论。
不同场景下的估算准确率：
  • 标准场景（仅调研笔记）：估算误差为±30%，需明确告知客户。
  • 调研后场景（B分支，有调研交付物）：估算误差为±20%，需说明准确率提升是因为已完成前期调研。

7. Assess Risks & Dependencies

7. 评估风险与依赖项

Identify:
  • Technical risks specific to this solution
  • Client dependencies (data access, environments, stakeholder availability)
  • Assumptions that could change the scope
  • Capability gaps requiring partnering or subcontracting
识别：
  • 该方案对应的特定技术风险
  • 客户侧依赖项（数据权限、环境、利益相关者可用时间）
  • 可能改变范围的假设前提
  • 需要合作或外包的能力缺口

8. Recommend Engagement Model

8. 建议合作模式

Select and justify: T&M / Fixed-Price / Outcome-Based / Hybrid.
General guidance:
  • T&M: when scope is exploratory or likely to evolve
  • Fixed-Price: when scope is well-defined and bounded
  • Outcome-Based: when measurable business KPIs can be tied to delivery
  • Hybrid: Phase 0 T&M + subsequent phases fixed or outcome-based
选择并说明合理性：T&M/固定价格/按效果付费/混合模式。
通用指引：
  • T&M：适用范围是探索性的、可能发生变化的项目
  • 固定价格：适用范围明确、边界清晰的项目
  • 按效果付费：适用可将可衡量的业务KPI与交付绑定的项目
  • 混合模式：第0阶段T&M + 后续阶段固定价格/按效果付费

Outputs (Contract)

产出物（契约）

Output 1: 
solution-brief.md

产出物1: 
solution-brief.md

Per opportunity. Structure:
markdown
undefined
每个商机对应一份，结构如下：
markdown
undefined

Solution Brief: {Company Name} — {Opportunity Name}

Solution Brief: {Company Name} — {Opportunity Name}

Executive Summary

Executive Summary

[2-3 paragraphs, business-language, no jargon. State the problem, proposed approach, expected outcomes, and engagement scope.]
[2-3 paragraphs, business-language, no jargon. State the problem, proposed approach, expected outcomes, and engagement scope.]

Current State Assessment

Current State Assessment

[From discovery, structured as problems + impacts]
#ProblemBusiness ImpactPriority
1High/Med/Low
[From discovery, structured as problems + impacts]
#ProblemBusiness ImpactPriority
1High/Med/Low

Proposed Solution Architecture

Proposed Solution Architecture

Architecture Overview

Architecture Overview

[High-level architecture described in text/ASCII — components, data flows, integrations]
[High-level architecture described in text/ASCII — components, data flows, integrations]

Technology Recommendations

Technology Recommendations

ComponentRecommended TechnologyRationale
ComponentRecommended TechnologyRationale

Integration Points

Integration Points

  • [Integration with existing client system 1]
  • [Integration with existing client system 2]
  • [Integration with existing client system 1]
  • [Integration with existing client system 2]

Phased Roadmap

Phased Roadmap

Phase 0: Assessment / Quick Wins (X weeks)

Phase 0: Assessment / Quick Wins (X weeks)

  • Objectives: [what this phase achieves]
  • Key Deliverables: [tangible outputs]
  • Dependencies: [what must be true or available]
  • Estimated Effort: X-Y person-weeks (optimistic-realistic-pessimistic)
  • Done Criteria: [clear exit point]
  • Objectives: [what this phase achieves]
  • Key Deliverables: [tangible outputs]
  • Dependencies: [what must be true or available]
  • Estimated Effort: X-Y person-weeks (optimistic-realistic-pessimistic)
  • Done Criteria: [clear exit point]

Phase 1: Foundation / MVP (X weeks)

Phase 1: Foundation / MVP (X weeks)

[same structure]
[same structure]

Phase 2: Build-out / Scale (X weeks)

Phase 2: Build-out / Scale (X weeks)

[same structure]
[same structure]

Phase 3: Optimization / Handoff (X weeks)

Phase 3: Optimization / Handoff (X weeks)

[same structure]
[same structure]

Team Composition

Team Composition

RoleSeniorityAllocationPhasesResponsibilities
Seniority Mix: X% Senior / Y% Mid / Z% Junior Client-Side Resources Needed: [roles, availability] Knowledge Transfer Plan: [approach]
RoleSeniorityAllocationPhasesResponsibilities
Seniority Mix: X% Senior / Y% Mid / Z% Junior Client-Side Resources Needed: [roles, availability] Knowledge Transfer Plan: [approach]

Preliminary Effort Estimation

Preliminary Effort Estimation

PhaseDurationEffort (person-weeks)Confidence
Phase 0X weeksO / R / PMedium
Phase 1X weeksO / R / PLow
Phase 2X weeksO / R / PLow
Phase 3X weeksO / R / PLow
TotalX weeksO / R / P
Key Assumptions Driving the Estimate:
  1. [Assumption 1]
  2. [Assumption 2]
PhaseDurationEffort (person-weeks)Confidence
Phase 0X weeksO / R / PMedium
Phase 1X weeksO / R / PLow
Phase 2X weeksO / R / PLow
Phase 3X weeksO / R / PLow
TotalX weeksO / R / P
Key Assumptions Driving the Estimate:
  1. [Assumption 1]
  2. [Assumption 2]

Risks & Dependencies

Risks & Dependencies

Technical Risks

Technical Risks

RiskProbabilityImpactMitigation
RiskProbabilityImpactMitigation

Client Dependencies

Client Dependencies

  • [Data access / environments / stakeholder availability]
  • [Data access / environments / stakeholder availability]

Scope-Changing Assumptions

Scope-Changing Assumptions

  • [Assumptions that, if wrong, materially change the engagement]
  • [Assumptions that, if wrong, materially change the engagement]

Success Criteria

Success Criteria

[Measurable, tied back to discovery pain points]
  • Criterion 1
  • Criterion 2
[Measurable, tied back to discovery pain points]
  • Criterion 1
  • Criterion 2

Recommended Engagement Model

Recommended Engagement Model

[T&M / Fixed-Price / Outcome-Based / Hybrid — with rationale]
Pre-sale artifact — subject to detailed discovery post-engagement. Estimates ±30%.
undefined
[T&M / Fixed-Price / Outcome-Based / Hybrid — with rationale]
Pre-sale artifact — subject to detailed discovery post-engagement. Estimates ±30%.
undefined

Output 2: Updated 
commercial-state.md

产出物2: 已更新的
commercial-state.md

Move opportunity to 
solution
stage. Update with:
  • Reference to the solution brief
  • Estimated engagement value based on effort sizing
  • Next action: review solution brief with prospect
将商机移动到「方案」阶段，更新以下内容：
  • 关联方案简报的引用
  • 基于工作量估算的项目预期价值
  • 下一步动作：与潜在客户评审方案简报

Guardrails

注意事项

  1. Never present as a final design — clearly label as "pre-sale, subject to detailed discovery post-engagement."
  2. Effort estimates must be ranges (±30% is acceptable at this stage), never point estimates.
  3. Technology recommendations must include rationale, not just preference.
  4. Always identify what the CLIENT must provide (data, access, people, decisions).
  5. If the solution requires capabilities outside our expertise, flag it and suggest partnering/subcontracting.
  6. Do not over-engineer — match solution complexity to client maturity level.
  7. Every phase must have a clear "done" criteria that could serve as a natural exit point.
  1. 绝对不要将其作为最终设计呈现——明确标注为「售前产出物，项目启动后需经过详细调研确认」。
  2. 工作量估算必须是范围值（该阶段±30%的误差是可接受的），绝对不要给出固定数值估算。
  3. 技术建议必须包含合理性说明，不能仅基于偏好。
  4. 始终明确说明客户需要提供的资源（数据、权限、人员、决策）。
  5. 如果方案需要超出我们能力范围的技能，要明确标注并建议合作/外包。
  6. 不要过度设计——方案复杂度要匹配客户的成熟度水平。
  7. 每个阶段必须有明确的「完成标准」，可作为自然退出节点。

Example

示例

Scenario: MedTech Corp, mid-size healthcare company. Discovery revealed: legacy SQL Server data warehouse (10+ years old) struggling with performance, no self-service analytics, reports take days to produce manually, data quality issues causing compliance risk. Qualification score: 4.2/5 — Pursue.
Solution Brief Executive Summary (excerpt):
MedTech Corp's reporting infrastructure, built on a legacy SQL Server data warehouse over a decade ago, no longer meets the organization's growing analytics and compliance needs. Manual report generation consumes significant analyst time, data quality gaps create compliance exposure, and the current architecture cannot scale to support self-service analytics demanded by business units.
We propose a phased data platform modernization engagement that migrates MedTech's analytical workloads to a cloud-based data platform with a modern analytics layer. The approach prioritizes quick wins in data quality and automated reporting (Phase 0-1) before tackling the full platform migration (Phase 2), ensuring early value delivery while managing risk.
The engagement spans approximately 20-28 weeks with a team of 3-4 consultants, producing a modern, governed data platform with self-service analytics capabilities and a fully enabled internal team.
Phase 0: Assessment / Quick Wins (excerpt):
  • Objectives: Validate data landscape, identify critical data quality issues, deliver 2-3 automated reports to replace highest-pain manual processes.
  • Key Deliverables: Data landscape assessment report, data quality audit, 2-3 automated reports, detailed Phase 1-3 plan.
  • Dependencies: Access to SQL Server environment, availability of lead data analyst for interviews, sample compliance reporting requirements.
  • Estimated Effort: 2-3 person-weeks (optimistic: 2 / realistic: 2.5 / pessimistic: 3).
  • Done Criteria: Assessment report delivered and reviewed, automated reports operational, Phase 1 plan approved.
场景：MedTech Corp是中型医疗企业，调研发现：已有10多年历史的 legacy SQL Server数据仓库性能拉胯，没有自助分析能力，报表需要手动制作数天，数据质量问题带来合规风险。资质得分：4.2/5 — 跟进。
方案简报执行摘要（节选）：
MedTech Corp的报表基础设施基于已有十年以上历史的legacy SQL Server数据仓库搭建，已经无法满足企业不断增长的分析和合规需求。手动生成报表消耗了分析师大量时间，数据质量缺口带来合规风险，当前架构无法扩展支持业务部门要求的自助分析能力。
我们建议采用分阶段的数据平台现代化项目，将MedTech的分析工作负载迁移到云原生数据平台，搭配现代化分析层。该方案优先在数据质量和自动化报表方向实现快速见效（第0-1阶段），再推进全平台迁移（第2阶段），在管控风险的同时确保尽早交付价值。
项目总时长约20-28周，配置3-4名顾问，最终交付具备自助分析能力、管控完善的现代数据平台，同时完成客户内部团队的能力赋能。
第0阶段：评估/快速见效（节选）：
  • 目标：验证数据全景，识别核心数据质量问题，交付2-3份自动化报表替换痛点最高的手动流程。
  • 核心产出物：数据全景评估报告、数据质量审计报告、2-3份自动化报表、详细的第1-3阶段计划。
  • 依赖项：SQL Server环境访问权限、首席数据分析师可配合访谈、合规报表需求样本。
  • 估算工作量：2-3人周（乐观：2 / 中性：2.5 / 悲观：3）。
  • 完成标准：交付并评审通过评估报告、自动化报表上线运行、第1阶段计划获批。