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.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
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"]
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.
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
Start with your 5-10 most successful customers
Ask them to share one insight, one metric, or one lesson from deployment
Build the first 3 "canonical" pieces of application knowledge with their input
Create a venue (customer Slack, private LinkedIn group, or customer forum)
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
