Why It's Important to Focus on User Workflows and Not Features

EventCatalog started as a workflow, not a feature. Engineers were trying to answer a simple question: what events exist here, what do they look like, and what’s the architecture? To get the answer they were digging through GitHub, opening Confluence pages that went stale two quarters ago, and asking around in Slack. Hours gone, every time, and nobody wrote any of it down.

Once you frame that as a workflow instead of a feature request, the answer gets a lot more obvious. Why don’t we sync all the schema registries and put them in one place? I didn’t invent that. It’s just what falls out when you look at a job people are already doing badly and ask where the time is going.

And then I drifted. I’ve spent real time on an EventCatalog DSL, a custom language, graph things, all technically cool and all completely disconnected from a workflow anyone was losing time on. AI has made that drift cheap, which makes it more dangerous. I can have an idea and ship it the same day now. Most of the time I’m just adding bloat. Here’s what I keep coming back to.

Start With the Workflow, Not the Feature

• Companies really only care about three things: saving time, saving money, and making money. Everything else is a nice to have. If your workflow doesn’t ladder up to one of those, it’s going to be a hard sell no matter how good the feature is.
• Most software is a workflow. People buy software to replace a workflow they already have or to create one they don’t. So the question worth asking is simple: what am I replacing, or what am I creating? It’s a much easier way to think about value than throwing features at a product.
• Work backwards. Start with the job your ICP does today, find where the hour goes, then figure out which feature removes it. Going the other way round is how you end up with a product full of things nobody asked for.
• Ask what your product replaces, not what it adds. EventCatalog replaced a Confluence page and a GitHub hunt. That’s a much clearer pitch than a list of capabilities.
• If you can’t say which minutes or pounds you’re giving back, you’re probably building for yourself. Something to be honest with yourself about.
• Think about how many workflows you’re actually trying to own. One workflow end to end can be a whole company. Depends on your niche, but owning one properly usually beats touching five badly.

How to Find the Workflow

• “Walk me through your day.” Get them narrating what they actually did last week, step by step. Not what they’d like to do, not what they think good looks like. What happened.
• Treat every feature request as a symptom and ask why. Someone asking for a filter is telling you something about a workflow. The filter might be the answer, but the workflow is the information.
• Look for the workaround they built. The spreadsheet, the pinned Slack thread, the Notion page one person maintains out of goodwill. That’s a workflow they cared about enough to hack around. Go there.
• Ask what’s frustrating about how they work today. Frustration is specific and it’s real. “What features do you want?” gets you a wishlist. “What annoyed you this week?” gets you a roadmap.

The Trap I Keep Falling Into

• New tech is the strongest pull there is. “What if this could do that?” is exciting and it feels like product work. It usually isn’t. I’ve built things I was proud of that nobody touched.
• AI removed the friction that used to protect you. An idea can ship the same day now. Shipping speed is not evidence that the thing was worth shipping.
• Cool is not the same as useful. Before you build the clever version, ask what it’s replacing and why anyone would leave what they already use for it. If you can’t answer that, it’s bloat.
• Be willing to strip things back. I’ve cut work I liked because it wasn’t tied to a job anyone had. That’s not failure, that’s the iteration doing its job.

Make Your Roadmap a List of Workflows

• Rewrite the roadmap as jobs, not features. Instead of “add search”, write “find out what events exist without opening GitHub”. Same work, completely different filter for what counts as done.
• Judge a release by the steps it removed. Shipping five features that each do 60% of a job leaves your user exactly where they started. Finish one workflow instead.
• Go and look at what’s unused. It’s telling you something. Stripping back is as much product work as adding, and it’s the part most of us skip.
• Think about what the market looks like in workflow terms. Which jobs are unowned? Which ones does everyone half-solve? That’s usually a clearer map than a competitor feature matrix.
• This gets easier over time, and mostly through scars. Every unused feature I’ve built taught me more about the workflow than the roadmap ever did…

Extra Resources

• How to Perfectly Position Your B2B Brand in 34 Minutes - Recommended watching. It’s a talk about B2B positioning, but a lot of it lands on why workflows matter more than features when you’re working out what your product actually is.