Giving Product Engineers Direct Access To Users

In order to have an effective product engineering team, everybody on that team, including software engineers, needs to be able to talk to your users. So how do you actually create a mechanism that allows that to happen? That's what we're talking on this week's episode of the product engineering podcast. Product engineering is all about driving outcomes inside your product with as much information as possible. So people making decisions on what should be built and what shouldn't be built need as much context behind those decisions as possible. And often that information lies directly with your users. It's inside their heads. It's inside the behaviors that they exhibit when they're using your product. So in order for everybody on that product engineering team to be able to make decisions about what they do, they need to be able to get some of that context out of your users heads and into their decision making process. So that usually involves product managers and software engineers talking directly to users. So how do you make that happen? Well, one of the obvious things you can do is create a mechanism that allows software engineers to actually interact with users or customers. So that could simply be a case of bringing them into customer calls, like letting them sit in the background, letting them build up relationships with customers themselves, or it could be a little bit more conscious. You could actually create a mechanism that allows account managers to talk directly to engineers and identify which customers have time to get on a call or to talk to those engineers. It could also be a little bit more passive. If you give engineers like call recordings and transcripts and things like that, then they can try and understand what customers want without actually talking to them directly. But it is usually better to have them actually talk directly to your customers wherever possible. Some organizations will actually embed software or product engineers onto customer sites. If they work directly with customers in that kind of way, then having a software engineer work on a site with a customer for a few days can be a really, really good way for those engineers to build up the deepest level of context possible about what those users are trying to achieve in the product. But there's many ways you can do it. The important thing is that you have a mechanism that allows it to happen. Because if you don't, then software engineers that are trying to drive outcomes inside a product will find themselves hitting a blocker when they need some more information to validate their ideas. If those conversations have to go through a product manager or they have to go through somebody else, then it's very, very difficult for those engineers to get rapid feedback and ask as many questions as they really want to ask. A software engineer coming up with an idea inside the product might have a load of questions that they want answered. And only some of those questions are available to be answered by their product manager or by the people that work with the customers. Some of those questions might involve actually speaking to the customer and asking them directly. If they're building an idea or they've got an idea for a new feature, watching a user interact with that prototype is absolutely invaluable for software engineers because then they can take that context back to their team, they can share with the rest of the product engineering team, and they can allow it to drive their own decisions going forward. User experience and user behavior is very, very difficult to put into words. It's much easier to actually experience it in person. So as much as you can ask users to fill in feedback forms and survey their responses and ask them like NPS surveys and things like that, actually sitting down and watching somebody use a piece of software and asking them what they're struggling with and observing their behavior is absolutely invaluable. No amount of AI can replace the ability to watch somebody using your software and see where they're struggling. It's not just a case of asking people what they want and then doing what they want. It's a case of actually observing how they try and solve a problem, watching their workflows. And so you need a much more direct line of communication between the people doing those things, the users behaving in those ways, and the product engineers that are trying to make decisions based on those behaviors. Because in many cases, software engineers can provide new perspectives on pieces of functionality that people that are not working directly in the code base might miss. Performance is a good example of this. I've been on a lot of customer calls with users where they've been complaining about a certain aspect of performance and I've been able to identify just by knowing what's happening in the application where that actual performance issue is really based on. So where as a product manager might have observed them loading a dashboard or something and seen it taking a long time, they might have written down the user is trying to load this page and it's taking a long time. As an engineer, you can actually watch them do that and go, "Oh, I know that. That's because it's waiting for this login component to load." So you would write down the user is trying to load this dashboard before that login component is loaded, which is a much, much more detailed level of information about what a performance problem is than just writing down this user thinks the product is slow. So having engineers that really, really understand what users are doing inside the product from a technical point of view can actually allow them to ask better questions and it can allow them to like read more information into the behaviors that they're observing in their users. Engineers can also be really, really good at spotting new opportunities and new possibilities. If you're observing somebody using a product and you're talking to them about their experience using a product, then ideas can pop into your head as an engineer that might not have popped into the head of a product manager or a user researcher. So for example, if you know the back end architecture and you know how all of your event queues and things are working and you observe a user doing something that you know isn't going to be implemented particularly well on the back end, then you can have ideas there and then about how we can change the back end architecture that will allow that user to be able to complete that job more efficiently. So just like product managers, I've got really, really good fine-tuned skills in being able to like pick up solutions and pick up the real reasons behind users pain points. Software engineers are really, really good at picking up the technical constraints and the technical reasons why certain jobs to be done might take a little bit longer. So if you put those two together, then ultimately you'll build up a much, much clearer picture of where users are struggling to use your product and what you can do about it. So having engineers actually sit in on customer calls can be really, really useful for building up that empathy and building up that understanding of what users are trying to do. There's other ways you can do it as well. If you have a session replay tool, then you can have engineers watch replays and you can have them watch users go through the product. I remember early on in my career when session replay tools became a thing. I was working on a B2C commerce platform and the first time I logged into a session replay tool and watched somebody going through and trying to click a button and realizing that that button wasn't the right button to be clicking. That was really, really insightful for me as an engineer because even though I knew I'd been told to put the button there and I'd implemented it correctly, it made me realize that the thing I was asked to build wasn't necessarily correct. And so then I could go and I could turn around to my product manager and I could say, I think this button should be moved. I've watched this session replay. I've got a bunch of data here that shows that this button was not put in the right place. And the product managers will often turn around and say, yeah, you're right. I hadn't really put that much. We didn't have that evidence at the time. Session replay data only comes in after you've already implemented something. And often product managers are far too busy to go through session replay data and try and change something they've already decided. Whereas an engineer trying to fix a bug can look at that context and they can think this is actually a lot more than just a simple bug. This was an incorrect product decision that was made. I'm going to reverse that decision and do something a little bit differently. And they would only get that from actually observing users using a product. Customer feedback is also really, really important as well. If you've got a tool that will allow you to collect lots of customer feedback and analyze it in a kind of holistic manner, then engineers just reading through customer feedback can be an extremely valuable exercise in allowing them to understand how the technical decisions that they're making are actually being played out in the real world. So reading customer feedback and reading in their own words, what users are finding difficult and what they're liking about a product, watching session replays and actually getting on calls with customers can really, really help engineers become much more product minded and much more aware of how the changes they're making are actually affecting the behavior of the users using the product. So whatever you can do inside your organization that allows engineers to get closer to the customers, whether it's giving them access to all of that feedback and replay data or allowing them to get on customer calls whenever they need to, the more effective you can make those engineers. So then they become not just code writers, but they become problem solvers that really truly understand the problems that your users are having. So part of this is removing any gatekeeping around customer access that your organization has that may be blocks or stops engineers getting in front of customers. But another part of this is thinking about customer access as part of the job of an engineer. A lot of organizations will see an engineer pigeonholed to having their headphones on and just writing code. And they might think I'm not going to waste that person's time by allowing them to go on a customer call or something like that. But increasingly, as that code is being written by AI, that task of putting your headphones on and typing into a keyboard is less and less and less like intrinsic to the role of a software engineer. And so a lot of them do have time and they probably should have time. If you're a software engineer listening to this, and you find yourself all day writing code into a terminal or talking to an AI, then I would challenge you to think like, do you actually have a couple of hours in your day to go out and talk to some customers? And what can you change in your workflow and your development process that's going to allow you to have that extra time? Can you free yourself up for one day a week, where every Tuesday, for example, you are available to talk to users? What can you change in your internal workflow and your internal processes that will allow you to do that? And you might say that, yes, that's going to make me 20% less efficient. But actually, by talking to users and by talking to customers and understanding that context, it will make you more efficient because you'll spend less time building the wrong thing. You'll spend more time solving the problems that need to be solved and understanding what you're actually going to be building and less time building code that doesn't end up making into production or code that doesn't work or code doesn't really solve the problem that your users are having. So engineers absolutely should be spending a little bit of their week talking to customers, reading user feedback, watching session replays, getting involved in the kinds of conversations that are happening in Discovery. And that Discovery part is really important. Generally, product engineering teams will talk to users in two parts of the product development lifecycle. They will talk to them at the start, when they're trying to design solutions, and then they'll talk to them at the end, don't work, and we have to go and fix a problem. Engineers typically often get brought into that last one. So for a lot of engineers, their only interaction with users is when something's gone wrong and a bug has been reported and they need to jump on the call to debug that issue. But it's also important to get them involved in the Discovery part as well. So the engineers are not just there to fix something when it goes wrong. They're also there to try and help shape solutions and try and help do Discovery as well. So both sides of that coin between users helping you build the right features and users complaining that something doesn't work, both sides of that balance should have engineering involvement. Engineers aren't just there to fix issues. Product engineers are there to actually adapt and help plan what things we're going to build into the products into the first place. And both of those things involve spending time with users. Another reason it's important is it allows those engineers to take a lot more accountability about things they built. So engineers that are only brought in when something goes wrong, they can hold accountable to the reliability of their code. If they know that they're going to be jumped onto a customer call outside of hours if that code breaks, then yeah, they will test it a bit better. But if you can get them involved in the Discovery process, you can also hold them accountable to, did we actually build the right feature? And so the engineers are then accountable for supporting the product in production and they're accountable for building the right feature in the first place because you brought them into those customer calls at both sides of that process. The opposite happens as well with product managers. Product managers often see their job as ending when they've handed the product roadmap over to engineers. But by doing this, you can also have product managers coming in at the end and helping resolve issues as well. Because if product managers are becoming more technical and they understand the technical implementation of something, then they'll be in a much, much better position to be able to resolve customer issues later on in the support of that feature. And engineers will be able to get much, much better at designing the right thing earlier on in that process. So have engineers and product managers and anybody else on your product engineering team talking to users at every step. Talking to users when you're designing potential solutions and talking to users when things go wrong and you have to support it into production. Both of those are extremely important and both of those are activities that should be done by product managers and engineers. A well-functioning product engineering team takes accountability for the entire product development lifecycle. They take accountability for choosing the right things to build and they take accountability for supporting those things in production. And so having them go and talk to users in both those kind of modes is super, super important. And I would absolutely encourage you wherever possible to remove blockers that are preventing your engineers from talking to users in discovery as well. So over the next few episodes, I'm going to have guests on this podcast and talking to users is one hot topic that I'm going to be talking to a lot of my guests about. How are other organizations allowing, enabling and encouraging their software engineers to talk to users at all stages of the product development lifecycle? You're going to hear lots of interviews I've got scheduled on how other companies do this, what practices they put in place and what safeguards and what education they have for enabling engineers to do that. So stay tuned to the podcast, subscribe, you can watch me on YouTube and I'll see you in the next episode.