The Product Thinking Framework

Tom Barber (00:00)
Hi folks, here's something that will probably sound utterly crazy at first, but your engineering team is a product. And the way that you're probably running the team right now, that's like building software about ever talking to the users. I'm serious though. If you think about it, was the last time you asked your engineers what their biggest pain points were? Not a performance review, not a one-to-one trying to impress you. I mean, like really asked and dug deep into what their...

what their pain points were, what their problems were, and what slowed them down. And this is the way a product manager would ask a customer, of course. Now, most engineering leaders tend to spend their entire careers treating teams, well, like teams. And so, when it comes to resources, headcount, that type of thing, but what if we're getting this completely wrong?

What if the techniques that we're using to build these great products are exactly what we need to build great engineering organizations? And so that is exactly what we're to dive into today. I'm Tom Barber, and this is Engineering Evolved.

So welcome back. We've got another pack show for you today. This is episode three of Engineering Evolved. Like I said, my name is Tom. And this is the show for engineering leaders who want to stop managing and start actually building. And today we're talking about something that I call the product thinking framework, which is just a different way to approach engineering leadership. And

Once you've seen this, hopefully you can't unsee it. You'll start noticing every time you're treating your team like a product versus treating them like a cost center. And most companies do this wrong. So before we dive in, quick reminder, if you're getting value from this podcast, the best thing you can do is share this with another engineering leader who's struggling with the same challenges. We're building something different here and I need your help spreading the word. So with that said, let's get into it.

So let me tell you about a B2B company that I was working with a few years ago. Great team, smart people, but they were absolutely like drowning. Deployment took days, their test suite took four hours to run, and every time they wanted to add a new feature, they had to navigate this architecture that nobody fully understood. So the obvious solution that came from the VP of engineering at that time was that we needed to hire more people. Does this sound familiar?

But as a company, they would never ship a product without doing customer research. They had product managers who lived and breathed user interviews, and they had designers that were running usability tests every week. But when it came to their own engineering team, they just threw bodies at problems and hoped for the best. And they're not unique in that fact. And so it was like trying to watch someone improve a website by adding more servers who ever looking at the code.

And I see this everywhere. see this constantly engineering leaders making decisions about tools, processes, team structure, without ever really understanding what their engineers actually need. They pick the latest hot framework because it was on Hacker News. They mandate agile practices because that's what the consultant said. They restructure teams based on org charts instead of actual work patterns. And then they're shocked when nothing improves. And so...

You know, the uncomfortable truth is that most engineering leaders wouldn't last a week as product managers. They get fired immediately for, you know, shipping features that nobody asked for, ignoring the customer feedback and making decisions based on what sounds cool rather than what solves actual problems.

Now...

Some of you are probably already getting defensive. Engineering is different. I do get it. I do get that engineering is not the same as releasing a product. And there's constraints from a technical perspective, scale perspective that you have to work with. And there's also a long-term goal here that you're trying to work towards. And you can't just pick up everything that engineers want.

Of course that is right. Engineering is different, so is enterprise software, healthcare products, developer tools. Every product, every product that you interact with has constraints, has technical debt and long-term architectural decisions. the product managers who are successful in these domains, they don't ignore the constraints and they work with them and find creative solutions and they prioritize ruthlessly.

and they deeply understand their users. And that is exactly what we're trying to do with our engineering teams.

Of course, the uncomfortable truth is it will probably get worse before it gets better. And so we're going to look at the different pillars for product thinking. Pillar number one is product discovery for engineering. Product managers don't start by deciding features. They start by understanding the problems. How do they go about doing this? Now, of course, they talk to users. They observe behavior. They find patterns in the users and behavior.

They identify like actual critical pain points and only then they decide what to build. Now that is a regular, you know, go around for product managers, product owners, product researchers. And if we start to apply some of this, you'll start to see both, you know, changes in performance and morale.

Now, if you wanted to apply that to your engineering team, of course, your engineers are the users. Their workflow is the product, and most engineering leaders are shipping features to their team without any discovery at all. Let me give you another example. Team wanted to implement mandatory code reviews, which is a good idea. Industry best practice catches bugs, shares knowledge, team understands things better.

But the thing that they didn't know, senior engineers were already doing informal code reviews. They've been doing it for years. The problem wasn't that the code was being reviewed. The problem was that the review feedback wasn't being documented. So the same issues kept coming up. Now, like what you do with a code review is down to you as an organization. But if you've just got people clicking through and saying yes, like regularly, you're going to see the same stuff come up because people work in silos. Now, if they've done product discovery,

if it actually taught to their engineers about their code quality process, you know, they would have built something completely different, maybe a lightweight documentation system, maybe a style guide, maybe a linter that caught common issues automatically. Instead, they mandated PR reviews in GitHub, which added the bureaucracy that nobody wanted, slowed down the existing informal process and creative resentment, which is classic example of building a feature that users didn't ask for.

