Chọn đúng thứ cần xây và nói rõ vì sao

Goal Cascade giữ team khỏi tối ưu local metric. Business Goal cho biết kết quả doanh nghiệp; Product Goal mô tả trạng thái sản phẩm/người dùng; Outcome là thay đổi hành vi; Initiative là hướng can thiệp; feature là option cụ thể. Với LinguaFlow, nếu goal là tăng subscription bền vững, outcome có thể là tăng số người hoàn thành ba buổi học có giá trị trong tuần đầu, còn streak chỉ là một solution candidate.

• Mỗi tầng phải có quan hệ nhân quả giả định rõ, không chỉ nối bằng mũi tên.
• Đặt metric và baseline ở tầng outcome; feature completion không chứng minh value.
• Guardrail ngăn team tăng completion bằng bài quá dễ hoặc notification gây khó chịu.
• Một Product Goal tạo focus; quá nhiều goal đồng thời biến backlog thành danh sách mong muốn.
• Ghi assumption trong chuỗi để biết mắt xích nào cần experiment trước.

BUSINESS GOAL
- Result / baseline / target / horizon:

PRODUCT GOAL
- Customer state we want:
- Success measure:

OUTCOME
- Behavior change:
- Leading indicator:
- Guardrail:

INITIATIVES (problem spaces)
1.
2.

SOLUTION OPTIONS
- Option A:
- Option B:

CAUSAL ASSUMPTION
Nếu ______ thì ______ vì ______.
Evidence/confidence:

Opportunity Solution Tree giữ discovery liên tục: desired outcome ở gốc, customer opportunities bên dưới, nhiều solution cho từng opportunity và experiment ở lá. Assumption Mapping tách bốn loại rủi ro: desirability (có muốn), viability (có lợi cho business), feasibility (có làm được) và usability (có dùng được). Team ưu tiên kiểm tra giả định vừa quan trọng vừa thiếu bằng chứng.

• Opportunity dùng ngôn ngữ nhu cầu/friction của khách hàng, không dùng tên feature.
• Tạo ít nhất ba solution option trước khi chọn để tránh fixation.
• Dev/QA tham gia sớm giúp lộ feasibility, operability và quality risk.
• UI/UX giúp kiểm tra comprehension và usability trước khi build.
• Tree là living map; evidence mới có thể đổi nhánh ưu tiên.

DESIRED OUTCOME
- Metric / baseline / target:

OPPORTUNITY 1
- Evidence:
- Importance:
  - Solution A:
    - Assumption:
    - Experiment:
  - Solution B:
    - Assumption:
    - Experiment:

OPPORTUNITY 2
- Evidence:
- Importance:
  - Solution A:
  - Solution B:

ASSUMPTION MAP
| Assumption | Type D/V/F/U | Importance | Evidence | Test |
|------------|--------------|------------|----------|------|

MVP là cách nhỏ nhất để tạo value hoặc learning đủ cho quyết định tiếp theo, không phải bản đầy đủ bị cắt polish. Chọn experiment theo assumption: prototype/usability test cho comprehension; fake door đo interest; concierge kiểm tra value bằng vận hành tay; technical spike đo feasibility. Mỗi experiment phải có hypothesis, audience, exposure, metric, threshold, guardrail, timebox và decision rule.

• Không test năm giả định trong một MVP rồi không biết tín hiệu đến từ đâu.
• Success criteria đặt trước khi xem data để giảm goalpost shifting.
• Kill criteria bảo vệ team khỏi kéo dài solution vì sunk cost.
• Prototype fidelity chỉ cao đủ để trả lời câu hỏi hiện tại.
• Cân nhắc ethical risk: fake door phải minh bạch, không thu tiền/PII sai kỳ vọng.

DECISION TO INFORM:

HYPOTHESIS:
Chúng tôi tin [segment] sẽ [behavior]
vì [problem/value].

RISK TYPE: Desirability / Viability / Feasibility / Usability
METHOD:
AUDIENCE:
TIMEBOX:

PRIMARY SIGNAL:
- Baseline:
- Success threshold:
- Kill threshold:

GUARDRAILS:

RESULT:
DECISION: Continue / Iterate / Stop
LEARNING / NEXT STEP:

Prioritization là quyết định opportunity cost dưới constraint. RICE hữu ích khi có Reach/Impact/Confidence/Effort tương đối; ICE nhanh hơn khi data ít; Cost of Delay hợp với timing; Kano khám phá basic/performance/delighter; Impact–Effort giúp workshop; MoSCoW dễ giao tiếp scope nhưng dễ biến mọi thứ thành Must. Framework tạo ngôn ngữ chung, PO vẫn phải chịu trách nhiệm về data, confidence, dependency và strategic fit.

