Your Feature Shipped. Is the Feature Flag Actually On in Production?

The sprint closes on Friday. Engineering marks the ticket Done. The product owner sends a stakeholder update that afternoon: the payment redesign shipped. On Monday, a stakeholder replies asking where they can find it. The PO checks the app — cannot find it either. They send a Slack message to the engineering lead. Thirty-five minutes later the answer arrives: the feature is behind a flag that's currently enabled for internal accounts only, and it won't go to 100% until Tuesday after the team checks error rates. Nobody told the PO. Jira said Done. Done was not done.

This is not a rare edge case. It is the standard experience for product owners at any team that uses feature flags — which is most teams. Feature flags are good engineering practice. Gradual rollouts reduce risk. Percentage-based enablement lets teams catch errors before they affect everyone. But none of these mechanisms communicate their state to the people who need to know whether a feature is actually live. The PO is the last to find out, usually from a customer or a confused stakeholder.

What "Done" in Jira actually means

Jira tracks work state, not system state. A ticket transitions to Done when the engineering work described in that ticket is complete. Merged, deployed, tested — the implementation is finished. Done does not mean the feature is visible to customers. Done does not mean the feature flag is enabled. Done does not mean the rollout has completed. Those are system states, and Jira has no field for them.

This was less of a problem before feature flags became standard. When deploying code meant the feature was on, Done and "customer can use this" were the same event. Now they are different events that can be days or weeks apart, and the gap between them is invisible in Jira. The ticket closes when the code merges. What happens after that — flag enablement, rollout percentage changes, regional configuration — lives in engineering systems the PO has no view into.

Engineering saying it shipped and product not being able to find it is the direct consequence of this gap. Both sides are correct in their own frame. Engineering completed the work. The feature is not yet available to customers. The ticket state — Done — is true in engineering terms and actively misleading in product terms.

The states between merged and live

The gap between a merged PR and a customer-available feature is not a single state. It is a sequence of states, and the feature can stop at any one of them. From the PO's position in Jira, all of those states look identical: the ticket says Done.

The states a feature flag can be in — and what the PO knows:

  State: Flag OFF in production
  What the PO sees: feature is "Done" in Jira
  Reality: zero users can see or use the feature
  How the PO finds out: customer complaint, or Slack to engineering

  State: Flag ON for internal accounts only
  What the PO sees: feature is "Done" in Jira
  Reality: only engineering and QA accounts see it
  Staging works. Production appears broken to the PO.
  How the PO finds out: "I can't find it" → Slack → 20 minutes later

  State: Flag ON for 5% of users (gradual rollout)
  What the PO sees: feature is "Done" in Jira
  Reality: 95% of users cannot see it, including the PO
  The PO announces it to stakeholders. A customer says they can't find it.
  How the PO finds out: stakeholder escalation

  State: Flag ON globally — but dependent configuration incomplete
  What the PO sees: feature is "Done" in Jira
  Reality: flag is on, but a permissions table migration didn't run
  Customers get an error. Support tickets open.
  How the PO finds out: the support queue

  State: Flag ON globally — feature actually live for all users
  What the PO sees: feature is "Done" in Jira
  Reality: matches what Jira says
  How the PO finds out: usually by chance, or by asking

The gradual rollout case is particularly treacherous. A feature enabled for 5% of users is technically live — engineering will correctly say it is deployed and running. But 95% of users, including the PO, cannot find it. The PO announces it to stakeholders. A customer says they can't access it. The PO goes back to engineering. The answer: "yes, we're rolling it out slowly, it's not at 100% yet." This was never communicated. The Jira ticket gave no indication. The PO has now made a commitment they cannot keep, not because anyone failed to do their job, but because the information never flowed from the system to the person who needed it.

Why the PO has no way to check

The honest question is: why can't the PO just look this up themselves? The answer is that looking it up requires knowing where to look, what the flag is called, which environment to check, and how to read the feature flag management interface — whether that's LaunchDarkly, Split, Unleash, or a custom config system. Most POs have no access to those systems. Those who do have access don't know the flag names, which aren't captured in Jira. And even with access and a flag name, interpreting what a percentage rollout or a targeting rule means for customer availability requires context that isn't surfaced in a flag dashboard.

The information exists. It's just locked behind tooling and terminology that is built for engineers. Product owners stuck in translation between what Jira shows and what the system actually does face this gap constantly — not just with feature flags, but with any question about actual system behavior. Feature flag state is one of the most common cases because it directly affects the PO's ability to communicate release status accurately.

The workaround is Slack. The PO asks an engineer. The engineer checks and responds. This loop runs multiple times per sprint, for every feature that uses a flag. It is an interruption cost on engineering and a delay cost on PO decision-making. It scales poorly as teams ship more frequently and use flags more aggressively. And it is entirely unnecessary, because the information exists in the system — it is just not accessible to the person who needs it.

What goes wrong when the PO doesn't know

The most common failure is the premature stakeholder announcement: the PO communicates a feature as shipped before it is live for all users. Stakeholders check and can't find it. Trust erodes. The PO now has to explain feature flags to a business stakeholder who doesn't know what they are, while also trying to figure out when the feature will actually be universally available — which requires another Slack conversation with engineering.

A less visible failure is the missed rollout completion. The flag goes to 100% on Tuesday. Nobody tells the PO. The stakeholder update from Friday is never corrected. Customers who asked about the feature and were told it was coming don't get a follow-up. The feature is live, but nobody external to engineering knows it. The launch moment, which product teams typically want to communicate intentionally, disappears into a quiet flag toggle that happens with no announcement.

