Deployed, Live, and Used Are Three Different Things. Product Owners Only Hear One.

Engineering closes the ticket: "shipped to prod." The product owner sends a Slack message to leadership: "The notifications redesign is live." Six weeks later, a customer emails support: "I can't find the new notifications page." All three statements are, from each person's vantage point, correct. And yet the customer's experience is the only one that matters, and it contradicts both of the others.

Deployed, live, and used are three different states. They are almost never communicated as three different states. "Shipped" is used to describe the first. "Live" is used to describe the first again, and also the second, and sometimes the third. "Launched" covers all of them. The vocabulary is collapsed into a single word that means something different depending on who said it and to whom, which means nobody in the chain is getting accurate information about what customers can actually do right now.

This is not a communication failure in the sense of someone being unclear or careless. It is a structural problem. The three states are real, they are consequential, and the systems used to track software delivery — Jira, sprint reviews, status updates — capture only one of them. The gap between deployed and actually-used-by-customers is where features go to die silently, announced as launched, with full Jira closure, while the customer who was supposed to benefit has never seen them.

The three states, precisely defined

The conflation starts because these states are not clearly named or distinguished in most organizations. Giving them precise definitions is the first step toward not confusing them.

The three states that get conflated into one word:

  DEPLOYED
  Definition: the code is running on a production server
  Who controls this: engineering (CI/CD pipeline)
  What it means for customers: nothing, necessarily
  What Jira says: Done
  Example: checkout redesign PR merged Tuesday, running in prod

  LIVE
  Definition: customers can reach the feature — flag on, rollout at 100%,
              stable URL, no permission gate blocking access
  Who controls this: engineering + product (feature flag config, rollout config)
  What it means for customers: they can use it if they find it
  What Jira says: Done (same as deployed — Jira does not distinguish)
  Example: checkout redesign flag enabled for all accounts Thursday

  USED
  Definition: a customer has actually interacted with the feature
              in a meaningful way
  Who controls this: customers
  What it means for customers: the feature exists in their workflow
  What Jira says: Done (same ticket, same status, weeks later)
  Example: 34% of customers have completed a purchase through the new flow

  The status update at each stage: "we shipped it."
  The stakeholder announcement at each stage: "it's live."
  The customer experience at each stage: varies wildly.

The important observation is that Jira says "Done" at stage one — deployed — and it continues to say "Done" whether the feature reaches stage two or stage three or neither. Work-tracking systems track the completion of work. They do not track the downstream state of the system after the work is done. That is a different kind of information, and it lives in a different place.

Where the conflation causes damage

The gap between deployed and live is primarily an engineering and product problem. The gap between live and used is a product and customer problem. Both gaps are invisible to the people who most need to know about them, and each creates a distinct failure mode.

Where the conflation causes real damage:

  Scenario 1: Stakeholder announcement before "live"
  -> Feature is deployed behind a flag at 0% rollout
  -> Leadership announces it to customers or the press
  -> Customers try to use it: not reachable
  -> Engineering has to emergency-enable the flag under pressure
  -> Rollout that was planned as a careful percentage ramp
     goes straight to 100% to fix the announcement

  Scenario 2: Success claim before "used"
  -> Feature is live at 100% rollout
  -> "We launched the checkout redesign" goes in the board update
  -> 6 weeks later: 3% of customers have actually used the new flow
  -> Old checkout path still handles 97% of purchases
  -> The "launched" feature is functionally invisible

  Scenario 3: Done ticket, broken feature
  -> Feature is deployed and the flag is on
  -> A dependent configuration step was never completed
  -> EU customers get a 403, US customers see a blank state
  -> Jira says Done, support tickets say broken
  -> Engineering has to triage something that was already "shipped"

  In all three cases, the same word — shipped, live, launched — was used
  to describe three completely different states.

The third scenario is the most common and the hardest to see in advance. A feature that is deployed and flagged on but blocked by a missing configuration step, a missing permission scope, or a regional gate looks identical in Jira to a feature that is fully available. The ticket is closed. The feature is not reachable. The gap shows up in support tickets, customer escalations, and quarterly reviews — never in the sprint report that called the work done.

