Projects are dead, long live Products

[00:04:36] Welcome and Introduction to the Livestream

Andrew Murphy: Everybody, and welcome to another Tech Leaders Launchpad Livestream. This is a series where I get people who have mentored and coached me to share their experience, wisdom, and ideas with you. When I started being a tech leader 15 years ago, there wasn't any support—no books, podcasts, or livestreams like we have now. My guests and I have had to learn everything the hard way. Part of what I want to do here is to help you learn from the expertise around you, something we couldn't do. And so, with me today, I have Martin. Martin, welcome to the livestream.

Martin Mazur: Thank you, Andrew. Thanks for having me. And thanks for staying up in the middle of the night to get me on livestream, I appreciate it.

Andrew Murphy: Yeah, for those of you who don't know, it's 10 pm in Melbourne. Pretty late, but I’m more than happy to have a chat with you, Martin. It’s been a long time since we last talked, so I’m raring for this. You might also notice, dear viewers, that Martin is coming to us over a piece of wet string and two tin cans. Sorry, that’s the best we could do for internet right now. I suggest you watch the recording if you’re having trouble picking up anything Martin’s saying—the recording will be as full fidelity as we can make it.

[00:06:12] Martin’s Background & Why This Topic Matters

Andrew Murphy: So Martin, I’d like to start with an introduction to you—your history, your past, but also why this topic is important to you. When I put livestream suggestions together, you said this topic was especially important. Tell us a bit about your history and why this matters.

Martin Mazur: Well, history and past… I turned 40 last year. I started with computers very young, like many of my generation—when the Nintendo 8-bit came out, I was fascinated by what technology could do. But even more, I wanted to understand how games were made. I got into programming early. My parents really supported that, and it launched my career. I didn’t finish university before I was drafted into a company, working as a consultant. I delivered projects to government agencies, all sorts of clients, eventually became a partner. When I sold that company, I swore I’d never be a consultant again! But I wanted to work in a product company, so I started my own startup…and it went terribly bad because I knew nothing about building companies, products, or startups. After some soul-searching, I realized consulting—helping people and teams be great—is what I know. So I decided, if I don’t like the business, let’s try to change it. That’s how I started the consultancy Trend 37, which I was a part of for 14 years. We grew from zero to 350 employees. Now I’m a tech leadership consultant and coach.

I transitioned into leadership out of necessity. I founded and ran a company—there’s no way of saying ‘I don’t want to do leadership,’ it just happens. What I find is, I’ve always kept one foot in business and one foot in tech, and now I use that to help my clients, especially when the business and technology aren’t grooving together. The problems in internal communication always show up in the product—the user and customer can feel it. That’s why I’m passionate about this: when we talk about ‘projects,’ the focus is on delivery—on scope, budget, quality. But a ‘successful’ project says nothing about delivering user value, or solving user problems. That’s the shift we need—bring back the joy. Why do we exist as software people? It’s not to deliver on-budget, on-scope, with desired quality—it’s to solve user problems with technology, in ways that excite users. Yet so many engineers are disengaged—the work has become about finishing the next ticket or bug, not about value. We've lost the connection to the actual problems we're solving. That’s why I love this topic—I think we need to take that back.

[00:11:51] Utilization, Not Creation, is the Value of Software

Andrew Murphy: I love a lot of that. A mutual friend of ours, Richard Campbell, has a phrase—maybe he coined it, but I love it: “The value of software is not in its creation, it's in its utilization.” That focus—we’re not here to build and stop there. The value is in how it’s used, who uses it, for what, and what value it brings through utilization. That’s the lens we should use.

When I started my career, I’d not finished my degree before I got my first job—I did an industrial placement in the UK, where you study for two years, then spend a year in a company. After that year, the company wanted me to stay on, but I insisted on finishing my degree. I ended up working and studying at the same time—stressful but valuable.

Something that shaped how I think about software: my boss always had me do the job the software was intended to help before I wrote the software. For example, I was writing code for warehouse management—stock taking. My boss said, right, go do an actual stock take. That direct experience, empathy, and understanding—that’s what we lose a lot. Why do you think this is happening in the industry? Why isn’t this way of thinking more prevalent?

[00:14:56] Why Do We Lose Direct Connection to the User?

Martin Mazur: That's a great question. And to add to your story—it used to be like this. My first jobs, I spent a week with customer support, just sitting, listening to calls, watching them click around in the system we built. Any engineer who does that has a visceral reaction to seeing how your system is actually used—often so different from what we intended. It physically hurts us! It’s not until we see it that we realize how misunderstood much of our work is.

