AI 智慧营养健康餐厅产品发现结论包

• Date: 2026-06-15
• Workflow: pm-product-discovery 13 skills + 5 commands translated into Codex execution
• Discovery object: 企业 / 园区 / 机关智慧食堂标准包，以及支撑它复制的售前、前厅、证据链能力
• Product stage: Existing product with new-product branches
• Review status: draft for Jack review

0. 本次使用的本地 PM Product Discovery 能力

Commands used:

• /discover: 串起完整发现循环，从发散到假设、优先级、实验和发现计划。
• /brainstorm: 生成 PM / Designer / Engineer 三视角方案与实验。
• /triage-requests: 把已有需求池归类、排序、决定做/验证/暂缓。
• /interview: 生成后续客户访谈脚本和访谈归纳模板。
• /setup-metrics: 生成北极星指标、输入指标、健康指标和告警阈值。

Skills used:

• brainstorm-ideas-existing, brainstorm-ideas-new
• identify-assumptions-existing, identify-assumptions-new
• prioritize-assumptions
• brainstorm-experiments-existing, brainstorm-experiments-new
• opportunity-solution-tree
• analyze-feature-requests, prioritize-features
• interview-script, summarize-interview
• metrics-dashboard

ZHCT local guardrails used:

• Evidence levels: A/B/C/D.
• Digital business investor lens: do not frame features as value unless they improve revenue, margin, reuse, recurring service, cash flow, main-business synergy, or risk reduction.
• Output rule: Markdown is the AI-readable source of truth; this draft is not a customer-facing commitment.

1. Executive Conclusion

The strongest product-discovery conclusion is:

The next 30-60 days should not prioritize broad AI nutrition capabilities, regional SaaS expansion, or a large dashboard platform. The priority should be to prove that the enterprise / park / government smart canteen standard package can be repeatedly sold, scoped, delivered, reconciled, and reviewed with lower custom work.

The first wedge remains:

企业 / 园区 / 机关智慧食堂标准包。

The first validated value proposition should be:

One standard package for employee dining operations, subsidy and payment settlement, food-safety evidence, device linkage, and delivery acceptance evidence.

The first discovery question is:

Can we use the same standard package template in two real enterprise / government canteen opportunities, reduce quote and delivery ambiguity, and generate evidence strong enough for sales, delivery, acceptance, and renewal review?

What to do now:

1. Use 售前 intake 与交付证据治理 as the entry gate for the next real opportunity.
2. Build a manual MVP of 前厅开餐检查表.
3. Bind key capabilities to real page / API / data object / screenshot evidence.
4. Prototype 前厅异常工单闭环.
5. Normalize 统一对账中心 field definitions before building complex BI.

What not to do now:

1. Do not sell customer-facing AI nutrition promises before accuracy, failure handling, consent, and human review are defined.
2. Do not claim regional school SaaS PMF based on one or a few projects.
3. Do not treat dashboards, decorative screens, or broad platform wording as the core product.
4. Do not let customers design the feature list directly; translate requests into opportunities first.

2. Evidence Packet

3. Ideas Explored

PM Perspective

Designer Perspective

Engineer Perspective

4. Selected Ideas for Validation

5. Feature Request Triage

Priority 1: Act Now

Priority 2: Plan Next

Priority 3: Collect More Signal

Priority 4: Decline or Defer

6. Critical Assumptions

7. Assumption Priority Matrix

8. Validation Experiments

9. Opportunity Solution Tree

Desired outcome:

In 30-60 days, prove that the enterprise / park / government standard package can be repeatedly scoped, quoted, delivered, reconciled, and reviewed with less custom ambiguity.