Engineering says it shipped; product cannot find it — this specific collision happens repeatedly because "done" in engineering means the implementation is complete, and "done" in product means the customer can use it. Both definitions are internally consistent. Neither is wrong. The problem is using the same word for both, in communications that reach both audiences, without clarifying which meaning applies.

Why Jira cannot capture deployment state

Jira is a work-tracking system. It was designed to track the state of tasks moving through a workflow, not the state of a system after those tasks are complete. A ticket moves from To Do to In Progress to Done. Done ends the ticket's lifecycle in Jira. What happens after Done — which flags are enabled, what rollout percentage is set, which accounts have access, which dependent configurations are still pending — is outside Jira's model because it is not work state. It is system state.

What Jira's "Done" state does not tell you:

  Ticket: CHECKOUT-291 "Redesign checkout flow for v2"
  Status: Done
  Closed: 14 days ago

  Not captured in that ticket:
  -> Feature flag: CHECKOUT_REDESIGN_V2
  -> Flag state: enabled for [beta-accounts] segment only
  -> Global rollout percentage: 12%
  -> EU accounts: blocked by data residency middleware (GDPR-44, open)
  -> Mobile: not implemented (MOB-188, in backlog, unassigned)
  -> Guest checkout path: still routes to v1 (CHECKOUT-304, open)
  -> Admin configuration required: yes — accounts without "checkout_v2"
     permission scope cannot see the new flow even if flag is on
  -> Actual customer reach: approximately 4% of active accounts

  The ticket is correct. The work described in it is done.
  The feature is not available to 96% of customers.
  Nobody lied. The system is just not visible from Jira.

Teams that try to solve this with manual Jira hygiene — custom statuses, flag-state comments, "customer available" labels added by hand — run into the fundamental problem of all manual processes: it works when people do it, and it is wrong when they do not. The engineer who merged the PR and closed the ticket is not always the same person who enables the feature flag three days later. The person who enables the flag is not always the one who realizes that EU accounts are still blocked by a middleware guard. The knowledge disperses. Jira does not collect it.

Feature flags that were never cleaned up after launch make this worse. A codebase with 40 active feature flags, half of them in ambiguous states, is a codebase where the question "is this feature actually on for customers?" requires non-trivial investigation every single time. The investigation falls to engineers, who have other things to do. Product owners wait.

What product owners actually need to know

A product owner who is about to announce a feature to stakeholders or customers needs to know one thing: can the people I am announcing this to actually use it right now? That is not the same as "is the code deployed?" or "is the Jira ticket closed?" It requires knowing the feature flag state, the rollout percentage, any regional restrictions, any permission gate requirements, and the state of parallel tracks like mobile or API parity.

None of that information is in Jira. All of it is in the system — in the feature flag configuration, the deployment tooling, the codebase itself where flag checks and permission guards are implemented. A product owner who wants to verify "live" before announcing it has to get that information from the system or from an engineer who can query the system. Currently, the path of least resistance is asking an engineer, which means every pre-announcement verification is a dependency on engineering availability.

Product owners stuck translating between engineering state and business language face exactly this friction before every stakeholder communication. The question is straightforward. The answer lives somewhere inaccessible. The engineer becomes the translator.

Querying deployment and rollout state in plain language

Kognita indexes the codebase continuously and makes the system's current state queryable without requiring anyone to read code. For deployment and rollout questions, this means a product owner can ask "is the checkout redesign actually reachable by all users right now?" and get an answer that reflects actual system state — not Jira ticket state, not what was last communicated in a sprint review, but what the code and configuration currently say about who can access this feature.

PO asks Kognita: "Is the checkout redesign actually reachable
by all users right now?"