So here's an action item for product discovery. Like set up an engineering office hours once a week. Sounds good. Block off an hour where any engineer can show up and talk about what's slowing them down. Now I've done this in a lot of places and it's super useful. It's not a retrospective, it's not a standup, it's not a formal feedback session. It's just open time for people to turn up and have a chat about what their common problems are. Because it's a good way of sharing knowledge, understanding, and...

pain points throughout a team. Here's the key, you're not here to solve problems, you're here to discover them, take notes, like ask the clarifying questions and say, tell me more about that. And how often does this happen? And what have you tried already? And like, you know what you'll discover off the back of this, the problems your engineers complain about these sessions will be completely different from the problems you think they actually have. And that's the gap where you're

or your productivity is hiding. As an engineering leader, you're trying to solve problems through gut feel and not through like concrete feedback. And I had like one, I had one client a while ago who discovered through these sessions that their engineers were spending four hours a week fighting their staging environment. Multiply that by a team of 15 and you're losing more than a full-time engineer to infrastructure problems. But the leadership had no idea because nobody asked.

And so product discovery isn't complicated. It's just talking to your users, but you actually have to do it and you have to do it consistently and with genuine curiosity without preloaded solutions, because you want people to be open, honest, and talk to you on a level rather than trying to appease you as an engineering manager.

So now we're going to move on and we're going to talk about the second pillar, is customer empathy and how customer empathy can work well with an engineering team. So in product management, customer empathy means deeply understanding not just what customers say they want, but what they're really trying to achieve. It's understanding their context, their constraints and their emotions. Now for engineering leaders, this means understanding what it actually feels like to be an engineer on your team, which seems obvious.

but not what you remember it feeling like when you were there five years ago, what it feels like right now with your current systems and processes because they change frequently. And so that level of feedback is super important. Here's a diagnostic question for you. When was the last time you personally went through your team's development workflow? Like actually sat down, grabbed a ticket, checked out the code, made a change, ran the tests and then deployed it. And if your answer is like more than

six months ago or worse something along the lines of I don't remember, you're making technical decisions without customer empathy. And this is like a product manager designing a checkout flow without ever trying to buy something from their own site. It's malpractice. You want as a product manager, as a product owner, those people to understand exactly how the product works. They should know it inside out. They should be able to build all the things, use all the components in there to understand what it does.

As an engineering manager, you also need to understand how your workflows work, how the tooling that works around them works, what the IDEs in use are, how that interacts with the version control system, all these types of things so that your engineers have a good grasp of the process. But so do you when you ask the questions and you're not just coming at it blind. Now, I worked a while ago now with a CTO who was adamant that their test strategy was great.

And they had, you know, the Holy grail of 80 % code coverage. had CI, CD, and they were doing everything right. So I asked him to pair with one of his engineers for a day, just shadow them and watch them work. And they discovered from that, that the test suite took 45 minutes to run. It was flaky. So engineers had this workflow where they push code, go get some coffee, come back. And half the time the test failed because of some network issue.

So they'd restart them and go get more coffee. Again, I don't think this is unique to this organization. And the CTO had been dragging about their test coverage whilst his engineers were spending two hours a day waiting for flaky tests. had all the metrics, but he didn't understand it from an empathy perspective.

So here's your action item for customer empathy. Once a quarter, spend a full day as an engineer on your team. Don't manage, don't go to meetings, don't do strategy, pick up a ticket and ship it. Use the same tools they use, go through the same processes, feeling the same friction. And my guess is you'll probably hate this. It will feel inefficient. You'll think I don't have the time for this, but this is exactly, exactly why you need to do it.

Because every minute you spend frustrated by your development workflow is a minute you'll understand why your team is slower than you want them to be. And more importantly, you'll stop blaming them and start fixing the systems.

So moving on to the third pillar. The third pillar is the MVP approach to infrastructure. And this is where product thinking, if you come from a product background, and I sort of like flip between the two where I do some product management stuff and I do some engineering management stuff. And this is where like that product gets really interesting because engineers and especially senior engineers love to over engineer infrastructure.

We love to build for scale that we don't have. We love to solve problems that are theoretical. And we love to create flexible systems, massive air quotes, that handle every future possible scenario.

It's like a product manager who wants to build every feature before launching, except worse because infrastructure decisions are stickier. They're harder to reverse. If you go and build an infrastructure for a product and then want to change that up later, it's a much harder task than figuring it out at the front, up front, trying to build for what's actually in front of you right now. And when you apply...

product management style thinking to infrastructure, it changes your approach. Instead of asking, what's the perfect architecture for our future state? Fair enough. You ask, what is the simplest thing that could work right now and what will that teach us? Like, let's keep it simple. This is MVP world. So.

