Back to Details

feasibility-assessor

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Feasibility Assessor

可行性评估工具

Evaluate business ideas and features across two tracks: financial viability and technical feasibility. Produce an integrated verdict with actionable de-risking recommendations.
从财务可行性和技术可行性两个维度评估商业想法与功能特性，输出包含可落地风险降低建议的综合判断结论。

Phase 1: Input Classification

第一阶段：输入分类

Determine the input type:
  • Idea pitch: informal description of a concept
  • Feature spec: defined requirements for a product addition
  • Repo/codebase: existing code to evaluate for extension or pivot
  • Business plan: structured document with financials
Extract from the input:
  1. Value proposition (what problem it solves, for whom)
  2. Target customer segment
  3. Pricing intent or revenue model
  4. Technology stack (stated or implied)
  5. Competitive landscape awareness
If critical inputs are missing, ask targeted clarifying questions before proceeding. Minimum viable inputs: value proposition and target customer.
确定输入类型：
  • 创意提案：概念的非正式描述
  • 功能规格：产品新增功能的明确需求
  • 代码仓库/代码库：用于评估扩展或转型的现有代码
  • 商业计划书：包含财务数据的结构化文档
从输入中提取以下信息：
  1. 价值主张（解决什么问题，面向哪些用户）
  2. 目标客户群体
  3. 定价意向或收入模式
  4. 技术栈（明确说明或隐含的）
  5. 竞争格局认知
若关键信息缺失，先提出针对性的澄清问题再推进。最低必要输入：价值主张和目标客户。

Phase 2: Financial Analysis

第二阶段：财务分析

Reference: 
references/unit-economics.md
, 
references/financial-viability.md
Skip this phase only when the request is purely technical (e.g., "can we build X with Y stack").
参考资料：
references/unit-economics.md
、
references/financial-viability.md
仅当请求纯技术相关时（例如：“我们能否用Y技术栈构建X”），跳过本阶段。

Unit Economics

单位经济效益

  1. Calculate Customer Acquisition Cost (CAC) — fully loaded: marketing spend + sales cost + overhead allocation per acquired customer
  2. Calculate Customer Lifetime Value (LTV) — ARPU multiplied by average customer lifetime, adjusted for gross margin
  3. Compute LTV:CAC ratio — minimum viable: 3:1
  4. Determine contribution margin per unit sold or per customer served
  5. Calculate payback period — months until cumulative gross profit from a customer exceeds CAC
State every assumption explicitly. Flag assumptions with high sensitivity (small change flips the outcome).
  1. 计算客户获取成本（CAC） —— 全成本核算：营销投入+销售成本+单个获客分摊的管理费用
  2. 计算客户生命周期价值（LTV） —— 每用户平均收入（ARPU）乘以平均客户生命周期，再按毛利率调整
  3. 计算LTV:CAC比率 —— 最低可行标准：3:1
  4. 确定每单位产品或每位客户的边际贡献
  5. 计算投资回收期 —— 客户累计毛利超过CAC所需的月数
明确说明所有假设条件。标记高敏感性假设（微小变化会反转结果）。

Revenue Modeling

收入建模

  1. Identify all revenue streams and size each one
  2. Assess pricing strategy fit: cost-plus, value-based, competitive, freemium-to-paid
  3. Apply conversion rate assumptions — use industry benchmarks from reference material
  4. Model churn and retention — apply cohort decay curves where possible
  1. 识别所有收入来源并估算规模
  2. 评估定价策略适配性：成本加成定价、价值导向定价、竞争导向定价、免费转付费模式
  3. 应用转化率假设 —— 使用参考资料中的行业基准数据
  4. 建模客户流失与留存 —— 尽可能应用群组衰减曲线

Break-Even Analysis

收支平衡分析

  1. Separate fixed costs (rent, salaries, infrastructure baseline) from variable costs (COGS, transaction fees, support per user)
  2. Calculate break-even point in units, customers, or revenue
  3. Model three scenarios:
    • Pessimistic: 50th percentile conversion, high churn, slow growth
    • Base: industry-average assumptions
    • Optimistic: top-quartile performance
  1. 区分固定成本（租金、薪资、基础设施基线成本）与可变成本（销货成本、交易手续费、单用户支持成本）
  2. 计算以产品数量、客户数量或收入为单位的收支平衡点
  3. 建模三种场景：
    • 悲观场景：50分位转化率、高流失率、增长缓慢
    • 基准场景：行业平均假设
    • 乐观场景：前25分位表现