• Định nghĩa thang Impact trước khi chấm để tránh mỗi người hiểu một kiểu.
• Confidence phạt item dựa trên ý kiến; không dùng số lẻ đẹp để che data yếu.
• Effort là input của Developers, không phải PO tự đoán.
• Dependency có thể đổi sequence nhưng không tự động biến item thành valuable.
• Sau điểm số luôn viết decision rationale và điều gì có thể làm quyết định đổi.

OUTCOME:
CONSTRAINT:

| Option | Reach | Impact | Confidence | Effort | Risk | Dependency | Score |
|--------|-------|--------|------------|--------|------|------------|-------|
|        |       |        |            |        |      |            |       |

DECISION
- Chọn:
- Không chọn:
- Vì:
- Trade-off:
- Evidence còn thiếu:
- Trigger để xem xét lại:

SANITY CHECK
[ ] Strategic fit
[ ] Quality/security
[ ] Capacity/dependency
[ ] Opportunity cost

Roadmap là công cụ truyền đạt hướng đi, sequence và learning; không phải Gantt feature list giả chắc chắn. Now–Next–Later phù hợp uncertainty cao. Outcome-based roadmap đặt problem/outcome lên hàng đầu rồi mới ghi initiative/options. Ngắn hạn có confidence cao hơn và chi tiết hơn; trung hạn thể hiện hypothesis/dependency, không hứa chính xác ngày khi evidence chưa đủ.

• Now gồm outcome đang tập trung và evidence/commitment rõ.
• Next là outcome có lý do mạnh nhưng còn dependency hoặc discovery.
• Later là direction/opportunity, không phải backlog đổ lên slide.
• Mỗi roadmap item có owner, metric, confidence và review date.
• Roadmap review khi evidence/constraint đổi, không chỉ theo lịch quý.

PRODUCT GOAL:
NORTH STAR DIRECTION:
REVIEW CADENCE:

NOW
- Outcome:
- Metric/target:
- Why now:
- Initiative/experiment:
- Confidence:

NEXT
- Outcome:
- Evidence needed:
- Dependency:
- Confidence:

LATER
- Opportunity:
- Strategic rationale:
- Unknowns:

NOT DOING
- Item / reason / revisit trigger:

Stakeholder management không phải làm hài lòng tất cả. PO cần hiểu interest, influence, information need và decision right; thiết lập cadence phù hợp; biến yêu cầu thành problem/outcome; trình bày option và trade-off. Một lời “không” tốt thường là “không phải bây giờ/với cách này” kèm reasoning, impact và điều kiện xem xét lại.

• Map influence/interest nhưng cũng ghi expertise, risk và preferred channel.
• Phân biệt consult, recommend, decide và inform để tránh decision by committee.
• Pre-wire quyết định lớn với nhóm bị ảnh hưởng trước buổi họp chính.
• Decision log ghi context, options, evidence, owner, date và revisit trigger.
• Escalate khi decision right/constraint vượt authority, không dùng escalation để né conflict.

STAKEHOLDER
| Name/Group | Interest | Influence | Concern | Input needed | Cadence |
|------------|----------|-----------|---------|--------------|---------|

DECISION RIGHTS
- Recommend:
- Consult:
- Decide:
- Inform:

DECISION LOG
- Date / owner:
- Decision:
- Context:
- Options considered:
- Evidence:
- Trade-off:
- Dissent:
- Revisit trigger:

MESSAGE “NO / NOT NOW”
Mục tiêu chung → Evidence → Constraint → Options → Recommendation

Checkpoint mô phỏng Product Review. Anh trình bày Goal Cascade, Opportunity Tree, MVP, scorecard và roadmap. Sau đó nhận constraint mới: capacity giảm 40%, deadline business giữ nguyên. Mục tiêu không phải giữ nhiều scope nhất mà giữ learning/value quan trọng nhất, nêu quality không được hy sinh và cho stakeholder lựa chọn minh bạch.

• Đóng băng Product Goal trước khi cắt để không tối ưu sai.
• Tách must-have để tạo value/learning khỏi nice-to-have.
• Giảm breadth, automation hoặc segment; không ngầm giảm DoD.
• Nêu impact, risk và option: giảm scope, đổi date hoặc thêm capacity.
• Cập nhật roadmap, decision log và success criteria sau quyết định.

UNCHANGED OUTCOME:
CAPACITY CHANGE:

MUST PRESERVE
- Customer value:
- Learning:
- Quality/security:

CUT / DEFER
| Item | Value lost | Effort saved | Risk | Revisit |
|------|------------|--------------|------|---------|

OPTIONS
A. Scope ↓ / Date giữ
B. Date lùi / Scope giữ
C. Capacity ↑ / Cost ↑

RECOMMENDATION:
STAKEHOLDER DECISION:
UPDATED ROADMAP/METRICS: