What Is Product Engineering?

Hello, welcome to the product engineering podcast. My name is James Charlesworth and this is the podcast where we talk about the intersection between software engineering and product management. In this first episode, we're going to start at the very beginning and answer the question, what is product engineering? Why does it exist and why should you care? Let's tackle that last question first because why should you care about product engineering? Well, if you work in software development, either as an engineer or a manager or any kind of products builder really, then you'd have noticed that the entire industry has been shifting around you over the last couple of years. Software engineering is no longer just about taking some requirements and turning them into code. Engineers are increasingly being expected to become higher level problem solvers and to have more awareness about the business impact that their code is having. And that shift is of course being driven by AI. The impact that AI has had on our industry has obviously been enormous and it will continue to be enormous for the foreseeable future. But product engineering isn't something that came out as a reaction to AI. AI has definitely accelerated the need for a product led approach to building software. But this was a trend that's been growing for years now and AI has just kind of shone a spotlight onto it. So let's start at the beginning then. What is product engineering? Product engineering is an approach to building software in which engineers share responsibility for product outcomes, not just the technical delivery of the work. So that means that engineers aren't just handed a spec or a set of acceptance criteria and asked to implement it. They're actually involved in understanding the problem and exploring possible solutions alongside their product manager. That doesn't mean engineers replace product managers. It means that product managers, engineers, designers, researchers and other specialists all work together in a combined product engineering team aligned around a shared outcome. To better understand product engineering, it's probably worth contrasting it to something that you might already know. So the opposite of product engineering is what's called roadmap driven development. In roadmap driven development, everything aligns around a product roadmap and that roadmap becomes a communication mechanism between the product team and the engineering team. It also becomes a communication mechanism between your product combined R&D organization and your users. So consider an example. Let's say you're working on a team and you're building an email marketing platform like MailChimp or something like that. Now your product manager has identified that some of the users in your platform struggle to understand when they log in what has changed since the last time they ran this campaign. So they see a dashboard and they can't quite understand what's different about the last time they looked at that dashboard. So what happens in a roadmap driven approach is the product manager will identify that this is a problem. They'll gather some evidence from other users that have that problem and then they'll go and try and design a feature to fix it. So in our example, let's say the product manager decides that they want to create an AI summary box at the top of the dashboard. What happens then is they build that design for that AI summary box and then they'll go to some users and they'll try it out. They'll put it in front of them and they'll do a bit of validation. Now let's say at the end of that validation process, the product manager has confident, fairly confident that this AI summary box will address that problem that the users are having. What they then do is at that point, they then go to the engineering team with that feature written down in a spec and say, can you please estimate this for us? The engineering team will come back and they'll say, yeah, that's probably three weeks worth of work. So the product manager takes that three weeks worth of work and puts it onto a product roadmap with a three week block. And that goes on the roadmap amongst a bunch of other features that the team want to build. At that point, execution begins. So engineers will break down that work and they'll do it properly and they'll build it and it will take them about three weeks as they expect it. Now that's roadmap driven engineering in a nutshell. You give an engineering team a piece of work that you want them to do, you ask them to estimate it and then you go ahead and let them build it. And the success of the engineering team under a roadmap driven model is really how well have they built the thing that they were asked to do and how accurately did they stick to the timeline that they said they were going to do it in. Now that predictability is very, very useful in a lot of cases and roadmap driven engineering is very, very useful for certain specific cases where predictability is incredibly useful and valuable. But in a lot of products, there are too many unknowns for roadmap driven engineering to be the only thing you can look at. Let's say for example, we're working on our email marketing platform and we don't necessarily know how to make it so that the users can see that information since the last time they logged in. So the product manager has an idea of how they might want to do that, which is this AI summarization feature, but they don't necessarily know until users are actually using that feature whether that was the right thing to do. So under a roadmap driven model, the engineering team can hold their hands up and they can say we built this thing exactly to the spec that you asked us to build it to. But that doesn't change the fact that if it goes into production and users start using it, they might find that it doesn't actually solve their original problem. So in a product engineering team, instead of giving the product engineering the team, the feature that you would like them to build, you come at them with the actual outcome. So in that situation, the outcome is that we want our users to be able to understand what's changed in the platform since the last time they visited. That's the outcome. You give that outcome to the engineering team and you allow the product manager and the engineers and all of the other people on that team to decide how they're going to drive that outcome themselves. What happens when you do that is a few things. Firstly, it forces engineers to think more like product managers. It forces them to move up the product development lifecycle. Because engineers get very uncomfortable if you give them unclear product requirements if they're being held accountable to how well they can deliver to some requirements. You probably heard the term scope creep before. Scope creep is an uncomfortable feeling that happens on engineering teams when they feel like they were lied to about the scope that was requested, before they feel like the scope is being changed. On a product engineering team, scope creep is okay because we'll get on to why in a second, but ultimately allows the team to iterate a lot more quickly if they're allowing the scope to change. So on a product engineering team, let's say you're working on an email marketing platform and the team are just being given the outcome of make it so that users can better understand what's changed on this platform since they last logged in. What happens then is the product engineering team get together and they think of some ideas. They think of some things they can do to try and drive that outcome. So maybe one of them is an AI summarization feature, but maybe one of them is they send out a weekly email or maybe they just redesign the dashboard or something like that. They have all these ideas. The next thing they do is they then decide how we're going to know which of these ideas is driving that outcome. And that's a very crucial step in product engineering is knowing in advance how you're going to measure the success or the failure of a feature towards driving an outcome. So the product engineering team will take an idea and it might be an AI summarization feature. They'll take that idea and they'll work out how they're going to measure it. And then what they'll do is they'll build a prototype of that idea and prototype is important because in the traditional roadmap model, that feature is not delivered until it's done to the acceptable scalable maintainable architecture that your product deserves. But in a product engineering model, if all you're trying to do is work out if this is the one feature that will drive that outcome, then you will naturally build lower fidelity smaller less scalable solutions that you can try out quickly instead of committing to a large scalable solution. Now this is an important concept in engineering in general. And if you've ever built a product for different levels of scale, this is really, really important to understand. When you engineer a solution to a problem, you're engineering it for a specific level of scale. So if you have a hundred users, the feature, the architecture, the way the code is going to work together, if it's serving a hundred users, that's very different than if you're serving a thousand users or if you're serving a million users. And a lot of companies, a lot of engineering teams will make the mistake where they will try and build a feature for a million users when they actually only have a thousand users or in our case, they only want to try it with 10 users. So one of the important things here is the trust that the engineering team can know that if we build something that isn't scalable, we're doing that because it's quicker to build. And we're going to try it out with a small number of users. And if we decide that that is the right feature to build, we then go and build it so it can scale to our full user base. And that's a really, really important distinction that is important to product engineering. Because in product engineering, the whole team is accountable for how well they drive that outcome. And so it's okay if the team don't deliver something that's fully scalable. It's okay if they don't deliver a completely finished, polished product. As long as it's vaguely, you know, it has the main things that you need. So it needs to be secure and it needs to have observability built into it. And you need to be able to measure the outcome of that feature and the performance of the feature. It doesn't need to be fully scalable. And it doesn't need to be perfect code. It just needs to serve the purpose of that prototype, which is to decide is this the thing we should continue building. Now, this is naturally the way that product managers work anyway, or at least they would like to work. Product managers do think in terms of this is an idea for a solution. So let's try it out on some users and then iterate on it. The iteration is really baked into how product managers work, but a lot of engineering teams struggle with iterating on top of something over and over again. They see that as adding complexity and making the code more difficult to work with. So product engineering absolutely relies on engineers being bought into the outcome that they're trying to drive and being able to cut corners and do things in a smaller way so they can learn from those experiments. So that when they do build something scalable that takes multiple weeks, they know they're building the right thing. So product engineering is allows you to change direction a lot more because engineers are being held accountable to the outcome instead of just delivering the things they're asked to build. Structurally, a lot of things change on the team as well. So in a product engineering team, you don't tend to have handoffs. One of the things with a roadmap driven model is that that roadmap basically becomes a handoff step between some product managers and some engineers. Product managers work up until the point where they've built a roadmap and it's defined and they've written product requirement documents and then engineers pick up from there. But in a shared outcome accountable product engineering team, that roadmap is really just an artifact that's being sent to stakeholders. The actual team themselves are constantly thinking about how we're going to drive this outcome. What's the next experiment going to be? How are we going to try this out on some beta users? And what happens in a product engineering team is naturally engineers will get involved in some of that discovery and that validation themselves. They'll get involved in ideation. They'll propose ideas that they think will have a positive R.L.M. or a positive R.O.Y. from an engineering perspective. And that's something that's often overlooked in engineering teams is that engineers can propose solutions. They might not always have the customer context and the product context to be able to propose the right solutions, but they can propose solutions that are engineering easy to make. So let's say in our example of an email sending platform, one of the ideas might be to build an AI summarization feature. Another idea might be to send out a weekly email that says what's changed in the platform since the last time you visited. Now, let's say the engineering team know that sending out an email is incredibly easy to do. I mean, they are an email marketing platform, so they could do that in a day. Building an AI summary feature might take two or three weeks, but they could send out an email in one day. Now, the product manager might not have known that that was as easy to do as that, so they would never have come to the team with that feature. But if you allow the team to suggest ideas that they think are easy to test out, then you'll get some of these ideas. And it could be that that was the right solution. You don't know. The important thing to understand about products engineering is it's to tackle the problem of unknowns in a product. And this is how you can decide really because products engineering is not for everything. Products engineering is a model that emerged out of having to iterate faster in unknown situations and in unknown product feature solving things sort of things. But it's not the only solution. If you have a project that's maybe, let's say you're migrating a database or you're migrating a customer, a migration project is something that still very much benefits from roadmap driven engineering because you know there's not very many unknowns in a migration. You know what the end state is going to be that you're trying to get to and you just need to know how long it's going to take and what kind of quality controls you've got in to get to the end of it. So migration project fits under a roadmap driven engineering model very nicely. But something like a vague user behavior outcome, like allowing somebody to more quickly get their jobs to be done done. That is a very, very unknown thing where there might be multiple possible solutions. So the roadmap driven model, even though it can create predictable delivery, it does break down when you are trying to tackle some vague unknowns about an outcome that you want to drive. And so product engineering fits a lot better into that model. Having everybody on your shared product manager and engineering and designer and research team, having them all align around one outcome allows them to be a lot more honest about the corners they're cutting about the things they're trying. It allows them to be bolder and it allows them to take more risks as well. AI can accelerate product engineering because AI allows you to go through the product development cycle so much more quickly because it allows you to experiment with things. Everybody likes to hate on vibe coded code and agentically coded stuff. But there is one thing that it's very, very good at. Agented coding is very, very good at putting an idea in front of customers in front of real users and seeing what it's like to use as a product. Now, it doesn't necessarily mean that it's always the correct architecture and always the correct solution. But using a gented coding and having AI write your code can get you from a thesis or hypothesis of how we can solve this problem to something that we can find out whether there's a signal of whether we'll actually solve the problem or not. It can, of course, help with the rest of the delivery as well. But the most impactful thing AI can do is it can allow everybody on the product engineering team to work together to ship something quickly to a small feature set of users. So AI is an absolutely crucial skill going forward for running an effective product engineering team because AI allows you to iterate. Another thing you need to be able to do is feature flagging. So you need to be able to try out experiments with a small subset of users. As we spoke before about scale, when you're doing experiments and you're trying out things on users, you don't want to be doing it for the whole user base at once. That will probably take too long to build and there'll be too much testing. You want to be able to try it out on a small subset of users, both for scalability, but also for just general friction because it might not be the right thing that you're doing. So try on some friendly users and then you'll know that you're doing it. And ultimately, if you're holding the product engineering team accountable to driving that final outcome, then you're not holding them accountable to how effectively I can deliver the things that are asked to deliver. That's quite uncomfortable for leadership sometimes to say we're not going to hold you accountable to how accurately you can stick to your estimates. But you need to be able to do that because that takes a responsibility away from the engineers for we need to do the thing that was written down and it puts a responsibility for the product engineering team to be able to do that. So that puts a responsibility on them to say we are accountable to how well the user behavior changes in our product, what the outcomes are that we're driving. So next time your team is shipping something significant, then don't stop to ask like whether was this actually delivered. Ask what was supposed to change in the product as a result of shipping that feature. Did more customers adopt your products? Did users complete that task more easily? Did support demand fall down? Did the behavior that you were trying to influence actually move by doing this work? Delivery still matters. Good engineering practices still absolutely matter. Reliability, security, maintainability, they all still matter. But completing the work is not the same as solving the problem in the product. So product engineering is about keeping product and engineering connected to that problem. So before the work begins, they're connected to it while it's being built, they're connected to it. And after it's been released, they're all involved in understanding what's actually driving those outcomes. So think about the last major feature your team shipped. What outcome was it intended to produce? Did anybody actually go back and find out whether that worked or did they just hold their hands up in success and say we correctly delivered the thing we were asked to deliver? In the next episode, I'm going to look at what happens when organizations repeatedly fail to ask that question and about how capable teams can find themselves caught in something called the output trap. So stay tuned to this podcast. You can find this on YouTube as a video podcast and on Spotify and other places where you can get your podcast. I intend to do this quite regularly and I will have guests on this as we get into a rhythm. But this is all going to be about creating engineering teams that are aligned around an outcome and driving value inside a product.