Aligning Teams Around An Outcome (with Anna Dick)

It's not necessarily like how fast you can use AI to build something, but it's still the blockers around decision making or waiting for somebody else or waiting for another team. Hey, welcome back to the product engineering podcast. Now this week we're talking about how product engineering actually functions in a modern product led organization. And there is nobody better to talk to us about this than Anna Dick. Anna is the CTPO at Capsule, the CRM, and she has over 20 years experience in the world of product leadership. So Anna, welcome to the podcast. Thank you. Thanks for having me. So one of the things we talk about a lot on this podcast is that shift between engineering teams essentially delivering a roadmap and building to respect towards taking much more ownership over product outcomes. So I wonder what's your experience in how that's shifted and how do you do things there at Capsule? Yeah, so Capsule, we are a company of around 50, so we're not massive. We are remote, but we do have a bit of an office in Manchester as well. I think when I first started at Capsule, there was already a bit of a product mindset within the team, but we were still quite siloed in terms of our approaches. So the kind of business side of things and then an engineering function, there wasn't a lot of product or product kind of mindset. So over the last couple of years now, we've been working on how we get that more into the business, but then also into the teams in terms of that shared responsibility. I think originally there was a lot of the engineering team spending time kind of building the things and not necessarily understanding the customer, the outcome and kind of where we wanted to get to. And that wasn't due to like a lack of appetite for it. It's just the way that it would be structured. And I think that getting that product mindset into the teams was something that was quite intentional for us. So we did get some external help. I think when I started at Capsule, I don't know if you ever had the kind of moments where you feel like you're the only one talking a language or speaking about a certain thing. So it's quite hard as one person in an organisation to kind of invoke that kind of change. So we did work with the consultancy in the early days to actually do upskill and learning sessions that were for everybody. So that was all the engineers very focused on kind of the execution and understanding around outcomes, but also sessions with our exec as well, because I think it needed to come from both sides in terms of how we work. It was also about how we kind of organised, how we got some product management experience into those teams, as well as the engineers thinking about those outcomes as well. That's really interesting because I think a lot of engineers want to do a lot more of this. They want to get involved in discovery or they want to speak to customers, maybe less of the supporting after it's released, but they should be doing that. But often it is just it's both the given the permission to do it and given the authorities to it, but then also given the education. What kinds of things did you find most valuable from people that came in and talked to them about it? So we had quite a structure. I think initially we did like a bit of it. I think it was maybe eight weeks where we covered different themes. So it's what is an outcome over just kind of output. For example, we looked at different kinds of way to structure the teams around discovery pieces. So the importance of research, having people involved in calls, research calls and how that kind of fed back. We were kind of quite focused on kind of user stories and story mapping, I think at the time. I think we've probably even evolved since then. But I think just helping people put their the perspective of the user in terms of what that outcome is rather than do this task, build this thing. It's like what's that overall piece that we're trying to achieve as well. How big are your engineering teams or product engineering teams? So we have four kind of delivery teams and we are very much cross-functional and that's something that during that period kind of improved. Although the kind of being cross-functional in terms of those engineers and maybe support and CS team didn't necessarily include marketing or more products, you know, that kind of full intent cross-section, like a unit of delivery who could kind of take an outcome and run with it. So the reason I ask is because everything you're describing of getting everybody on the team more focused on the outcome and speaking to customers can run a risk of having that too many cooks in the kitchen kind of thing where a customer is sort of dealing with an entire team instead of an individual. So how do you get around that of giving everybody the ability to contact customers and do some discovery but without having the entire team trying to pile onto one problem? Yeah, so I think, you know, we've been, you know, changing our team structure even more as we go. We are now bringing up kind of a pair of developers very much upfront working with product in this discovery phase as well. And each of those kind of pairs will have a different problem or outcome that they're looking to solve. So, you know, is it helping our customers get more leads or is it helping them on board those kind of outcomes? So that quite small team is then involved in doing the research, understanding what the customer needs, doing customer calls, but also building out the prototype as we go as well. I think because we do want to have more engagement with customers, obviously it can be challenging to get time with our customers and often the people that want to speak to us are, you know, the early adopters, they're the people that, you know, don't necessarily are not necessarily as objective with feedback sometimes. So we have started more of a kind of continuous discovery element where we are looking for other types of users. And we do like provide a little bit of incentive to help get, you know, not just the people that would want to speak to us normally as well involved in that process. That's something that a lot of engineers who first go into like product engineering don't really understand is that not every customer has created equal. If you only design for the people that are willing to speak to you, as I'm sure you know, but a lot of engineers, like because a lot of their experience of customers is either when something goes wrong or they just see kind of generalised customer feedback across the entire thing, it's difficult to understand that like you're right, a customer that's more likely to be an early adopter and jump on and do some discovery with you doesn't necessarily, it's not representative of the entire customer base. Yeah, exactly. And what do you look for if you're maybe hiring or putting somebody else into a new role inside your organisation? What kinds of skills do you look for that you can develop for effective people in product engineering, both on product and the engineering side as well? Yeah, so I think it's curious, curiosity, I guess, in terms of definitely that kind of learning mindset in terms of just being interested in understanding all of those wider roles. So, you know, not just, you know, how you might build something, but a real interest in like, why are you building it? Who's it? Who's it for? What are they doing? So I think that's one of the things we're looking for our teams to be more conscious of is what is it actually, you know, once it's going through the beta phases, is what's that feedback? What are the numbers? What are the insights? That's kind of saying, yeah, do more of this or actually, you know, don't be afraid to go, that's not really the right thing anymore. And like actually using some of that data to kind of pivot and change paths as well. So yeah, definitely curiosity, I think more and more the ability to work wider across the stack. So, you know, whether that's product, who can build prototypes, designers who can build, you know, engineers who are happy to get on interviews. I think what we're seeing is that kind of widening of the scope of all of those roles. It's kind of getting the, you know, groups of those people together to be able to be that kind of unit of delivery that can solve those customer outcomes together. Yeah. And if you do have a wider role, and this is something that a lot of people are saying is that, you know, for example, AI makes it so that a product manager or designer can build a prototype. Getting closer to customers makes it so that engineers can be a bit more outcome driven. But how do you avoid kind of peanut buttering everybody's role? So how do you make sure that people can still bring their specialist skills? So if you have somebody that's really, really good at kind of back end architecture, how do you make sure those skills are still used effectively in that context is shared? Yeah. I mean, I think the way that we're saying, you know, we'll always need the experts. And I think we're very clear on that. And you know, not every engineer is comfortable being on interviews. And I think there's different ways to kind of spread across the stack. And I think that's around how we kind of form or create the teams so that you do make sure that you've got the specialisms within each area for the teams. But they're also kind of happy to be like, as a team, what do we need to do to get this, you know, product to the next step in front of customers as well? And I think it's a bit of a training and exposure as well in terms of the areas that people feel comfortable with. And, you know, we now have some of our front engineers who are using AI to mock out some of the back end as they go. So it kind of, what can we use AI to help unblock people? That doesn't necessarily mean that that back end would ever go into production as something that we would maintain as production code. Because there's that gap between like, what is the prototype, is something that's secure, maintainable, and manageable on an existing stack. You know, there's a lot to do there. But it definitely helps teams like unblock themselves in terms of not waiting for those kind of specialists to be able to get that next version that we can maybe prototype or run some data through or get in front of customers. I also wanted to ask about process. So you've been doing this game for a very long time, right? Like you would have remembered when Agile came out and then everybody had to kind of over index on all of these Agile ceremonies and other ways of working. In terms of actual processes, like day-to-day ceremonies and things like that, have you noticed a shift there? Is there anything that you do now that maybe we wouldn't have done five years ago? So, you know, we've been kind of loosely Agile. I think we are Agile in terms of we pivot and we move quite a lot. We do an element of quarterly planning in terms of the outcomes and the objectives and the customer goals we want to get to. And then we might have, you know, certain things that we want to experiment or a bit more mature thinking around the things that we want to build with NetBora. And we do prioritise them based on, you know, indicators that we're seeing, whether that's from our customers or certain data points. We still very much do that discovery phase. But I think now that we're using AI and we're bringing the engineers forward to support prototyping, that discovery used to be kind of done more in isolation with the product and designer potentially. So we're probably spending a bit more time on the thinking and investing more people in that process with a bit more rounded view. So I think in terms of ceremonies, we still have our kind of two-weekly cycle, but that planning is much lighter on a weekly basis. We tend to do a lot of the planning kind of upfront in our discovery phase. I think the prototype effectively becomes the thing that we want to build. And then once that's validated with customers, it's how do we break that down to build it over a number of iterations? We don't like, we're not very deep on like counting points or, you know, kind of scrum type things. We have very much of a constant flow, although we do have this kind of two-week checkpoint where we do say, what do we want to achieve in the next two weeks for each team? So that they're very aligned. And then we can line up other areas of the business as well for that too. Yeah, I've noticed a death in story points. I think the reason we don't count story points anymore is because that used to be the riskiest, most intensive part of the investment was turning a story into some code. And so you really needed to be able to accurately predict that. But now if you can turn a story into some code quite quickly, it doesn't really matter. If you use those AI coding tools where they turn around and say, oh, this will be about a week's worth of work. And you say to the AI, like you're an AI, you can do that in 10 minutes. Stop doing it. It's a week's worth of work. A week's worth of work five years ago is not the same as a week's worth of work now. Now you can go from an idea to a prototype extremely quickly. But yeah, I do think sometimes people over still over-index on prototypes, though. So you mentioned that you would do a prototype as part of the discovery phase. There is both that sunk cost fallacy of thinking, well, we've already built a prototype. We should continue in this direction. And then there's also sometimes the perception that the prototype is ready and it's scalable and secure and stuff like that, which it isn't. So how do you get around that mindset shift? And that might often be a case in leadership more than it is on the actual teams, where you will look at a really great looking prototype without really internalizing that there's a bit more work to do. Yeah, definitely. And I think that that expectation management is key because I think as soon as certain members of the business see something that's working, they're like, oh, that's that's it. That's then ship it. You know, that's a common kind of jokey phrase, like not kind of joking. So I think that's a lot of work we've done across the business to help people understand the difference between that prototype and a production version. But I think because we've got the engineers working more upfront on the prototype. Product person might start to like visualize an idea themselves in a prototype. But when we get the engineers involved, they're actually building the prototypes into our code base, you know, so they're using a lot of like existing components, potentially existing API endpoints. So that gap between what a prototype is and what that production version as they feed back over time, I think that's going to is going to reduce in terms of the effort between prototype and what live build is. But that doesn't mean it's the right thing. So it's still making sure that we're going through enough of that validation phase. So just because we've built it doesn't mean we should ship it. Yeah, I'm always quite sympathetic of like cyber reliability teams and security teams because their work is so hidden and their work is the difference between something being mocked together and tried out the few users and actually scaled out to production. And I think a lot of people in security and cyber liability are finding that their workload is just going up so much because it's so easy to make stuff that needs a security review or it needs testing and things like that. Like do you bring people from the kind of technical support, security, all those kinds of things, do you bring them into the process at any point or how does that work? Yeah, they're in the process from the beginning. So we tend to kind of kick things off with kind of product, kind of canvas, I guess. So it's like why we want to approach this problem, what are the insights, what are our customers kind of saying, which is quite light. And then we kick that off with the whole of our delivery team as a like, this is the problem space we're going to start looking at. And that has CS support, marketing, sales where we can get them, but we've got a very small sales team. But just to try and get that understanding quite early and then say, who does need to be involved in this? But then it tends to break down to a slightly smaller team, product engineering, design, who would maybe go off and do some of that discovery work, but they'd link in with the experts in their team as and when we want to explore. But when we get to the point of full build, then everybody comes back together and is more involved. Yeah, one thing I did on a slight tangent, one thing I really wanted to ask you. So you've been doing product leadership for a very, very long time. A lot of people that listen to this podcast are from an engineering background. Maybe they're a senior or a staff level software engineer, and they're having this sort of identity crisis because their entire life has been built around writing code. And now they're realizing that, okay, that is now a case of directing agents to do it. So a lot of people are thinking, okay, I know I need to become more product led. I know I need to speak to customers. I need to care about outcomes. What advice would you give to people that have been software engineers for several years and they want to become more product led and they don't quite know which direction or what skills to pick up? Yeah, so I think getting involved with the product teams or even like the business side of things. So if you're already working in a cross-functional team, is trying to understand all the different roles within there. I think a lot of the product mindset type piece is like really understanding what ultimately you're trying to achieve. What's the behaviors that you're trying to change? So actually spending some time with customers, maybe understanding some of the persona data that your teams have around the customer base. Spend time with maybe your customer teams or your sales teams as well to try and understand like how do people use our products or services. I think that's really helpful as well. Yeah, no, it is. I completely agree. I know some CPTOs and product engineering leaders that will, for the first two or three weeks when a new engineer joins a company, they'll embed them into the marketing team or they'll embed them into the sales team or something. So they actually get a feel for how things are sold because for so long software engineering has stopped at the Jira ticket ending on done and the code being merged and then they move on to something else. And so for a lot of software engineers, like the world outside that Kanban board has been quite limited. And so, yeah, it's an exciting thing to pick up. And I think this kind of getting the engineers involved in the discovery work up front, we've had some great feedback in terms of that approach and how that's kind of gone, "Oh, I didn't know that, I didn't really think like that in terms of how people might use the products." And you're right, rather than just seeing a list of tickets to work from, being kind of responsible and having a bit more of autonomy as well around the decision making that's involved in creating these things. Rather than working off a ticket backlog, I think people feel a bit more empowered in that sense. Yeah, I remember the first time I looked at a session replay to always in money supermarket. And when you see somebody moving their mouse around the page and not opening a accordion, you're thinking the information is right there. You just click that button and it opens up. Why haven't you clicked it? And then to really get your top into the heads of that. I saw a really good talk of somebody that works on the Gov UK website, which is genuinely a landmark piece of UX engineering. Where they did a lot of research of people that were not like digital natives. And so they were trying to use the government website and they were struggling with dropdowns and things like that. And those are the kinds of things that if you've grown up around software and you've been a software engineer or product manager, it's really difficult to understand that other people have different experiences and they use products in different ways until you actually see it happening. So for me personally, that was my opening thing. It was really good. Yeah, and I think the session replays, but then also just the data, from tools like Pendo, we can now use the MCP server to actually get some of that data kind of straight back into Slack channels. So it's instantly starting to see how people interacting with it or maybe not interacting with it. And what does that mean? I think the whole team can then experience that data, can talk around that data and just is living it a little bit more rather than, oh, we've built it, I'll hand it off and we're moving on to the next thing. How do you encourage engineers? Because a lot of engineers will see data like you might find in Pendo or competitors to Pendo. They might see that as not their domain. So they might think, well, my data is the memory usage on the database and things like that. Right? So how do you encourage people from an engineering background to actually engage with product analytics data? So I think it's making it accessible. So I think like we would have had very, very few engineers who would have logged into Pendo, for example, to like look at that data. Our product managers might have presented some of that data, but actually when we're presenting it more in line with this is just released, this is the next day, oh, we've got five people have started using that. They were actually finding like an energy about it because no one wants to build something that's not used, you know, or isn't working quite right. So if there's that data to actually say, how could we make this even better? Then I think that's really powerful. But yeah, making it kind of really accessible and putting it where our engineers are so that they can, you know, they can see it. Okay, the last question I have for you. What do you think the future is for the product management role and for the software engineering role? Do you think there will remain separate roles or will everybody just be a product engineer? Like I said, I think there will always be specialisms. You know, maybe it's different in a startup kind of world. I think for us where we have quite a mature stack, you know, 15 years old, the specialists are really important and I think we don't want to lose that. I don't think necessarily everybody will be a product engineer, but I think there will be, I don't know if I like the word builder, but you know, that kind of like spreading across so that you can take an outcome and you can with the support of AI, supporting you what the area that isn't your specialist, you can get things to a certain point, you can unblock yourself to get things to beta or further. Because I think one of the things I found, it's not necessarily like how fast you can use AI to build something, but it's still the blockers around decision making or waiting for somebody else or waiting for another team. So I think trying to unblock those other areas so that people can more completely create, you know, the thing or the outcomes that might not be the final version, you know, that would be reviewed by the specialist or inputted or maybe replaced at some point. But yeah, I think having these more unit, small unit of delivery teams where you've got a mixture of capabilities, maybe with specialists kind of sitting around those teams that would still care about the architecture, you know, the data architecture, the security, maintainability, all of those things. Because I think those are all things that you really need to care about. Yeah. But without having, you know, so I think still having a specialist, but being more builders. Yeah, it probably is an organization size thing because small startups have never really had a split between product management and engineering. Like if you're in a four or five person startup, everybody is getting hands on and everybody is talking to customers and everybody is, if they can, writing code. So yeah. But maybe that's what, that's probably part of what helps them move fast. It's when you try and scale that and you're adding more people into the, you know, into the mix in terms of how that can start to slow things down, I think. All right. Well, thank you Anna so much for coming onto the podcast. If people want to contact you, where's the best place to find you? Probably on LinkedIn. I think that's fine. Yeah. Reach out. Brilliant. All right. Well, thank you so much and join us next week. And thank you again, Anna Dick from Capture CLM.