We need to bring that back—engineers sitting with users, visiting users, watching their struggles. Why did this way get lost? A few reasons. There’s a business factor—a focus on optimizing for coding time because of developer scarcity. So anything not coding, someone else handles—talking to users, testing, deployments, all pushed elsewhere to ‘maximize’ coding time. But that’s a misunderstanding of the profession. We’re paid to solve user problems, and that takes thought, exploration, and not just coding. There’s been a drive to ‘optimize’ away everything but coding, but that’s not what engineering is.

With Agile, early on, there was a customer focus—if you look deeper in the Agile Manifesto, the 12 principles are customer-centric. But even that got distorted: the ‘customer’ became the product owner; developers stopped speaking to real users. Again, a rift appeared.

What’s new this time: as product-centric/product-led organizations emerge, we’re looking at how to scale this beyond startups—how to do it with 300, 400, 500 developers. And it needs to involve the whole company, not just tech—design, product, even CEOs articulating a vision that aligns everyone. It’s a top-down and bottom-up effort this time. For the first time, I’m seeing good things happening—maybe it’ll really stick.

[00:20:20] Transitioning from Projects to Products—Responsibility Shifts

Andrew Murphy: Let’s dive deeper. You said it needs support from the CEO and the whole organization. How do people's responsibilities shift as you move from a traditional ‘software house’—say, with BAs, product owners, etc.—to a truly product-focused company? What actually changes in roles and responsibilities?

Martin Mazur: All of it is different. Management has to let go of perceived control—a lot of reporting, scope, budget, deadlines, quality. Yet even with that, projects are late and over-budget, and then the blame falls on engineers for ‘bad estimates.’ But even if you deliver everything on time, do you get the return on investment? Often not—the value wasn’t really validated.

In a product-focused organization, the CEO sets a bold, customer-centered vision for 5–10 years. The CPO translates that vision into product ranges. Product managers look at customer research, define problems to solve, and feed those into teams. The teams themselves become creative and innovative—not just building what's specced, but figuring out what actually should be built. These teams must be cross-functional.

Once something ships, teams are accountable for results—if it doesn’t solve the problem, they must iterate. Roles change drastically, e.g., business analysts become more design-heavy, project managers become more like product managers—the "CEO of the product." Leading is more about influence than authority.

CTOs and tech leads focus on technology strategy—what's new, how it solves actual user problems. Engineers must focus on user problems, not lines of code. There’s way more interpersonal, business, design, and empathy skills required. In between are the organizations that do agile well, who are closer to product-thinking, but the cultural shift can take years for more old-school organizations.

[00:28:07] Feasibility & ‘Good Crazy’—Rethinking Tech Lead Roles

Andrew Murphy: I like your point about tech leads looking at what’s just become possible. At Linktree, when defining tech roles, I said tech oversaw ‘feasibility’ - both “why can’t we do this?” but also, “what can we now do that wasn’t possible a year ago?” It’s not just about saying no to crazy ideas—sometimes, the new thing is actually what’s needed. You can take a crazy idea and break it down.

Martin Mazur: There’s good crazy and bad crazy! I heard this at a panel recently—some people are 'bad crazy,' some in the middle, and some ‘good crazy.’ The trick is finding the right crazy, the one you can actually use. Many best ideas started as 'crazy.'

Take LLMs and GPTs—every tech lead is being asked to “do something with AI.” The role is to say, “Here’s the tech—let’s check if it helps solve any of our users’ actual problems. If it doesn’t, don’t do it.” The point is tech has to be in service of user problems, not projects for their own sake.

[00:31:42] Challenges for Tech Leaders in Product-led Orgs

Andrew Murphy: For our audience—mostly current or aspiring tech leaders—what are the specific challenges for them in this product-led approach? Challenges in their mindset, skills to learn, and how they connect with the business?

Martin Mazur: Great distinction—there’s a difference between leading and managing. If you want people reporting to you, that’s more management. When I say leadership, I mean the ability to paint a vision and get people to voluntarily follow. For real leaders, this way of working actually gives you more mandate—you can paint the vision for your tech, product, or platform, and invite your team to join that journey. Passion is easier when you’re leading toward a vision, rather than delegated tasks.

The crucial leadership skills remain: empathy is still the top skill—understanding others, crafting aspirational goals, getting others fired up. Coaching is also incredibly powerful—not just formal "coaching sessions," but everyday help. Coaching is helping people find answers themselves, so they grow and become self-sufficient. It's a superpower for lazy (i.e., efficiency-seeking!) tech leaders: you invest in people, so they solve bigger problems in the future. That’s how good leaders are made.

[00:36:45] Coaching and Leading Change vs. Forcing It

Andrew Murphy: Coaching—guiding rather than telling—is so much more powerful for changing minds. Rather than making statements, you ask great questions, get people to see a new perspective, help them change their own minds. This is such an underused skill.

