Adoption, retention, growth loops, moats, metrics¶
Adoption and onboarding¶
A sale is not success. Track the chain and instrument each step:
ACQUISITION -> SIGNUP -> ONBOARDING -> ACTIVATION -> HABIT -> RETENTION -> EXPANSION -> ADVOCACY
Identify the activation event: what has to happen before the customer says "I get it"? For a governed factory it might be the first receipt-backed deployment they did not have to babysit. For a discovery protocol it might be the first agent resolved from another organization. Write it as an observable event, then design onboarding to reach it fast.
Retention¶
A healthy product solves an ongoing need. Ask: why come back, how often, what gets better with usage, what becomes harder to leave, what recurring value exists, what would make a customer cancel. Retention is usually more important than acquisition; growth without retention is leakage.
Growth loops¶
Do not reduce growth to advertising. Products can generate their own distribution:
USER -> USES PRODUCT -> CREATES SOMETHING VISIBLE OR VALUABLE -> OTHERS DISCOVER PRODUCT -> NEW USER
Mechanisms: collaboration, sharing, referrals, generated content, marketplaces, integrations, network effects, community, templates, developer ecosystems, published manifests and registries (an OSSA manifest and a DUADP record are discoverable artifacts by design), open-source modules on drupal.org, GitLab CI components in the catalog, receipts and attestations a customer can show an auditor.
Look for the loop that is native to the product. Name it, or state honestly that the product has none and acquisition will be paid for every time.
Moats and defensibility¶
If this succeeds, what prevents someone from copying it? Candidates: brand, proprietary data, network effects, switching costs, distribution, ecosystem, integrations, community, expertise, regulatory approval, scale, workflow lock-in, open-source ecosystem leadership, standards stewardship.
Features alone are rarely durable moats. For Bluefly the candidate moats are standards leadership (OSSA, DUADP), governance evidence that auditors accept, Drupal and public-sector community trust, and compose-not-build economics. Each must be evidenced, not asserted.
Metrics¶
Every definition establishes a North Star (the metric that best measures delivered value), then: acquisition, activation, engagement, retention, revenue, referral, cost (including model and compute cost per accepted outcome), reliability. Avoid vanity metrics. Prefer "accepted outcomes with evidence" over "agents deployed" and "sites operated under governance" over "pageviews".
The economics test that decides whether it is a product¶
Ask: does each implementation make the next implementation cheaper? If every customer produces another custom fork (a Drupal snowflake, a bespoke connector set, a hand-written policy pack), the thesis has failed and the business is consulting wearing a product name. The reusable assets must accumulate somewhere named: recipes, site templates, upstream contributions, policy and workflow compositions, automated acceptance tests, factory methods, adapters. Put the reuse percentage on the metrics list.
Capture reuse from evidence, never from intent¶
Reusable capability is the compounding asset, and the failure mode is writing the artifact before the method has been proven. The order is:
REAL EXECUTION -> ACCEPTANCE -> REUSE ON A SECOND CASE -> EVIDENCE -> VERSIONED ARTIFACT
not:
GOOD IDEA -> WRITE ARTIFACT
An artifact written from a good idea is a guess with a version number, and it will be trusted by the next person precisely because it looks like captured knowledge.
The artifact's format is implementation, not strategy. Proven method may land as an upstream contribution, a configuration, a recipe, a test, a policy, a formula, an order, an integration, an Agent Skill, or a plain runbook. Do not force every lesson into one shape, and do not let the choice of shape become a product claim. The business claim is the evidence-backed reusable capability; the packaging is how it travels.
Delegation expansion (the metric that proves trust)¶
For any product that puts agents into real operations, the behavioral metric that matters most is the rate at which a customer moves additional consequential workflows from human-only execution into governed agent execution. A customer who keeps the product installed but never delegates more work has bought a dashboard. North Star candidates in this family: Verified Agent-Managed Changes (content), Verified Governed Operations (cross-system). Never tokens, agents registered, prompts, memories, or generations.
Ecosystem strategy¶
A product can create value through third parties: APIs, plugins, extensions, partners, contributors, developers, marketplaces, templates, open standards. Ask what Bluefly owns and what it enables others to build. The corpus answer is that Bluefly owns composition and standards, and enables others to implement. A product that requires Bluefly to own the implementation layer is off doctrine.