Hello friends, and welcome to the Product Fundamentals podcast: The Preamble.

This podcast is a new project, dedicated to helping product people of all sorts to build the fundamental knowledge – the background context – needed to be good at our jobs.

When I say product people, I’m not just talking about product managers. Building and launching software products is a team sport, and it works best when PMs as well as software engineers, designers, researchers, testers, strategists, marketers, everybody has a shared foundation of knowledge. We need more than just best practices to succeed; we need real, factful knowledge about the world. I want to do my part to build that common foundation.

And the way that we build software together really is peculiar. Every company is a little different, but there’s a strong chance that if you work in software, the way you work is something like this: 

• You’re in a team of 4 to maybe 10 people,
• Your team is “cross-functional”, meaning there’s a mix of different roles in it
• You set quarterly or semi-annual OKRs to act as goals for your team,
• You have a daily standup meeting and you structure your work into regular one or two week sprints,
• You have recurring retrospectives with the team to try to improve how you work,
• You have a backlog of work items to be done (which may well seem endless), and you track ongoing work on something like a kanban board, and finally
• Your big projects are defined by business-friendly requirements docs and tech-heavy spec docs.

This structure is… weird. But I bet at least the broad strokes of that approach sound familiar to most modern software people.

But equally, I bet that sounds pretty foreign to almost everyone outside of software. As best I can tell, accountants, academics, lawyers and architects – all manner of other professional “knowledge workers” – don’t work like us at all.

This reality raises the obvious question: why? Why do we build software in this weird way today? How did we come to do it this way?

We’ll come back to that.

When I started my product management career, about 10 years ago, there were few training boot camps or rotational programs. Like a lot of people, I just jumped into a startup and faked it until I made it. I read lots of books and blogs about how to be a PM, and I tried to absorb everything that the smarter people around me were doing and saying.

That meant that besides the best practices and the rhythm of software work, I also absorbed some normative judgments that may sound familiar to you too. I knew that “Agile” and “Lean” were good words, good things to be, and I knew that the opposite of Agile was called “Waterfall,” and that Waterfalls are bad. You never wanted someone calling your project “waterfall-y.” But other than some vague intuitions, I couldn’t really tell you what that meant. I just knew that sprints were good, waterfalls were bad, and calling yourself a Scrum Master made you a big dork.

But why were the good things good? Why were the bad things bad? I couldn’t have given you any sort of satisfactory answer.

I’ve taken to calling this collection of work practices and normative claims “the muddy Agile consensus,” because while we all agree that Agile is a good word, the overall scheme is not entirely clear or coherent, and I suspect that few of us have solid reasoning for each of the individual bits that we follow.

So for my own benefit, I decided to tear down that shambles of accumulated intuitions, and get some clarity. More than just the labels and their meaning, I wanted to understand the how and the why. How did we come to work this way, and why do think this way? Is this way stable? What does the past tell us about what could come next?

The first season of the Product Fundamentals podcast is my attempt to answer those questions.

The story I’m going to tell this season is a history. I won’t tell you “how to be a PM” or what a good spec doc looks like, or how to run your team. There are plenty of people better equipped than me to talk about best practices. 

Instead, we’ll cover the historical, economic, cultural, and technological forces that combined and led us to make software in the weird way that we do. It turns out that the way we work was driven by a grab bag of innovations and ideas from before the Industrial Revolution through World War 2, from post-War reconstruction and from the Space Race, and that’s all before we get to the personal computer, the dot-com bubble, a fateful meeting of burned-out consultants at a ski resort, or the economic legacy of the Great Financial Crisis. It turns out, there’s a whole lot of history wrapped in how we work.

My hope is that understanding the path that got us to now will leave us better equipped to make smart choices, to work more effectively, and to navigate the upheaval that is coming – and is frankly always coming – in our wild industry. 

If that sounds interesting to you, then I invite you to subscribe to this podcast feed. You can find episode transcripts, links to some supporting sources, as well as ways to reach me on the podcast web page at prodfund.com. I’d certainly love to hear from you.

So with all that said, please join me for our next episode when we start at the beginnings of professional software, catch the dawn of exponential growth, meet the first summit of “software engineers” at NATO, and discover just what “Waterfall” really means.

Thank you for listening.