If you were thinking about microservices, for example, and you've got a microservices architecture, we're going to break that into 15 services, it's going to take many months and they have like, you you end up with architecture diagrams that look like flight plans because of the complexity and the networking and the different CI, CD processes and deployment architecture, everything that has to go with it. And so then you ask, well, what problem are you trying to solve? And

quite often in microservices, there isn't a cohesive answer. It's just that's what people are trying to build towards because it's a hot topic and everyone's doing microservices. So we've done this before and we've run experiments in different scenarios where you take a single feature, for example, and extract it into a separate service. Let's say we take a notification system. One service, like a week or so is

piece of work. And what you then find is the complexity from a deployment process, the monitoring, the interface boundaries, the database patterns, all of that has to change because you've just gone and changed one service. And so if you'd then gone and done that for everything, you'd then spent a whole amount of time doing all this extra engineering.

and then found that all the wrapping around it isn't going to work. And so you then you've got to engineer that as well. And so this is where MVP thinking applied to infrastructure comes in. So again, if you're thinking about something like microservices, just think about the extra wrapping that has to go around this because this is, you know, product thinking at the end of the day. Do you need it? Can you MVP it?

So here's another action item. Let's look at the roadmap right now. Find the biggest infrastructure project you have planned and now ask what's the smallest experiment we could run to validate this direction. Not what's the first phase, not what's the MVP version of this full plan. What's the smallest thing as an organization that would teach you if you're going in the right direction.

cut your in half, cut your plan in half again, cut it in half again. You're looking for something that you can finish in a couple of weeks that will generate real feedback. And most of the time you'll discover that these assumptions are wrong and that's not a failure, that's success because you've just saved yourself months of building the wrong thing or maybe the right thing, but scoped slightly differently or architected slightly differently. If you can do these things on a small scale before trying to apply them to large scale changes,

Your engineering team will thank you for it in the

Okay, so we've covered the three pillars, but here's the thing. These aren't tactics. they require a fundamental mindset shift. And when you start treating your engineering team like a product, you'll start to stop thinking of yourself as a manager and start thinking of yourself as a product manager. And that changes literally everything. You're not building features, you're solving problems. Product managers,

don't fall in love with features. They fall in love with problems. Their feature is just one possible solution. And so this is the same with your team. You're not building an agile transformation or a microservices architecture or a DevOps culture. These are the features and they may be good features, but that's not the point. The point is what problems are you actually solving? Are your engineers sort of slow and why?

Are they shipping bugs? Why are they burning out? Why get obsessed with the problems and hold your solutions lightly. If microservices architecture makes it easier for your engineers to deploy some stuff, then that's great. If your test suite is super optimal and removes all the bugs and it takes a little bit extra to make it work. But the bugs don't get shipped. And so everyone ends up with a lighter workload because you're not fixing things or fighting fires. And that's also great.

But make sure that you understand that the architecture that you're building is there to solve, in some ways, you know, human problems.

I worked with an engineering VP once who convinced his team they needed to adopt Scrum. And this isn't a new one. Everyone tries to adopt, I can't speak today. Everyone tries to adopt Scrum. You'd read the books and been to conferences, et cetera. And this was obviously, gonna fix everything.

But when we dug into the actual problems, not the symptoms, but the root causes, we found that his team's biggest problem was unclear priorities. have different stakeholders, we're giving different conflicted directions and engineers didn't know what to work on. Again, not unique in any sense, you know what, solve that. And it was not Scrum. Because that comes with all the extra...

you know, stuff that gets bolted on around the side. What it actually was was a simple prioritization framework and weekly stakeholder sinks. And we never touched their development process at all. It was just a communication issue. And if he'd approached this as a product manager instead of a methodology evangelist, he would have discovered that in week one. Instead, he'd wasted six months trying to force Scrum onto a team that didn't need it. And...

Okay, you might say it's scrum-like, you might say that it's heading in that direction, and maybe it would end up there. But at the same time, just spending some time to tweak the processes or make sure that everyone feels comfortable and confident in what they're building doesn't involve you having to then build out a whole set of sprint methodologies, retrospectives, all that type of stuff to make it work.

And here's another huge mindset shift. Good products are never finished. They're constantly evolving based on user feedback and changing needs. And your engineering team is the same way. You don't install a process and move on. You iterate constantly. And as your team grows, these stresses and strains will get pulled in different ways and the ways the assumptions that you had before may not hold true all the way through into the future. And this is why engineering transformation initiatives fail so often.

They're run like construction projects. There's a plan, there's an execution phase, there's a completion date, and then you're done. Of course, you're not done. Your team isn't a building, it's a product and it needs ongoing product management. So this means you should always have a backlog of team improvements. You should be running regular discovery sessions to understand new problems. You should be shipping small changes frequently rather than big transformations rarely. Think about it.

