The startup wants to use engineering effort to acquire customers rather than spending on ads. Use this skill when:
→ Check prompt for: customer profile, pain points
→ If missing, ask: "Who is your ideal customer, and what's the one question they ask before they're ready to pay for your product?"
→ Check prompt for: team size, availability, prior free tools
→ If missing, ask: "How much engineering time can you budget for building the tool? Even 2-4 weeks is enough for a simple calculator."
SUFFICIENT: ideal customer + core question + engineering capacity known
PROCEED WITH DEFAULTS: customer known, brainstorm common category questions
MUST ASK: customer is too vague to identify the core question
Use TodoWrite:
ACTION: Find the ONE specific question the ideal customer asks before they're ready to pay for your product. Not "what should I do about marketing" but "is my marketing working well enough?" or "how does my site compare to competitors?"
Examples:
The question must be:
WHY: Generic free tools produce generic leads. HubSpot's Marketing Grader attracts people who care about marketing quality — which is exactly HubSpot's ideal customer. A generic "business calculator" attracts everyone and converts no one. The tool must match the question, and the question must match the customer.
ACTION: Strip the tool to the minimum viable answer:
Budget: 2-4 weeks of engineering for a first version. Resist feature creep.
Write the design spec to tool-design.md.
WHY: Complexity is the enemy of adoption. HubSpot Marketing Grader succeeded partly because it was embarrassingly simple — paste a URL, get a grade. If it had required a 20-question survey first, 90% of users would have dropped off. The friction-to-value ratio is the core metric.
ACTION: Design the landing page around a single input field, centered, with minimal distractions. The user types or pastes one thing and clicks one button. Everything else waits until after the result is shown.
Elements to include ON the landing page:
Elements to EXCLUDE from the landing page:
WHY: Every additional element on the landing page reduces conversion to first-use. The single-input pattern removes all friction between "user arrives" and "user gets value." The sales pitch happens after the value is delivered, when the user is in a "this is useful" state — not before, when they're evaluating whether to try.
ACTION: Design what happens AFTER the user gets their result:
Write the flow to tool-capture-flow.md.
WHY: Gating value behind email collection kills conversion. Delivering value first and asking for email second (for "send me my report" or "notify me of improvements") captures email at 30-50% rates instead of 5%. The sequence matters: value → capture, not capture → value.
ACTION: The tool is built — how do people find it?
Distribution channels for tools:
WHY: A great tool that nobody finds is worthless. Distribution is half the work. The tool's SEO properties (keyword-rich domain, targeted landing page) compound over time and often become the biggest traffic source.
Three markdown files:
tool-design.md — Core question, input, output, scope constraintstool-capture-flow.md — Post-result flow, email capture, product CTAtool-distribution.md — Distribution channels and launch planScenario: B2B SaaS with spare engineering capacity
Trigger: "We have 2 engineers on the bench for 4 weeks. We sell analytics software to marketers. What should we build?"
Process: (1) Core question: "Is my website's analytics setup correct?" — something marketers worry about. (2) Tool design: paste URL → crawl for Google Analytics, GTM, event tracking, UTM consistency → score report. (3) Single-input: URL field + "Check my site" button. (4) Capture: show score immediately, "email me the full report" capture. Product CTA: "Our tool fixes these 5 issues automatically." (5) Distribution: SEO on "analytics audit", launch on Product Hunt, embed on analytics blog.
Output: Complete tool spec, lead flow, distribution plan.
Scenario: Consumer health app
Trigger: "We have a meal tracking app. Want to use engineering-as-marketing. Ideas?"
Process: (1) Core question: "How healthy is my diet?" — universal question for target audience. (2) Tool: "Paste your last 3 days of meals → AI analyzes nutrition and grades your diet." (3) Single input: text area for meal entries. (4) Capture: show grade immediately, "Save your progress" (email capture for 7-day tracking). Product CTA: "Our app auto-tracks this every day." (5) Distribution: SEO on "healthy diet quiz", Instagram/TikTok shareable results.
Output: Tool concept, social-friendly result design, distribution plan.
Scenario: Founder pulled between product and tool
Trigger: "Engineering team has 3 weeks free. But I'm worried we should use that time to fix bugs in the product. Which is better?"
Process: (1) Engineering resource hoarding anti-pattern in action. (2) Frame the trade-off: 3 weeks of bug fixes = marginal improvement to existing users. 3 weeks building a free tool = ongoing lead flow for years. ROI comparison strongly favors the tool. (3) Caveat: if the bugs are P0/churn-causing, fix them first. If they're "nice to have", build the tool. (4) Tool recommendation based on customer question. (5) Commit to the decision: don't build half a tool and half a bug fix.
Output: Clear decision framing that breaks the engineering-hoarding default.
This skill is licensed under CC-BY-SA-4.0.
Source: BookForge — Traction: A Startup Guide to Getting Customers by Gabriel Weinberg and Justin Mares.
Install related skills from ClawhHub:
clawhub install bookforge-bullseye-channel-selection — Select Engineering as Marketing deliberatelyclawhub install bookforge-seo-channel-strategy — Tools rank for long-tail queries naturallyclawhub install bookforge-content-and-email-marketing — Tools capture emails for lifecycle marketingOr install the full book set from GitHub: bookforge-skills
共 1 个版本
暂无安全检测报告