菜单
Bridge for hardware teams adopting digital growth methods. Translates software growth concepts (funnel, activation, PLG signals, community) into hardware-native equivalents. Non-blocking signal module — outputs carry bridge metadata and do not gate any workflow.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/0xF4ng/aether-growth-fieldwork --skill online-growth命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Entry-point router. Ask the user two questions, then route to the right skill. Call this when you don't know where to start.
Writing production workflow for technical B2B and developer-community content pieces. Invoke when an author needs to produce a migration story, technical deep dive, architectural decision piece, how-to guide, or thought-leadership article from scratch. This skill selects the right story framework, produces the draft structure, and runs a pre-publish editorial checklist. It does not review completed content — use `pmm/content-review/SKILL.md` for that gate. Appropriate for any technical B2B product; no brand-specific knowledge required.
Decide whether a changelog entry should stand alone or batch with others, run the quality gate, and produce a publish-ready entry with SEO title and visual recommendation.
基于 SOC 职业分类
正在显示 SKILL.md
| name | online-growth |
| description | Bridge for hardware teams adopting digital growth methods. Translates software growth concepts (funnel, activation, PLG signals, community) into hardware-native equivalents. Non-blocking signal module — outputs carry bridge metadata and do not gate any workflow. |
| triggers | ["/hardware-online-growth","hardware team asks how to apply digital growth or PLG methods","hardware product is launching a DTC or direct online channel","hardware team wants to use community mechanics"] |
| role | bridge |
| signal-direction | hardware-gtm → reads growth methods |
| version | 1.0.0 |
| sources | ["hardware-gtm/DOMAIN.md","growth/DOMAIN.md","growth-motion-plg (growth-skills v1.0, score 8.5/10)"] |
| metadata | {"bridge-signal-from":"growth","blocking":false} |
Confirm (ask or infer) before applying any digital growth framework:
This bridge guarantees:
/launch)bridge-signal-from: growth and blocking: false — they are recommendations, not gatesWhat this is: A translation layer. Growth methods developed for software products have hardware equivalents — but they are not direct mappings. Using a software playbook on a hardware product without translation produces wasted effort and wrong conclusions. This bridge does the translation.
What this is not: A replacement for the three-pillar check. Brand and marketing decisions still require the three-pillar check to pass. This bridge operates on the channel and engagement layer, not the launch readiness layer.
Software funnel thinking applies to hardware with modified stage definitions.
| Software stage | Hardware DTC equivalent | What to measure |
|---|---|---|
| Acquisition | Organic search + content (video, technical specs, case studies) + ad traffic |
| Qualified sessions: visitors from relevant industry/role |
| Activation | Demo booking or trial request completed | Demo booked within 7 days of first visit |
| Retention | Evaluation-to-POC progression | Prospect proceeds from demo to defined next step within 30 days |
| Referral | Reference customer agrees to be cited or takes a call | Reference willing to talk to new prospects |
| Revenue | POC or pilot contract signed | Contract value and recurring component share |
The hardware FVM equivalent: the activation moment for a hardware prospect is not signing up — it is completing a meaningful demo or receiving a sample. Everything before that is awareness.
Use /funnel-audit with the hardware DTC funnel mapped above.
Common hardware DTC bottlenecks:
The hardware trust deficit is harder to solve than the software equivalent. A developer trying a SaaS tool risks 15 minutes. A factory manager bringing in a robot risks a production line. The social proof requirement is 10× higher.
PLG in software = users self-serve their way through the funnel. Hardware cannot self-serve (it is a physical product requiring installation). But there are PLG-equivalent signals worth instrumenting.
| Software PLG signal | Hardware equivalent | What to do when detected |
|---|---|---|
| Multiple team members from same org sign up independently | Multiple engineers from same company request demos or content independently | Route to SLG: this company has internal interest beyond the original champion |
| Usage exceeds free-tier limits consistently | Demo requests multiply from same company; site visits from same IP cluster increase | Trigger proactive outreach: "I noticed several of your colleagues have been looking at this" |
| Integration with enterprise tools attempted | Prospect asks about MES/ERP/SCADA integration | This is a serious evaluation signal — route to technical support immediately |
| Company domain matches enterprise profile | Company matches ICP criteria (industry, size, relevant application) | Priority account; warm outreach using company-specific insight |
The hardware equivalent of PLG is the application library. A prospect who has watched 5+ application videos from your library, downloaded a datasheet, and visited the pricing page has done the hardware equivalent of a self-serve trial. They are warm. Contact within 24 hours of this pattern.
Software developer communities build around shared technical problems and open tools. Hardware communities build around shared operational problems and trusted references.
| Type | Platform | What it is |
|---|---|---|
| Industry application communities | LinkedIn groups, trade event networks, vertical Slack channels | Operators in a vertical (food processing, automotive, logistics) share challenges |
| User community | Customer Slack, private customer forum | Your installed base shares application knowledge |
| Technical/enthusiast community | GitHub (if OSS component), YouTube comments | Engineers who understand the technology and share builds |
| Content type | Format | Why it works |
|---|---|---|
| System running in production (real customer site) | Short video (30–60s) | Irrefutable evidence; operators trust what they can watch |
| Application-specific deep dive | Written + video | "Can it handle [my specific part]?" — answer with evidence |
| Customer operating metrics | Case study with real numbers | ROI justification for the procurement conversation |
| Failure mode and recovery | Written or video | The transparency paradox — shows the system handles real conditions |
The highest-converting hardware community content is video of the system doing the exact job the prospect needs done. Not a product demo. An application video.
Hardware community trap: creating a public forum that consists only of product announcements from the vendor. Engineers see through this immediately. Every post must provide application value, not brand value.
Hardware has a longer and more complex buyer journey than software. Design the lifecycle around the deal stage, not the calendar.
| Stage | Lifecycle action | Content |
|---|---|---|
| New lead (demo requested) | Confirm demo within 4 hours; no-show follow-up same day | Personal, brief |
| Post-demo (active evaluation) | Send application video specific to their use case within 24h | Application-specific evidence |
| POC in progress | Weekly check-in with specific operational question | Technical, relationship-building |
| Stalled evaluation (no response 2+ weeks) | Diagnostic question or new signal (new application video, relevant case study) | Value-add, not push |
| Existing customer (expansion) | Quarterly review with OEE benchmarks from similar installations | Data-driven |
Hardware re-engagement signal: a prospect who visited the technical documentation or application library more than once in a week after a period of silence is likely re-evaluating. Contact within 48h.
| Software method | Why it doesn't translate directly |
|---|---|
| Freemium / free trial | Hardware is a physical product; you cannot ship 1,000 free trial units. Instead: demo unit program for qualified partners; demo at customer site for qualified leads. |
| A/B testing messaging at scale | Hardware deal volume is typically too small for statistical A/B testing. Sequence tests or interview-based messaging validation instead. |
| High-volume drip sequence | Engineers and procurement buyers tune out automation. A 12-email onboarding drip that sounds automated destroys trust faster than it builds it. |
| Product-led virality | Hardware users don't share a file or link to onboard a colleague. Instead: reference customer introductions; application library sharing. |
| DAU/WAU as health metric | Hardware health is installed base uptime, NRR, and application expansion per deployment. |
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Applying SaaS freemium to hardware | You cannot ship 1,000 free trial units; physical cost is the constraint | Use demo unit program for qualified partners and site demos for qualified leads |
| Running A/B tests at SaaS volume expectations | Hardware deal volume is too small for statistical significance in most cases | Use interview-based validation and sequence tests instead of split testing |
| High-volume drip sequences to hardware buyers | Engineers and procurement buyers tune out automation faster than software buyers | Maximum 4 emails in onboarding; plain text; personalized with usage/application context |
| DAU/WAU as hardware health metric | Hardware users don't "return" to a website the way software users return to an app | Use: installed base uptime, NRR, application expansion per deployment |
| Application library without job-specific content | A product demo video is not an application video | Application videos show the product doing the EXACT job for a specific vertical (food processing, automotive, logistics) |
| Community that's only vendor announcements | Engineers immediately recognize brand-only content and disengage | Every community post must provide application value, not brand value |
| Using product-led virality (share a link) | Hardware users onboard colleagues via reference introductions, not link shares | Design reference introduction programs; track and reward them explicitly |
| Metric | Benchmark | Notes |
|---|---|---|
| Demo request conversion (qualified landing page visitor) | 1–3% | 5–10% for highly targeted vertical content |
| Demo → POC progression rate | 30–50% | Below 30% = demo not showing job-fit; missing application specificity |
| Demo response time (target) | <4 hours | >24 hours drops POC conversion by 30–40% |
| Content that drives most demo requests | Application video of product in target vertical | Outperforms spec sheets 5–10× in click-through |
| LinkedIn reach for technical hardware content | 500–5,000 impressions for account with 1K followers | Video outperforms text 3–5× |
| Average hardware B2B sales cycle | 3–9 months | Complex machinery/robotics: 6–18 months |
| References willing to take prospective customer call (healthy installed base) | >30% | Below 20% = customer satisfaction issue |
| PLG equivalent: warm signal threshold (application library + pricing visits) | 5+ content visits from same company in 1 week | Treat as inbound; contact within 48 hours |
| Hardware community: time-to-first-answer (healthy) | <4 hours | After seeding period; below this = active community |
| Yield rate minimum for commercial launch | ≥95% | Below 95%: pilot volumes only |
| Skill | When to use |
|---|---|
growth/funnel-audit/SKILL.md | Audit the hardware DTC funnel using translated stage definitions in this bridge |
pmm/icp-research/SKILL.md | Before bridge applies: hardware ICP requires application-scene + vertical, not just firmographic fit |
pmm/launch/SKILL.md | Hardware branch: launch workflow enforces three-pillar check |
hardware-gtm/DOMAIN.md | Three-pillar check, channel strategy, POC/pilot contract design |
growth/DOMAIN.md | Growth motion definitions, PLG signals, community flywheel |
## Online Growth Brief (Hardware)
**Product:** [Name]
**Sales motion:** [B2B partner / DTC / OEM]
**ICP:** [Role + vertical + application scene]
**Three-Pillar Check status:** [PASS / Not yet run — note if brand/marketing decisions are gated]
### Channel mix recommendation
| Channel | Role | Unit economics (estimated) | Priority |
|---|---|---|---|
| [Channel] | [Awareness / Activation / Demo conversion] | [CAC estimate or demo cost] | [P1 / P2 / P3] |
### 30-day experiment spec
Hypothesis: [If we [action on channel], then [metric] improves by [estimate] because [hardware-translated rationale]]
Measurement: [What to track; hardware-equivalent activation event]
Success signal: [Threshold for WIN verdict]
Owner: [Role]
### Success metrics
Primary: [Hardware-equivalent activation metric — e.g., demo requests from targeted ICP, not signups]
Guardrail: [What must not decline — e.g., demo-to-POC rate]
### Bridge metadata
bridge-signal-from: growth
blocking: false
note: This is a bridge output — it translates growth methods for hardware context.
It does not replace the three-pillar check or the hardware launch workflow.