Would you ever let your product go two years without an update? Of course not. Why would you ever let your product go two years without an update? It would get stale, things would stop working, it would be hard work. So why would you let your teams, tools and processes go two years without meaningful improvement?

Answer me that on a postcard. Put a link in the comment in the description below. I would like to know the answer to that. You're measuring outcomes and not outputs. And so here's the last mind shift and it's critical to what you're doing. Product managers measure success by using outcomes, not feature outputs. They don't celebrate shipping 50 features. They celebrate users achieving their goals. Engineering leaders need to...

think in the same way. I see so many teams measuring story points completed, number of commits, lines of code, and their outputs, but they're also meaningless. know, people who are looking for ticket resolution stats, all these types of things, like, yes, they're great to measure some form of velocity, but they're outputs. What you should actually measure is the outcomes. You know, are the engineers actually shipping faster?

your story points tell you that? Are they working less over time? Are they learning and growing? Are they enjoying their work? These are the outcomes. And here's the counterintuitive part because sometimes the best way to improve outcomes is to do less.

Productivity, like developer productivity tools, engineers are supposed to use them, code quality checkers, logging tools, monitoring dashboards, documentation systems, you name it. If you have loads of those deployed, then you end up with this knowledge that's split across all these different products. People are logging into different systems or monitoring metrics in different ways. If you have the opportunity to then cut these down,

You might find that productivity goes up because you find engineers spend less time fighting the tools and more time writing code. And that's outcome thinking. More tools didn't create better outcomes. Fewer tools did.

Okay, so let me address some of the objections that I will no doubt get in the comments or people like sending messages to me about this framework. So number one, but my engineers don't know what they want. And the truth is, you know, that's true, but neither do product users. That's why you do product discovery instead of just taking feature requests. You're not asking

engineers what to build, you're understanding their problems so you can decide what to build.

But engineering needs long-term thinking. We can't just be reactive. And as I said at the start, I completely agree with that. And good product management isn't reactive, it's strategic. You're balancing short-term needs with long-term vision. And that's literally what product managers do every day.

but I don't have time to do all this discovery and empathy work. Really? How much time are you spending on projects that fail or take a lot longer than they're supposed to because you haven't really planned them out? How much time are you spending in meetings trying to figure out why your team is behind schedule? How much time are you spending dealing with staff turnover because they're all annoyed and leave? And all of that is waste created by not understanding your team.

Product thinking doesn't take more time. It saves time by helping you build the right things. A little bit like writing tests. Like developers hate writing tests because it feels to them like they're not contributing to the core platform, the core product. But tests of course mean that you're fighting less fires and so it makes things more stable in the future. Product thinking from an engineering perspective falls into that same bucket.

How about, but my company won't give me budget for these improvements? Yeah, I've heard that one, but here's the secret. Most of what your team needs doesn't require a budget. It requires attention and prioritization. Engineering office hours are free. Just set up a Zoom call, a Teams call, whatever, and tell people about it. Shadowing your engineers is free. Running MVP experiments often costs less than your original plan. But you know what is expensive?

Building the wrong infrastructure, implementing processes that nobody wants, losing good engineers because you're not listening to them. Product thinking is cheaper than the alternative.

So, with all that said, you already know how to build great products. You understand customer research, iteration, MVP thinking, outcome measurement. You do this every day. The product thinking framework isn't asking you to learn new skills, it's asking you to apply these skills that you already have to a team that you already own.

And when you do this consistently, when you start treating your engineering team like your most important product, everything changes. Your engineers feel heard, they're more engaged, they ship faster, they're more creative, they stick around for longer. And you, you finally stop feeling like you're pushing a boulder uphill, you start seeing compound returns. Each improvement makes the next improvement easier.

When you apply this framework, for example, you end up six months later, deployment time goes from three days to 30 minutes, test suites go from hours to minutes, and you don't hire anyone, you just got different processes in place. You just start treating a team like a product, and that isn't to take the people out of it, it's to put the people into it. Product sounds like it's a veneer over the top and it's a layer. Of course, as a product owner,

you're very much engaged with the people. Here in the engineering team, we're very much engaged with the people. So here's what I want you to do this week.

Pick one pillar, just one. Maybe it's setting up engineering office hours. Maybe it's shadowing an engineer for a day. Maybe it's running an MVP experiment on your biggest infrastructure project. Start small, learn fast and iterate. That's product thinking.

That's all it is.

So thanks for listening. That was enough of that rant for one episode. Hopefully it resonated with you. If it did, if you could share this podcast with another engineering leader. And if you want to go deeper on this stuff, check out the show notes. I've got some templates and frameworks you can use. And once again, I've been Tom Barber and this has been Engineering Evolved. I'll see you in the next episode. Feel free, like I said, to put comments.

Drop me messages, let me know what you'd like to hear. But until then, treat your team like the product they are. See you later.