Path to Profitability

盈利路径

  1. Project gross margin trajectory over 12-24 months
  2. Model operating expense scaling (linear vs step-function vs economies of scale)
  3. Estimate funding requirements and runway at current burn
  4. Compare against industry benchmarks for time-to-profitability
  1. 预测12-24个月内的毛利率变化轨迹
  2. 建模运营费用的增长方式（线性增长、阶梯式增长、规模经济）
  3. 估算当前消耗速率下的资金需求与现金流续航时间
  4. 与行业盈利周期基准进行对比

Phase 3: Technical Analysis

第三阶段：技术分析

Reference: 
references/technical-risk.md
Skip this phase only when the request is purely financial (e.g., "are the unit economics viable for a SaaS at $29/mo").
参考资料：
references/technical-risk.md
仅当请求纯财务相关时（例如：“定价29美元/月的SaaS单位经济效益是否可行”），跳过本阶段。

Architecture Assessment

架构评估

Classify complexity:
LevelDescriptionExamples
1 — SimpleStandard CRUD, single serviceLanding page, basic CMS, form-based app
2 — ModerateMulti-service integration, auth, paymentsE-commerce, SaaS dashboard, API platform
3 — ComplexDistributed systems, real-time, high availabilityMarketplace, streaming platform, fintech
4 — NovelR&D required, unproven at scaleML-driven product, novel protocol, hardware+software
Evaluate:
  • Technology stack maturity and ecosystem support
  • Infrastructure requirements and cost scaling curve
  • Third-party dependency count and criticality
复杂度分类：
级别描述示例
1 — 简单标准CRUD、单一服务着陆页、基础CMS、表单类应用
2 — 中等多服务集成、认证、支付电商平台、SaaS仪表盘、API平台
3 — 复杂分布式系统、实时性、高可用性交易市场、流媒体平台、金融科技
4 — 创新型需要研发、未经过大规模验证ML驱动产品、新型协议、软硬件结合
评估内容：
  • 技术栈成熟度与生态支持
  • 基础设施需求与成本增长曲线
  • 第三方依赖数量与关键程度

Build Estimation

开发估算

  1. Define MVP scope — the minimum feature set that tests the core value proposition
  2. Estimate development timelines:
    • Optimistic: experienced team, known stack, minimal unknowns
    • Realistic: standard team, some learning curve, normal blockers
    • Pessimistic: new domain, integration challenges, regulatory overhead
  3. Identify required team skills and availability
  4. Run build vs buy vs partner analysis for each major component
  1. 定义MVP范围 —— 验证核心价值主张的最小功能集合
  2. 估算开发周期：
    • 乐观情况：经验丰富团队、熟悉技术栈、未知因素少
    • 现实情况：标准团队、存在学习曲线、常规障碍
    • 悲观情况：新领域、集成挑战、监管合规成本高
  3. 确定所需团队技能与人员可用性
  4. 对每个主要组件进行自研vs外购vs合作分析

Risk Scoring

风险评分

Score each dimension 1-5 (1 = low risk, 5 = critical risk):
DimensionWhat It Measures
Technical noveltyProven tech (1) vs active R&D required (5)
Integration complexitySelf-contained (1) vs many external APIs (5)
Scale readinessArchitecture handles 100x with config changes (1) vs requires re-architecture (5)
Data riskPublic/owned data, no regulation (1) vs restricted data, heavy compliance (5)
Security/complianceNo sensitive data (1) vs PCI/HIPAA/SOC2 required (5)
Composite technical risk = weighted average. Flag any dimension scoring 4+ as a blocker requiring mitigation plan.
对每个维度按1-5分评分（1=低风险，5=极高风险）：
维度衡量内容
技术创新性成熟技术（1）vs 需要主动研发（5）
集成复杂度独立系统（1）vs 依赖大量外部API（5）
扩容就绪度架构可通过配置变更支持100倍流量（1）vs 需要重构（5）
数据风险公开/自有数据、无监管要求（1）vs 受限数据、强合规要求（5）
安全与合规无敏感数据（1）vs 需要符合PCI/HIPAA/SOC2标准（5）
综合技术风险=加权平均分。标记任何评分4分及以上的维度为需要制定缓解方案的障碍。

Phase 4: Integrated Feasibility Score

第四阶段：综合可行性评分

