More agile, and if anything, we've distilled it down to just creating multiple feature lists for each segment of the roadmap (MVP, v1, v2, etc). We often use user stories or flows to help craft the feature list, but the user flow become fairly inconsequential afterwards, as we focus more on real user feedback once the product is out/being developed.

People tend to get caught up on personas, when it's really just a practice of getting to know your customer (if you already didn't have one in mind from observing the initial problem). But people also get caught up on adding features that aren't necessary to the immediate flow (edge cases). Having a persona in mind and creating a flow validates the features you choose to move forward with, and eliminates any extra stuff for the next iteration.

It kinda seems like a merge between Agile and Gherkin at the end of the day, where we establish scenarios and flows, but focus more on keeping it concise and feature-driven (as opposed to process).

For example:

We start with a simple list of major website features (MVP), then a subset of features that would require.

Then we move on to a user flow, to see how the user will access each feature on the website and ensure they have a smooth journey.

From there we create a Trello/Kanban with lists containing various stages of the product lifecycle and organize the features from there based on priority

---

I use Gherkin syntax moreso when I'm writing an app spec for myself or other developers. I can ensure I'm considering every part of the process and each individual moving cog in the machine. It drills the app down every single screen, every single feature, and all the different states. This is more like README-driven design (or documentation driven design).