Years ago, I attended a training session at a bank I was working for, which was undergoing an agile transformation. The session was called Elephant Carpaccio, and its purpose was to help delivery teams understand how to slice functionality into user stories. The term was coined by Alistair Cockburn, one of the co-signers of the original Manifesto for Agile Software Development in 2001. It demonstrates that even something large - like an elephant - can be sliced into small, manageable pieces.

Around the same time, I heard the terms “steel thread” and “thin vertical slice” in relation to the same concept. I went on to refine and apply the steel thread concept to successfully deliver many products.

Steel Thread versus Thin Vertical Slice

Whenever I explain the steel thread approach to a development team, someone pipes up and says “oh, that’s just a thin vertical slice”. But what is a thin vertical slice, and why is it vertical?

It’s vertical because it’s based on a conceptual architecture diagram that shows the different systems (UI, application, data, etc.) as horizontal layers. Building a minimal piece of functionality that touches each layer means slicing vertically through the systems.

A thin vertical slice

The problem I have with the thin vertical slice analogy is that, by framing the story-splitting process in terms of architecture and systems, it can constrain the team’s thinking to a pre-designed solution - either an existing one or one that has to be designed to some extent before starting to build. And for a product manager, it requires a solid understanding of the architecture that they might not have developed yet.

So what’s a steel thread?

While I can’t find the person who coined the term steel thread in a software context, it’s said to have originated in bridge-building, where a single pilot cable was slung across a river and then used as a guide to pull subsequent cables across, until eventually you have a complete bridge. I can’t verify this, but it makes sense, and I love the idea.

Surprisingly the concept was so little known that it was deleted from Wikipedia in 2013 because "Steel Thread" was considered “a colloquial term and not notable within Software Engineering”.

For me, the steel thread is the bare minimum functionality you need to build an end-to-end user journey that touches all parts of the system. Just like in bridge building, this gives you a stable base on which to construct useful functionality.

Differences between a steel thread and a thin vertical slice are:

• A steel thread is the first end to end piece of functionality for a new product or feature, while a thin vertical slice is a way of writing any user story.

• A steel thread is designed and written in terms of a user journey, not system architecture.

Ideally a steel thread would be able to be completed in a single user journey, but in my experience it’s usually an entire epic - the first epic tackled by the team when starting a new initiative or product.

Why do a steel thread?

The benefits I have seen from using this approach include:

• It allows you greater flexibility in prioritization.

• It gives you a faster path to MVP.

• It makes it easier to demo progress to stakeholders.

• It gives the team a deeper understanding of the user journey.

An Example

I recently worked with a team to build a product that extracted data from a specific type of document. While we had an existing product, this was essentially a complete rebuild - the changes we wanted were significant enough that updating the existing codebase would have taken longer and caused more headaches - so we started from scratch.

(An aside: I love this as a PM - it gives you the freedom to make the product right without having to deal with seemingly bizarre decisions made long ago, probably for perfectly good reasons - and I think the engineers feel the same way. Re-building an existing product from scratch takes less time than you’d think.)

There was no third-party service that worked for these types of documents to the accuracy we needed, so we were building our own AI engine to do it - which was the riskiest part of the build.

The user journey (somewhat simplified) went like this:

When prioritizing stories for our steel thread, we either hardcoded parts of the process, or left them out entirely. We ended up with an end-to-end product that displayed a single page.

Not very useful, right? But it was something we could demo, and gave us a solid base on which to target the highest-risk part of the build: the AI engine the data science team was developing. The next iteration looked like this:

Now we had an end to end product that extracted data from a single type of page and displayed the numbers extracted on the screen. Whilst we still had plenty of work to do, this proved the concept, and not only could I demo it to stakeholders, I also demoed it to a potential customer - who signed a contract on the back of it.

Conclusion

So that’s it - my view on the steel thread approach to product delivery. I hope it helps you create amazing products. I’d love to hear from other product professionals who have tried this approach - did it work for you?