The hardest failure to detect is the partial rollout that looks complete. A feature enabled for 20% of users will produce customer support tickets from the 80% who can't access it. Support routes those tickets to the PO. The PO's first instinct is "it's a bug" — the feature was marked Done, so maybe something broke after it shipped. They escalate to engineering. Engineering explains the rollout. The PO had no framework to interpret the support tickets correctly because they didn't know a partial rollout was in progress.

What the PO actually needs to know

The question the PO needs answered after a sprint closes is not "is the code deployed?" That's what Jira answers. The question is: "can customers actually use this feature, and if not, why not, and when will they be able to?" That question requires knowing the flag state, the rollout percentage or targeting rules, any regional or account-type restrictions, and whether there are open issues blocking full availability.

None of this information is complex. It exists in specific places in the system. What's missing is the path from the PO's question to the system's answer without an engineer in the middle. The PO doesn't need access to LaunchDarkly. They don't need to know what a flag targeting rule is. They need to be able to ask "is the payment redesign live for all users?" in plain language and get an accurate answer in return.

What actually happens between "sprint closed" and "feature live":

  Tuesday: Sprint closes. FEAT-774 "Payment redesign" marked Done.
  Tuesday PM: PR #2091 merged. Code is in production.
  Tuesday PM: Feature flag PAYMENT_REDESIGN_V2 remains OFF.
    (Engineering team practice: flag stays off until QA sign-off)

  Wednesday: QA tests in staging. Finds one visual bug.
  Wednesday PM: Bug fixed, PR #2094 merged.

  Thursday: QA re-tests. Approves.
  Thursday: Engineering enables flag for internal accounts.
  Thursday PM: PO receives no notification. Jira ticket: Done (since Tuesday).

  Friday: PO sends stakeholder update: "Payment redesign shipped this sprint."
  Friday: Stakeholder tries to find it: cannot. Replies to PO asking where it is.

  Friday PM: PO sends Slack message to engineering: "Is the payment redesign live?"
  Wait: 35 minutes
  Response: "Oh — it's enabled for internal only right now. We're doing gradual
    rollout. Should be 100% next Tuesday after we check the error rate."

  Result: PO had announced a feature to stakeholders 3 days before it was live.
  No one told the PO. Jira showed Done. Done meant nothing.

The sequence above is not unusual. It is how gradual rollouts work in practice — a deliberate multi-day process of enablement, QA, and error rate monitoring. The engineering team is doing exactly what they should be doing. The PO is completely in the dark at every step, not because communication broke down, but because the system has no mechanism to notify the PO when flag state changes. The ticket was Done on Tuesday. The feature was live for all users the following Tuesday. The PO found out somewhere in between, if they asked at the right time.

How Kognita answers the flag question

Kognita indexes repositories continuously and connects codebase state to Jira context. For feature flag questions, that means a PO can ask in plain language — "is the payment redesign flag enabled in production?" — and get an answer from the actual system without needing to know what a LaunchDarkly flag is, what targeting rules look like, or which environment to check.

PO asks Kognita: "Is the payment redesign live for all users in production?"

Kognita returns:

  Feature: Payment redesign (FEAT-774)
  Jira status: Done (closed Tuesday)

  Feature flag: PAYMENT_REDESIGN_V2
  Current production state: enabled for internal accounts only
    → accounts with role = internal: ON
    → all other accounts: OFF

  Rollout plan (from PR description + Jira comments):
    → Phase 1: internal only (current)
    → Phase 2: 10% of users — planned for Monday
    → Phase 3: 100% — planned for Tuesday, pending error rate threshold

  Not yet live for: external customers, mobile (flag not implemented in
    mobile codebase — tracked in MOB-201, currently unassigned)

  What the PO needs to do next:
    → confirm Tuesday full rollout date with engineering
    → check MOB-201 status if mobile availability is expected
    → do not announce to customers until at least Tuesday EOD

The answer reflects what the system actually shows: which accounts the flag is enabled for, what the planned rollout schedule is based on PR descriptions and Jira comments, whether mobile implementation is complete, and what the PO needs to do before announcing the feature externally. That is the information the PO was going to get via Slack thirty-five minutes later — surfaced immediately, without interrupting anyone on the engineering team.

This changes the PO's relationship with release status. Instead of operating on Jira ticket state — which is accurate about work completion and silent about customer availability — the PO can operate on system state. The stakeholder update doesn't go out until the PO has confirmed the flag is on for all users. The customer communication waits for the rollout to complete. The "is it actually live?" question gets answered from the system, not from whoever is available in the engineering Slack channel.

Final take

Feature flags are not going away. Gradual rollouts are better engineering practice than big-bang launches, and the industry has correctly converged on them as standard. The problem is not the flags — it is that the people responsible for communicating release status have no visibility into flag state. Jira says Done. The flag says off. The PO is in the middle with no way to tell which is true for a given customer at a given moment.

The fix is not asking engineering to update Jira with flag state, or building a custom dashboard, or scheduling a post-sprint "flag status review" meeting. The fix is giving the PO a direct path to the system's answer — one that doesn't require knowing the flag name, reading a targeting rule, or waiting for an engineer to look it up. When that path exists, the premature stakeholder announcements stop, the missed rollout completions get caught, and the PO can make commitments that the system will actually back up.