Financial Viability

财务可行性

  • Viable: LTV:CAC > 3:1, payback < 18 months, clear path to positive unit economics
  • Risky: LTV:CAC 1.5-3:1, payback 18-36 months, unit economics depend on scale
  • Not viable: LTV:CAC < 1.5:1, payback > 36 months, negative contribution margin
  • 可行：LTV:CAC > 3:1，投资回收期 < 18个月，单位经济效益明确可转正
  • 有风险：LTV:CAC 1.5-3:1，投资回收期18-36个月，单位经济效益依赖规模增长
  • 不可行：LTV:CAC < 1.5:1，投资回收期 > 36个月，边际贡献为负

Technical Feasibility

技术可行性

  • Straightforward: complexity level 1-2, all risk dimensions < 3
  • Challenging: complexity level 2-3, one or two dimensions at 3-4
  • High-risk: complexity level 3-4, multiple dimensions at 4+
  • Research-grade: complexity level 4, any dimension at 5
  • 简单直接：复杂度级别1-2，所有风险维度评分<3
  • 具有挑战：复杂度级别2-3，1-2个维度评分3-4
  • 高风险：复杂度级别3-4，多个维度评分4+
  • 研发级：复杂度级别4，任意维度评分5

Overall Verdict

总体结论

FinancialTechnicalVerdict
ViableStraightforwardGreen — proceed
ViableChallengingYellow — proceed with caution, mitigate tech risks
RiskyStraightforwardYellow — validate financial assumptions first
RiskyChallengingYellow — high uncertainty, run cheap experiments
Not viableAnyRed — reconsider fundamentals
AnyHigh-risk/ResearchRed — reduce technical unknowns before committing
财务状态技术状态结论
可行简单直接绿色 —— 推进项目
可行具有挑战黄色 —— 谨慎推进，缓解技术风险
有风险简单直接黄色 —— 先验证财务假设
有风险具有挑战黄色 —— 高度不确定，开展低成本实验
不可行任意红色 —— 重新审视核心逻辑
任意高风险/研发级红色 —— 降低技术不确定性后再做决策

Assumption Sensitivity

假设敏感性分析

Identify the top 3-5 assumptions that most influence the verdict. For each, state:
  • Current assumed value
  • Threshold value that would flip the assessment
  • How to validate cheaply
找出对结论影响最大的3-5个假设。针对每个假设说明：
  • 当前假设值
  • 会反转评估结果的阈值
  • 低成本验证方法

De-risking Recommendations

风险降低建议

Rank experiments by cost-to-run vs information-value. Prioritize experiments that validate the riskiest assumptions at the lowest cost.
按成本投入vs信息价值排序实验优先级。优先选择能以最低成本验证最高风险假设的实验。

Phase 5: Report Generation

第五阶段：报告生成

Structure the output as:
输出结构如下：

Executive Summary

执行摘要

  • One-paragraph verdict with go/no-go signal
  • Top 3 risks and top 3 strengths
  • 一段式结论，包含是否推进的明确信号
  • 前3大风险与前3大优势

Financial Dashboard (if applicable)

财务仪表盘（如适用）

  • Unit economics table: CAC, LTV, LTV:CAC, contribution margin, payback period
  • Revenue projection under 3 scenarios (table or description)
  • Break-even point and timeline
  • 单位经济效益表格：CAC、LTV、LTV:CAC、边际贡献、投资回收期
  • 三种场景下的收入预测（表格或文字描述）
  • 收支平衡点与时间线

Technical Scorecard (if applicable)

技术评分卡（如适用）

  • Complexity classification
  • Risk dimension scores (table)
  • MVP scope and timeline estimate
  • Critical dependencies and mitigation
  • 复杂度分类
  • 风险维度评分表
  • MVP范围与周期估算
  • 关键依赖与缓解方案

Sensitivity Analysis

敏感性分析

  • Which assumptions, if wrong, flip the verdict
  • Threshold values for each critical assumption
  • 哪些假设出错会反转结论
  • 每个关键假设的阈值

Recommended Next Steps

建议下一步行动

  • Ordered list of actions, cheapest validation first
  • Clear owners or skill requirements for each step
  • Decision gates: what evidence triggers proceed vs pivot vs stop
  • 按优先级排序的行动列表，从成本最低的验证开始
  • 每个步骤的明确负责人或技能要求
  • 决策节点：哪些证据会触发推进、转型或终止决策