Desired outcome
└── Prove repeatable standard-package delivery
    ├── Opportunity 1: Sales and delivery lack a shared intake gate
    │   ├── Solution A: Mandatory presales intake form
    │   ├── Solution B: Quote-blocking field completeness rule
    │   ├── Solution C: AI evidence-gap checker
    │   └── Experiments: E1, E7
    ├── Opportunity 2: Front-hall operations fail because readiness issues surface too late
    │   ├── Solution A: Opening checklist MVP
    │   ├── Solution B: Device / payment / food-safety readiness panel
    │   ├── Solution C: Role-specific pre-meal signoff
    │   └── Experiment: E2
    ├── Opportunity 3: Sales claims and delivery capabilities are not always bound to evidence
    │   ├── Solution A: Page / API / screenshot evidence matrix
    │   ├── Solution B: Demo path library
    │   ├── Solution C: Capability status labels: live / demo / planned / outsourced
    │   └── Experiment: E3
    ├── Opportunity 4: Incidents break trust when they lack owner, status, and closure evidence
    │   ├── Solution A: Manual incident concierge workflow
    │   ├── Solution B: Five incident categories and SLA table
    │   ├── Solution C: Employee-visible refund / correction progress
    │   └── Experiment: E4
    └── Opportunity 5: Finance trust depends on clear reconciliation before dashboards
        ├── Solution A: Reconciliation field dictionary
        ├── Solution B: Sample-day reconciliation walkthrough
        ├── Solution C: Difference reason codes
        └── Experiment: E5

10. Interview Plan

Research question:

In real enterprise / government smart-canteen opportunities, which operational, financial, food-safety, and delivery risks most block standard-package repeatability?

Target participants:

• 2-3 sales / presales teammates
• 2 project managers / delivery leads
• 2 canteen operators
• 1-2 finance / settlement users
• 1 food-safety or back-kitchen responsible person
• 1 customer-side leader if accessible

Core questions, following Mom Test principles:

1. Walk me through the last time a smart-canteen quote had to be revised. What triggered the revision?
2. What information was missing before quote, schedule, or deployment started?
3. Tell me about the last opening-day or meal-period issue. What happened first, who noticed it, and how was it closed?
4. What settlement or subsidy problem took the longest to explain recently?
5. Which capability in our proposal is hardest to prove with a real screen, interface, photo, or record?
6. What do you currently do manually before opening meal service?
7. What would make you confident that a standard package can be reused without major custom work?
8. What customer promise makes you uncomfortable because the evidence is not strong enough yet?
9. Which issue, if fixed, would reduce the most rework in the next project?
10. Who else should we interview before locking the standard package?

Interview summary template:

11. Metrics Dashboard

North Star:

Standard-package repeatability rate = real opportunities using the same standard-package template through intake, quote, delivery evidence, reconciliation, and review / total target opportunities in the period.

Input metrics:

Health metrics:

Business metrics to start collecting:

• Product package sales amount
• Gross margin by software / hardware / service
• Collection cycle
• Delivery labor hours
• Standard / config / custom / rejected requirement ratio
• Renewal or expansion signal
• Nutrition product or service linkage signal

12. Three-Week Discovery Timeline

Week 1:

• Run E1 intake in the next real opportunity or one realistic simulated opportunity.
• Run E2 opening checklist paper MVP.
• Start E3 evidence matrix for PC backend and front-hall settlement.
• Interview presales, delivery, operations.

Week 2:

• Continue E3 evidence matrix for mobile and food-safety loop.
• Run E4 manual incident concierge.
• Build E5 reconciliation field dictionary.
• Interview finance and food-safety roles.

Week 3:

• Finish E5 sample reconciliation walkthrough.
• Run E6 nutrition label quote-option test if target opportunity exists.
• Synthesize interviews with assumptions validated / invalidated.
• Decide build / pivot / defer for top five items.

13. Decision Framework

14. Final Product Discovery Recommendation

The discovery loop should produce one near-term build lane and three validation lanes:

Near-term build lane:

• Presales intake and delivery evidence gate
• Opening checklist MVP
• Capability evidence matrix
• Reconciliation field dictionary

Validation lanes:

• Incident closure concierge before system build
• Nutrition label paid-addon signal before health-service expansion
• Internal AI Copilot ROI before customer-facing AI promises

The standard-package product should be expressed as:

A repeatable enterprise / government smart nutrition canteen package that makes employee dining operations, subsidy settlement, food-safety evidence, device linkage, and acceptance review controllable.

The current biggest strategic risk is not lack of features. It is:

Too many capabilities are still presented as product value before they are bound to repeatable evidence, quote boundaries, delivery costs, and customer behavior.

The next product manager action is:

Take two real opportunities through the same intake, quote, evidence, delivery-risk, reconciliation, and review loop. If the loop works twice, then write the PRD and standard package. If it does not, fix the loop before adding more features.