决策地图
产品能力：把体验需求拆成可验证的技术决策
CMS、后台、搜索和功能管理都应从产品运营方式出发。
Recommendation
先选能匹配当前团队工作流的最小系统，避免过早搭建全套运营平台。
先定义内容或运营团队如何工作，再决定是否需要专用产品基础设施。
范围
用这条边界避免在错误层级解决相邻问题。
包含
- Feature exposure and release control
- Product feedback collection and synthesis
- Internal and public roadmap workflows
- Structured forms and user input
- Editorial content modeling and publishing
- Staff-facing operational interfaces
- In-product onboarding and activation guidance
- Changelog publishing and product-change history
- Profile-, event-, segment-, and lifecycle-driven messaging
不包含
- Embedded Product Chat, which remains owned by Messaging
- Customer-support ticketing, agent queues, and service operations
- Channel-specific email, SMS, push, and in-app notification delivery
- Product analytics, experimentation statistics, application errors, and performance monitoring
- Employee onboarding, implementation services, and general customer-success strategy
- Feature Monitoring as an independent Task
重要工具
这些工具代表此决策领域内不同路线；请先打开相关任务页面，再将任何工具视作默认。
- WordPress （英文页面）
- Sanity （英文页面）
- Contentful （英文页面）
- Strapi （英文页面）
- Payload （英文页面）
- Typeform （英文页面）
- Tally （英文页面）
- Formspree （英文页面）
- Retool （英文页面）
- Appsmith （英文页面）
- Refine （英文页面）
- Directus （英文页面）
- PostHog （英文页面）
- LaunchDarkly （英文页面）
- Statsig （英文页面）
- Unleash （英文页面）
- Appcues （英文页面）
- Userflow （英文页面）
- Chameleon （英文页面）
- Canny （英文页面）
- Productboard （英文页面）
- UserVoice （英文页面）
- Aha! （英文页面）
- Jira Product Discovery （英文页面）
- Linear （英文页面）
- Headway （英文页面）
- Beamer （英文页面）
- Noticeable （英文页面）
- Customer.io （英文页面）
- Braze （英文页面）
- Iterable （英文页面）
决策顺序
先完成基础归属判断，再增加专门能力。
Is the immediate job editorial publishing, structured user input, or staff operations over application data?
Route to CMS, Forms, or Admin Panels based on the primary data, user, and ownership model.
Must feature exposure change independently of deployment?
Use Feature Flags for evaluated feature state and targeting; route adoption measurement to Product Analytics and failures or performance to Observability.
Do users need contextual help taking the next useful action inside the product?
Evaluate In-Product Onboarding after the core workflow exists and keep employee or services-led onboarding outside the Task.
Does the team have an owner and repeatable process for collecting feedback and turning it into direction?
Use Product Feedback for intake and synthesis; use Roadmaps for governed planning and communication of direction.
Is the need a durable history of shipped changes or targeted communication driven by profile and lifecycle state?
Use Changelogs for persistent release history and Lifecycle Messaging for event-, segment-, or lifecycle-aware delivery.
决策分组
每个任务都对应一个独立的用户决策，而非产品功能标签。
Product operations surfaces
Choose the concrete surface first: editorial publishing, structured input, or staff operations over application data.
Release and activation
Separate controlled feature exposure from contextual in-product guidance.
Learning and direction
Keep collected user input distinct from the roadmap process that communicates prioritization and plans.
Product communication
Distinguish persistent release history from event- and lifecycle-driven communications.
常见混淆
这些边界避免相邻任务被压缩成一个泛泛的候选清单。
- Treating feature exposure, adoption measurement, and application health as one feature-monitoring task.
- Feature Flags control exposure; Product Analytics measures adoption; Observability Tasks diagnose failures and performance. Feature Monitoring is deleted.
- Treating user requests as roadmap commitments.
- Product Feedback captures and synthesizes input; Roadmaps communicate governed prioritization and plans.
- Using editorial content management and operational data administration interchangeably.
- CMS owns structured editorial content and publishing; Admin Panels own staff operations over application data.
- Mixing planned work with a durable record of shipped changes.
- Roadmaps communicate future direction; Changelogs document released changes.
- Treating a persistent changelog and targeted lifecycle delivery as the same communication surface.
- Changelogs publish an owned history; Lifecycle Messaging delivers communications using profile, event, segment, or lifecycle context.
暂缓引入
不要在产品真正需要之前引入专门系统。
No product owner or repeatable intake, synthesis, prioritization, and communication process exists.
Adding dedicated systems before decision ownership exists creates repositories of requests or promises without a governed loop.
The product has no defined lifecycle states, profile or event model, segment policy, or cross-channel owner.
Lifecycle orchestration should follow a defined communication policy rather than substitute for one.
The core product workflow and activation outcome are not yet defined.
Onboarding tooling should guide a coherent product workflow, not compensate for an undefined one.
Starter Stack
查看这些决策如何出现在完整应用起始方案中。
官方资源
支撑此分类边界的标准与一手文档。
来源
此决策地图使用的主张级参考资料。
- 1Evaluation Context specification
OpenFeature · Accessed Official
- 2Providers specification
OpenFeature · Accessed Official
- 3Forms Tutorial
W3C WAI · Accessed Official
- 4Human Interface Guidelines: Onboarding
Apple · Accessed Official
- 5About Projects
GitHub · Accessed Official
- 6About Discussions
GitHub · Accessed Official
- 7About releases
GitHub · Accessed Official
- 8Data model
Contentful · Accessed Official
- 9Explore content
Directus · Accessed Official
- 10Segments
Customer.io · Accessed Official