Product theory¶
What a product is¶
A product is not the thing you built. A product is a repeatable mechanism for producing an outcome someone values enough to choose, and to pay for, again.
A product generally has all of these. Missing one is a finding, not a detail:
IDENTIFIABLE USER
PROBLEM / DESIRE
VALUABLE OUTCOME
DELIVERED EXPERIENCE
REPEATABLE DELIVERY
EXCHANGE OF VALUE
OWNER
MEASURABLE SUCCESS
Things that are routinely mislabeled as products¶
| Term | What it is | Becomes a product when |
|---|---|---|
| Feature | A capability inside a product | Never on its own; it can become an add-on Offering |
| Capability | A business function with one authority, protocol and runtime independent | A Product packages it with a buyer, price, and delivery |
| Platform | A substrate others build on | It has its own buyers and economics, not just internal consumers |
| Tool | Something a person operates to do a task | It has a repeatable outcome and a paying audience |
| Infrastructure | Runtime, hosting, plumbing | Almost never; it is cost of goods for a product above it |
| Service | Labor delivering an outcome | It becomes repeatable, packaged, and priced (productized service) |
| Marketplace | A venue matching supply and demand | Both sides show up without being hand-fed |
| Ecosystem | Third parties creating value around you | It is a strategy, not a SKU |
| Solution | A bundle assembled for one buyer type | The bundle is repeatable and named |
| Experience | How it feels to use | A property of a product, not a product |
| Brand | Expectations attached to the product | Never a product; it multiplies one |
| Business | The entity that sells products | Contains products; is not one |
| Standard / protocol | A specification others implement | Not a product; products conform to it or implement it |
| Project | Bounded work with an end date | Never; projects produce products or outputs |
In the Bluefly estate the specific confusions to watch are: pack called product, pack directory
called product line, protocol (OSSA, DUADP) called product, ops mapping called product, dashboard
source code stored as product doctrine. See product-portfolio-taxonomy.md.
Problem theory (before the product)¶
Answer these with evidence, in this order:
- What problem exists? State it in the customer's words, not ours.
- Who experiences it? Role, not demographic.
- How frequently? Daily, per release, per audit, per incident, annually.
- How painful? What does it cost in money, time, risk, reputation, sleep.
- What happens if nobody solves it? If the honest answer is "nothing much", it is a vitamin.
- What is the current workaround, and what does it cost?
- Vitamin or painkiller? Painkillers sell to budgets that already exist.
- Is the problem already budgeted? A line item is a buyer with money; a wish is not.
- Is the problem growing or shrinking? Regulation, AI adoption, and platform end-of-life grow it.
- What event causes someone to go looking for a solution?
Trigger events¶
Something changes before somebody buys. Examples that matter for Bluefly's markets:
Drupal 7 / 10 end of life date announced or reached
Acquia or hosting contract renewal arrives
new accessibility, privacy, or AI regulation applies
security incident or failed audit
CEO or board mandates AI adoption with governance
procurement requires evidence of agent governance
agency or vendor relationship ends
grant or budget cycle opens
site outage or content backlog becomes visible to leadership
competitor or peer institution launches something
A target audience without a buying trigger is incomplete. Write the trigger into the ICP.
The catalyst must be dated and primary-sourced¶
A trigger is only load-bearing when it has a date and a primary source. "Drupal is aging" is not a catalyst. "Drupal 10 reaches end of life on December 9, 2026, and a major version cannot be skipped, so every Drupal 10 site must move through Drupal 11" is a catalyst: it has a date, a consequence, and an authority that states it.
Rules:
- Record the date, the source URL, and the date you retrieved it. A catalyst without all three
is L5 no matter how confident anyone is about it.
- Verify against the primary authority, never a vendor blog, an analyst summary, or a previous
version of your own document. Version thresholds, EOL dates and compliance deadlines move, and
they move in both directions: deadlines get extended, and "corrections" sometimes restore an
error. Check the primary source even when correcting something.
- Watch for the near-miss source. A change record, release note or requirement that belongs to a
different project will look authoritative and be about something else entirely. Confirm the
project, not just the number.
- When the primary source says the answer is not yet determined, write that, including the words
it uses. "Listed as TBA as of
Product lifecycle¶
DISCOVERY -> VALIDATION -> INTRODUCTION -> GROWTH -> MATURITY -> DECLINE / REINVENTION -> RETIREMENT
Each stage has different priorities. Discovery wants learning per dollar. Introduction wants first paying references. Growth wants repeatable acquisition and retention. Maturity wants margin and defensibility. Decline wants a decision, not a roadmap. Name the stage in every definition.
Product-market fit stages¶
PROBLEM DISCOVERY -> PROBLEM VALIDATION -> SOLUTION VALIDATION -> MVP -> EARLY ADOPTION -> PRODUCT-MARKET FIT -> SCALE
Do not write "scale" plans before early adoption evidence exists. A definition that skips stages must say which evidence lets it skip.