We’ve talked a lot about customer value, research, ensuring what we build actually solves problems. How do we do that in practice? How do we build customer feedback into software development so it’s not an afterthought? Traditional software would only get customer feedback at the end—user acceptance testing after delivery. That’s not what we want…

[00:38:38] Embedding Customer Research & Discovery (Experiments vs. Projects)

Martin Mazur: Exactly. It’s about failing early and fast—what’s the earliest way to test your hypothesis? Tons has been written about this, but basically: every team should run discovery work—figuring out user problems, testing solutions via mockups, prototypes, interviews before full delivery starts. Discovery and delivery run in parallel, not sequentially.

Teams should dedicate some hours each week to ‘discovery’—running experiments. The value of an experiment is the learning, regardless of ‘success.’ Most experiments won't go as expected, but that’s valuable knowledge for the next attempt.

A key lesson: users are great at describing their problems and pains, but rarely at solutions. Trust the problems and pains, not their proposed solutions. If you build exactly everything every user asks for, you end up with a mess—think of over-complex banking software filled with rarely used features.

What makes a great product is understanding the user’s problems and creatively solving them, not blindly fulfilling user requests.

[00:43:03] Centering Value Over Features—MVPs to MVEs

Andrew Murphy: Value is the unifying thread here—a true product approach puts value at the core of every decision, from which experiments to run to what features to build. It guides everything. Both time-to-implement and value are hard to assess, but without trying to assess value, we can’t make smart decisions.

At Linktree, I tried to shift us from “minimum viable product” (MVP) to “minimum viable experiment” (MVE). Instead of asking “what's the smallest product we can build?”, ask, “what's the smallest experiment we can run to validate value?” If something takes more than a few days to build, we should be able to say clearly what value we expect, and if not, we run an experiment first.

Martin Mazur: For the real problems, useful solutions tend to emerge anyway. Funny enough, in my early tech lead days, so many projects were about porting Excel spreadsheets to the web. I used to hate it, but looking back, those Excel sheets existed because a real user problem was solved—someone did their own experiment, and it worked so well others reused it. Eventually, it got too big and engineering was called in to scale it. By then, every requirement was locked in—there was no more discovery or user research, just porting.

With those, the learning was already done (maybe even too late). But at least validation happened—unlike projects that just deliver a spec and cross it off.

[00:48:06] Retrospective—Why Custom Tools Emerge, and the Role of Engineering

Andrew Murphy: I’ve had the same with Access databases—when you’re asked to just replicate an Access database in something scalable, all the learning’s been done. It’s useful, but takes a lot of the juice and joy out of development. Ideally, we'd get involved earlier...

Martin Mazur: Exactly—that’s the real problem. The tech team got involved too late. As soon as validation happened in Excel, engineers should have come on earlier to prevent the ‘big ball of mud’ scenario. But it’s still better than many projects—at least real user problems were solved.

[00:49:36] Wrapping Up—Upcoming Events and Ongoing Work

Andrew Murphy: We’re approaching the top of the hour, so let’s close out with what’s coming up for both of us. I’ve got a livestream soon with Nisha, an excellent human being—we’ll talk about supporting your team through life-changing events. Leadership is not just about delivery but about empathy when life happens. Follow me on YouTube, LinkedIn, or Twitch for notifications, or subscribe to the newsletter for email alerts. And, if you want a chat, scan the QR for a 20-minute conversation—I love these chats, so please do book one!

Martin, where can people find you and what have you got coming up?

Martin Mazur: My blog is at Mazur.today, which will soon have a new version. I’ll be live at Developer Week in Germany, NDC Oslo, and just confirmed for Auradev in Malmö. Feel free to reach out if you’re at those events—or book a chat with me, just reach out on LinkedIn. I also plan to start a podcast with EBA Lauren (a PhD in management): “Leading in Flux”—two very different backgrounds, discussing leadership in uncertain times. Our pilot is up; if you want episode one published, bug me on social!

Andrew Murphy: Everybody bug Martin—I want to hear that podcast! I’ve got a lot of travel coming up and need more to listen to. That’s the downside of living in Australia—no one comes here, we all have to come to you!

[00:54:34] The Challenges of Podcasting and Closing Remarks

Martin Mazur: If you know anyone who wants to do podcast post-production for hugs and fame, send them my way. Post-production is the hard bit!

Andrew Murphy: That’s why I do livestreams instead of podcasts! You can just go live and skip the editing.

Martin Mazur: Sneaky, sneaky!

Andrew Murphy: All right, thanks again, Martin, for joining. Loved this conversation. For everyone else, see you next time—make sure to subscribe or follow wherever you are. Good evening, day, morning, or night, wherever you are around the world. See you later.

Martin Mazur: See you!