Kognita returns:
  Feature: Checkout redesign v2 (CHECKOUT-291)
  Jira status: Done (closed 14 days ago)

  Current customer reachability: No — approximately 4% of accounts

  Access gates still active:
  -> Feature flag CHECKOUT_REDESIGN_V2: enabled for [beta-accounts] only
     Global rollout: 12% of accounts
  -> EU accounts: blocked by data residency middleware
     Tracking ticket: GDPR-44 (open, no assignee)
  -> Mobile: checkout-service v2 endpoints not called by mobile clients
     Tracking ticket: MOB-188 (in backlog, unassigned)
  -> Guest checkout: routes to checkout-service v1
     Tracking ticket: CHECKOUT-304 (open, in sprint 47)
  -> Permission scope: accounts without "checkout_v2" scope
     cannot access new flow regardless of flag state

  To reach all users:
  -> Enable CHECKOUT_REDESIGN_V2 globally (or ramp rollout to 100%)
  -> Resolve GDPR-44 (EU data residency)
  -> Resolve MOB-188 (mobile implementation)
  -> Resolve CHECKOUT-304 (guest checkout path)
  -> Audit accounts missing "checkout_v2" permission scope

The answer in this example reveals that a feature announced as "shipped" is reaching roughly 4% of customers — not because anyone made an error, but because the full set of gates (flag, rollout percentage, regional restriction, mobile parity, guest path, permission scope) were each individually correct but collectively meant almost nobody could reach the feature. No single person had visibility into all of them simultaneously. Kognita reads across all of them at once.

Feature flag and rollout configuration as a first-class query

The rollout configuration question — "what does the rollout configuration say for the notifications feature?" — is something a product owner should be able to answer before any stakeholder communication. In practice, it requires either access to LaunchDarkly (or whichever flag management tool the team uses) plus knowledge of the flag name, or asking an engineer to look it up.

PO asks Kognita: "What does the rollout configuration say
for the notifications feature?"

Kognita returns:
  Feature: In-app notification center (NOTIF-88)
  Jira status: Done (closed 3 weeks ago)

  Rollout configuration:
  -> Feature flag: NOTIFICATION_CENTER_V1
  -> Current state: enabled for accounts created after 2025-01-01
  -> Older accounts: flag evaluates false — notification center not shown
  -> No rollout ramp configured — this is a hard account-age cutoff
  -> New accounts (post Jan 2025): 100% reach
  -> Existing accounts (pre Jan 2025): 0% reach

  Approximate customer split:
  -> ~23% of active accounts created after Jan 1, 2025
  -> ~77% of active accounts on the pre-cutoff cohort

  Related open tickets:
  -> NOTIF-101: "Notification center not visible" (3 reports, open)
     All three reporters have account creation dates before Jan 2025

The query works without the product owner knowing the flag name, the flag management system, or which service implements the gate. They ask in the language of the feature — "notifications feature" — and Kognita connects that to the technical artifact, reports its state, and surfaces the downstream consequence: 77% of active accounts cannot see this feature. The support tickets filed by users with pre-cutoff accounts make sense immediately once that configuration state is visible.

Changing the "deployed" announcement to "live"

The announcement problem — product owners announcing features as live before verifying the live state — is a symptom of the verification step being too expensive. If confirming "is this actually reachable by customers?" requires filing a ticket, waiting for an engineer, and getting an answer in a meeting two days later, product owners will skip the verification for routine launches and rely on the Jira Done status instead. Jira says Done. The Slack message says live. The customer says they cannot find it.

When the verification step is a two-minute query in Kognita, it stops being skipped. The product owner checks reachability before drafting the announcement. If the feature is deployed but the flag is at 12% rollout, they either hold the announcement until the ramp completes or they frame the announcement accurately — "rolling out to all accounts over the next week" rather than "now available to all customers." Both are defensible communications. Only the accurate one is true. The system check is what makes the accurate one possible without engineering involvement.

Final take

Deployed, live, and used are not synonyms. They have never been synonyms. The vocabulary collapsed because the systems teams use to track delivery — Jira, sprint reviews, status updates — only have one state for all three. Done means the code shipped. It does not mean the customer can use it. It has never meant that. The conflation persists because the alternative — verifying actual customer reachability before every announcement — has always required engineering involvement, and engineering involvement is never free.

The fix is making the verification self-serve. When product owners can ask "is this actually reachable by all users right now?" and get a plain-language answer from the system — flag state, rollout percentage, regional gates, permission requirements — the check happens before every announcement instead of after every customer complaint. Deployed becomes a technical fact. Live becomes a verified state. The gap between them stops being invisible.