Online growth

Hardware → Online Growth Bridge

Before starting

Confirm (ask or infer) before applying any digital growth framework:

• Product type — physical product (manufactured/assembled)? Or hardware + firmware bundle with some self-serve component?
• Sales motion — B2B partner channel / distributor / DTC / OEM? (determines which PLG equivalent applies)
• Three-Pillar Check status — has it passed? (if not, the bridge cannot unblock brand or marketing decisions; those remain gated)
• Current funnel visibility — are there any digital analytics on the company's content, demo requests, or web traffic?
• Target market — geography + vertical + ICP role? (hardware ICP qualification requires industry vertical and application context, not just company size)
• Existing content — are there application videos, case studies, or technical specs already published?

---

Contract

This bridge guarantees:

• No brand or marketing decisions are made without three-pillar check passing (reinforced here even though primary gate is in /launch)
• Software growth methods are never applied directly — every method is translated to a hardware-appropriate equivalent
• Bridge outputs are labeled with bridge-signal-from: growth and blocking: false — they are recommendations, not gates
• Hardware FVM equivalent (meaningful demo / sample receipt) is always used as the activation moment, never software-style signups

---

What 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.

---

Funnel applied to hardware DTC

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.

Running a hardware funnel audit

Use /funnel-audit with the hardware DTC funnel mapped above.

Common hardware DTC bottlenecks:

• Awareness gap: few qualified visitors; content is not reaching the right audience
• Messaging mismatch: visitors arrive but don't request demos; website shows specs, not outcomes
• Trust deficit: visitors consider but don't commit; missing case studies, certifications, or references
• Friction: demo booking process is too complex; too many form fields; no response within 24h

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 signals adapted to hardware

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.

---

Community mechanics for hardware brands

Software developer communities build around shared technical problems and open tools. Hardware communities build around shared operational problems and trusted references.

What hardware communities look like

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

Community content that converts for hardware

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.

Seeding a hardware user community

1. Start with your 5-10 most successful customers
2. Ask them to share one insight, one metric, or one lesson from deployment
3. Build the first 3 "canonical" pieces of application knowledge with their input
4. Create a venue (customer Slack, private LinkedIn group, or customer forum)
5. Do not wait for users to generate content — seed it yourself for the first 6 months

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.

---

Lifecycle design for hardware DTC

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.

---

What NOT to borrow directly from software growth

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-patterns

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

---

Hardware DTC benchmarks (2025–2026)

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

---

Related skills

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

---

Output format

## 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.