The first "Workflow": MVP for "Creating a new feature"

[lharries]

Owner: @EDsCODE (team experimentation)
Decision to be made: Should we build this in Q1 as part of team experimentation?
Decision date: 7th December 2022

@annikaschmid could you work with the team to add some more detail?

[annikaschmid]

Thanks for writing this up, @lharries! I think for the purpose of communicating what the feature is about, the vision is great.
There are a couple of things we need to think through a bit further once we start with the feature, e.g.:

• I think you wouldn’t necessarily have to choose between auto-rollout and a/b test. You could start with an a/b test and roll out the feature if the a/b test was successful
• Retention is a bad metric to pick for a feature test, because it’s a lagging indicator. In this case, I don’t think it would lead to good results
• In this case, Sarah made changes to the feature after it has been rolled out. Would she create a new workflow for this? Probably not, but maybe she still wants to roll out changes with a schedule. I suppose the user can decide on a case by case basis whether a change requires a new flag or not (like today)

[lharries]

@annikaschmid another extension that we might want to think about (for the longer term rather than next quarter) - you mentioned the idea of "Feature management", what if Feature Management was a 1st class feature in PostHog? What would this look like? (Feel free to leave for now if you don't think it would be useful)

[EDsCODE]

Do we think this feature will be applicable for existing users or are we hoping to attract a new set of users? If existing, is there evidence that current users would be interested in working this way. For example, are event taxonomies and feature flags decided upon pre feature implementation or post?

If not existing, is there some research we can do to get information on how this plays against the existing popular workflows among product engineers? I would assume there's some level of tooling or assortment of tools that are used to achieve this product planning -> implementation

[EDsCODE]

The promise for an opinionated workflow makes a lot of sense. If we can properly automate the pre and post implementation for engineers this would be a significant value add.

**I will asterisk that adding opinionated features like this could get confusing from a marketing standpoint. Most of the product is fairly unopinionated "here's analytics tooling you can use to understand your users" while this feature moves in the direction "here's a product process". This might also mean that we have to sell teams on the fact that this product process is better than what they already have/is the ideal process to start their product with

[lharries]

Great point.

Could we give them the tools to customize the create a new feature workflow? And maybe even create their own workflows

E.g. they can edit the schema which decides which graphs and session recordings are on the dashboard, and how the feature flag are setup. We could use the new JSON based stuff that Marius is making with some template variables

This way we can give them some starter workflows but they can also edit it or create their own to suit their processes

[EDsCODE]

Simple reminders like this would be great

[neilkakkar]

This is definitely an interesting idea!

I don't think we should build this right now though as I don't think we're ready for opinionated workflows on top of the core functionality. Here's how I'm thinking about this:

1. The value-add of any core feature (which enables something new that wasn't possible before / was frustrating / too hard to do) is more than any feature that explains how to do those things (i.e. workflows).

   For example, I'd be a lot more happier (as a PostHog user) if we built JSON flag support this quarter, rather than a workflow on top of existing features.

2. Well, (1) isn't true in the absolute, and I think there will come a point when workflows can help guide users in the right direction when it's easy to get lost in the product. This makes sense when there's a significantly big chunk of users who want to do things the same way but aren't able to for whatever reason. The cost of these workflows is the same as any other opinionated flow: we make things hard for users not using that workflow, who then end up not using the workflow at all.

   I'm not quite sure how people use flags & what workflow would makes sense (I'm not convinced the above-mentioned workflow is the way to go), so I'd propose gathering this data by building the blocks of core functionality that the workflow demands but isn't possible right now, without actually building the workflow. So, it's something like breaking down what we build into:

   1. Reminders to check statuses of flags X time from now.
   2. Ability to generate a customisable recordings playlist for flag & notifications/slack when these are > X.
      .. and then talking to users to figure out which parts of flag features they use the most (& also raw data), to come up with a workflow.