Workflows. They’re at the core of most business systems. And they have a common shape:
- gather data (from humans and/or various other systems),
- process the data (often in some new and interesting way in order to add value), and then
- make the processed data available for some business function in another system, in a report, or through an API or MCP.
There are usually more than 3 steps when you draw it out with boxes and arrows, but they tend to follow this basic shape.
When it comes to building one of these workflows, the most obvious and natural way to do it is step-by-step, left-to-right. That also happens to be the worst way to do it.
Building a workflow left-to-right delays value and learning. If you’re lucky, everything works at the end. More often, you discover things as you move towards the right side of the workflow that make you want to rework some of the things to the left. Even in the best case, there’s no incremental value during development. It all comes at the end.
There’s a better way.
First, identify what part of your workflow is new and complex. Where’s the real value that makes the workflow worth building? It’s usually in the data processing or presentation. If you have a workflow diagram, draw a box around that part.
Next, list out all the things there are multiple variations of in your workflow. Typically, that’s entities, data sources, and business rules. What is there many of? List them out: “many library branches,” “many patrons,” “many books,” “many filters on search results,” etc.
Finally, narrow each of those “manys” to one or a small number of representative examples to get a thin slice through the interesting part of the workflow. Just one data source to start. Just a subset of the data. Only the most common variation on the business rules. Just one way of presenting the data.
Of course, you won’t stop with that thin slice. It’s almost certainly not enough to ship. But it’s a much better place to start than, “gather all the data but don’t do anything with it yet.”
Once you’ve built that first thin slice, your workflow works. And then, every slice after that makes it work for more and more cases.
Recently, we’ve been working with a lot of teams who have delivery working pretty well. Once they decide to build something, they have a good process to get it built. Some are even seeing huge bumps in productivity as they grow their skills with AI development tools.
But with backlogs organized around technical tasks, components, and workflow steps, that delivery capability isn’t really turning into a faster flow of value and learning.
So, we’ve been offering a workshop to help cross-functional teams learn to shape their work in vertical slices of value at every level of detail. We spend two days working hands-on with practice examples and the team’s own work. At the end, teams know how to find thin, valuable slices in whatever work comes their way.
One participant in a recent workshop put it this way: “This training should be given to all our product and devs.” Another described the workshop as, “super engaging, very interactive, and packed with practical use cases we can bring back to our teams.” Another shared how, when they practiced the techniques they learned in the workshop, an item that seemed huge “ended up being incredibly simple to break down.”
Check out the details about the vertical slicing workshop on our website, and click the Contact link to schedule a free consultation to discuss whether it’s a fit for your team.
Last updated