Who are our users and why should they use OpenFeature?

[DavidPHirsch]

I would like to step up our community outreach program and identify our primary personas, to make sure we're creating the right content and reaching out to the right communities.

I would structure each persona with the following details:

• Job title
• Who are they?
• What are their motivations?
• Job they do
• Frustrations

Please feel free to add ideas and suggestions.

[DavidPHirsch]

@lukas-reining @Kavindu-Dodan
for the moment i have identified a few profiles:

• application owner, also known as Release manager, Product Owner, DevOps manager
• software developer, or engineer
• product manager, or program manager, Technichal PM or head of product
  Any other profiles you can think of?

[lukas-reining]

Sounds good too me and I can not think of any from the top of my head right now.
I think it could be pretty valuable what @toddbaert says. Maybe some other adopters can help to get another view or ideas on that.

[toddbaert]

@DavidPHirsch This is great. We should also take time to integrate the findings/data here with the personas in the spec: https://openfeature.dev/specification/glossary#user-roles

It may be that we want to update or refine these based on the feedback.

Maybe we can reach out to known adopters and contributing companies and ask how roles regarding feature flags break down in their org?

[zellyn]

A comment about the need to segment software developers by infrastructure maturity / uptime requirements:

At Square/Block we find ourselves to be on the "serious engineering" side of a continuum. For startups and even decently mature products, it's likely that your feature flag vendor's uptime will exceed yours, so you don't need to worry about it. A lot of the vendors seem to target this segment quite heavily.

In contrast, when I talk to teams that are managing production-critical and payments-related services, their initial questions and concerns are all about uptime and how things fail:

• What happens if I lose connection to the source of feature flag data while running?
• What happens if I can't get a connection on startup?
• if the vendor is down and I need to scale up my pool of servers, how do I start a new server if it can't get the flag data?
  • what if my kubernetes cluster does periodic restarts to keep things fresh — what happens during a flag vendor outage?
• [if using some kind of flag proxy/bridge] if the vendor is down and I need to scale up my pool of proxies, how do I start a new proxy if it can't get the flag data?
• Can I bundle a then-current version of the flags into my application artifact, so I have a reasonably sane configuration, rather than falling back to in-code defaults?

[zellyn]

Roles to consider that we have inside Square/Block:

• someone negotiating contracts/pricing with an existing or new feature flag vendor. OpenFeature helps avoiding lock-in and the thread to switching
• (often the same person as above) someone maintaining the current contract, keeping track of seat counts, giving access, etc.
• an engineer/team responsible for operating the feature flag system: proxies/bridges/relays, syncing of ACLs/group-and-role-memberships to the feature editing frontend
• an engineer/team responsible for building out language-specific tooling for teams to use when building services that use feature flags
  • an engineer/team responsible for building tooling to facilitate smooth migration from one feature flag vendor to another: creation of language-specific migration facades that can talk to two different vendors, report diffs, switch the source of truth at some level of granularity (app, flag, flag label/tag)
• a product manager who wants to track rollouts of new features
• a product manager who wants an easy way to administer groups of customers for preview of new features, and uses feature flag identifier overrides or segments to do it
• a product manager who wants visibility into which customer has been exposed to which variations (for tracking, to send follow-up emails, etc.)
• an architect / principal engineer heading up "reliability" initiatives trying to reduce the number of times feature flag flips are responsible for outages

I'll probably think of some more, but that'll do for now. These aren't distinct personas, but are things we've seen.