Dev And Product - Or On Enjoying Coding Whilst Creating Value

Fanny Krebs-Pinto at UXDX Community: Germany. Video: https://youtu.be/Q6e14or1mEA

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why I wanted to look at this

[00:00:04] I'm very excited to be speaking about this topic. It is something that is very important for me, and this is basically about collaboration between developers and product teams. Charlotte[?], we're all here very excited as well. Let me just tell you a few things about me first. As Charlotte mentioned, I'm deputy lead at the Paris group[?], which means I work very closely with the product team, but also on a daily basis with developers. I'm not a developer myself, I used to organize events[?]. I think I've been involved with developers for around 10 years now, on a work basis but also on a personal basis, which means I think I have gained a great empathy towards developers and the pain points they have.

[00:00:55] Because I also like to improve collaboration in general — that's something that I really enjoy doing — I wanted to find ways to improve collaboration between product managers and developers, and basically to say, how can PMs make the work of developers much easier? Which is what I want to explore now.

[00:01:12] Why I wanted to do this: because I think when I started working as a PM I knew all the theory. I'd read many things, I listened to many podcasts, and then I started working and I discovered that the reality was much different than what I'd read about. So it was kind of a bummer, because then I needed to find all the things and all the ways to make the collaboration work. But I was lucky enough to be working in many different team setups and to see what worked in some teams and what wasn't working in others, and to be able to get all this input and understand better what makes great collaboration. And that's basically what I want to share with you now.

[00:01:49] Obviously not everything will apply to you as well, but hopefully some of the things you can bring back to your teams and see if they work for you as well. There will be many different concepts, many different tips, and I will go pretty fast through all of them. But if you need more input on any of the things that I mention, there will be my contact details at the end. Please do reach out, or even better, join us at the chat and Q&A at 5 p.m.

[00:02:21] Because usually part of my job is also doing research, and I think that is a very good transition from the previous speaker, I wanted to base this talk not on my gut feeling and what I discovered, but also on real issues from developers. So I did have a lot of conversations and interviews with different developers, and I wanted to know what they found — knowing about the job, I also wanted to know what they found annoying about the product manager — to really be able to find where PMs could actually become much better at collaborating.

[00:02:55] These are basically the seven themes that I found out in the data that I received. I will share first the issues for each of the themes, but also the solutions that I suggest, that I have experienced, that are implemented in my own teams. Sometimes they worked, sometimes they didn't work, but hopefully some of them will work for you as well.

Wrong expectations

[00:03:17] The first thing that came up is expectations, or wrong expectations. I think this is pretty natural. We all have assumptions, we know they're wrong, but we still have them, and they cause many issues. That could be assumptions about roles in a team. It happened to me that it took a developer three months before she discovered that in the team I was the product manager and not only a project manager. So that was on me as well, for not mentioning it early on, maybe not making it very clear from the start.

[00:03:52] But it can also be assumptions about processes. Early on in my teams I had the assumption that I would just put tickets on a board and then people would pick those tickets, and they assumed that I would assign tickets. So obviously the ticket wasn't picked up for ever. But that's what I mean. Assumption is always bad, but even though we know it, we still have them, that's natural.

[00:04:15] There are still things that we can do to make this better. First, one that works really well if you join a new team, but also if you joined a team a long time ago and you never had to do it or never took the time to do it — you can still do this — and that's introductions. That's basically just taking the time to sit in one-on-one coffees, now maybe over Zoom, or individual video chats, but just take the time to speak with the team members one after the other. Introduce yourself, maybe speak about your expectations of working with them, but also ask how you can help them in the team.

[00:04:51] Another great way I found was an alignment meeting, or a team canvas or the HLPR canvas. I will show you examples now of those. So the first one is the team canvas. That's a framework that you can use. You can also tweak it and make it work for you as you need it, but basically it's a meeting framework where you define together what's the purpose of the team, who is doing what in the team — so especially now, if you consider the UXDX format where you have this T-shaped expert touching different parts, you can really say it here and define it and say who's able to do what in the team — and how we want to work together, as well as the values, for example.

[00:05:34] The other one is the HLPR canvas. This one works slightly differently. The team canvas was more an alignment where you do this together as a team, and this one on the other side is something you do on your own and then you present it to the team. You can also just share it, but ideally you should present it. And that defines a bit better how you see yourself and how you define your goals. So that's, for example, the do's and don'ts, but also your hopes and fears, and that helps you create better empathy within the team and to understand better who you are working with.

Collaboration processes

[00:06:08] Then the second topic we have is collaboration processes. If we imagine that you have this alignment meeting where you already define a bit the roles and responsibilities, you might still have some issues in how to work together, and that can lead to having too many meetings, or spending too much time on making estimations. Maybe you spend a lot of time being very frustrated because a PM has very specific deadlines and didn't reach out to know if the deadlines are reachable or not. Maybe an imbalance of tasks between bugs and technical tickets and features. All this is leading to frustrations. Maybe the scope of tickets isn't very clear, maybe the tickets are too detailed or not detailed enough. Maybe you feel micromanaged, or maybe you don't have time to do writing, documentation or tests. All these are micro, or actually bigger, issues that are in the collaboration process.

[00:07:09] How can they be addressed? It's actually very easy, I would say. It also goes back to communication mostly. So again, if you have this one meeting where you define together as a team how you want to work, also take the time to define your workflow. That could be defining the methodology: do you need to do Scrum, do you need to do Kanban, do you need to do anything else, do you need a mix? What makes sense for you? Do you even need estimations, or maybe you find them useful, maybe you want to drop them? What is the level of detail you want to have in tickets? Maybe if you work with more junior developers in the team it will be more important to define more, the tickets need to be longer[?]. But maybe if you work with more senior people, they might find it like micromanagement. Discuss this and really see what works for you and what you want to have.

[00:08:02] Another thing that I really found helpful is the definition of done. I was surprised how many teams did not have something like this written down. It makes such a huge difference, because basically you define when you consider that a task is completed. And if you include there that the documentation is to be updated, or that the test needs to be written, then you can ensure in the long term that it doesn't become a frustration that documentation is not working or not up to date, or that the test coverage is bad. Because if it's included in every ticket, then you spend this time every time. You just have to make sure that this is clear for everyone and that this is what you want to have.

Deadlines

[00:08:41] Another thing that was mentioned was the issue with the deadlines. That seems to be a big pet peeve of many developers, and I believe this is really on the product manager, not really speaking with the teams. But for this also there are solutions. If you have a deadline that seems unreasonable, then mostly there are two things you can do. You can negotiate either on the scope of the feature, so what needs to be achieved if the deadline cannot move, and what can you achieve in that given time. Or you can negotiate on the time: if the scope cannot move, then you can extend the deadline. There's no other way. It has to be one or the other, if it's not possible to achieve the given deadline for a specific scope.

[00:09:23] What I've found really helpful for negotiation is the use of story mapping. Basically here you have a framework where you design, or you document, the whole user journey and what tasks are needed for each of the steps. And then you can use this format as a basis for discussions with your development team, and really see, for each of the steps, what is needed now and what should be pushed to the next release or even further down. Use this as a collaborative tool to discuss what deadlines you want to commit to.

Urgent and unplanned work

[00:10:04] We also have the so-called mysterious urgent or unplanned work. This again I think is something that happens a lot, especially for maybe more junior[?] PMs when they don't really know how to say no, or the strategy is not always very clear. And that leads to requests from management that are not stopped or pushed back and then come to the development team. Maybe also some stakeholders. Maybe sometimes it's even the product manager that comes up with some genius ideas that have to be squeezed somehow into some planning.

[00:10:39] But for this also there are easy ways to fix it. And I say easy — it's not always easy to implement, but the solution is not so complicated, I would say. The first one is just say no. That applies both for the PM, so maybe try to push back ideas first, or for the developers, also just try this. It happened to me that I pushed some unplanned work to my team and then the team just said no, and I looked very confused. But then I had to go back to the people who asked me, and then I also said no. I don't think it was the last time I actually just accepted something without really considering if it really made sense.

[00:11:16] But if you don't want to just say no like this, another way is maybe to ask questions. Maybe you can ask, does it really make sense, what is the value of doing this now, what happens if we don't do it now, and what else can we drop if we have to work on this very important thing first? So really start a conversation. And maybe the PM will discover, okay, they didn't have all the input they need to have, maybe they need more input, maybe they need to do more homework. Or maybe they do have answers and it really makes sense, and then it's much easier for you as a developer to understand why this needs to happen now.

[00:11:55] And other ways are to make compromises. That's basically for many more projects where you do have this happening quite frequently. I was in a team once where it was really hard for the teams working with us to plan their campaigns — it was a marketing team — to plan their campaigns and events. So we knew every time, at sprint planning, some unplanned work would come in. And then what we agreed on with the team was to take three joker tickets per sprint, basically. We knew those three tickets could come up every time and they were not planned, but we knew they would happen every time, and just knowing we had this option actually made it much easier to deal with.

The why and the how

[00:12:37] Another one of the issues we have is the why and the how. So that's everything that goes around understanding the vision, understanding the strategy, understanding the direction. And mostly where it comes to a problem is when there's no vision, no strategy or no direction. That doesn't mean there's none in the company or in the product team, but that means usually that the developers, or the team working on the solutions, are not aware of that. So maybe the team knows the strategy, maybe the PM knows where the team should be going but doesn't communicate it well enough.

[00:13:13] That also comes to teams being asked very late in the process. So not so much when they define how the solution should look like, but they're given already the solutions of how the solution should look like, which also can lead to a lot of frustration. Because you have experts or very skilled people, and then you don't really ask for their expertise, you just give them solutions that they have to implement.

[00:13:39] What can we do against this? First, if we go back to this — I'm a huge fan of this alignment meeting, maybe you've understood that now. That's basically when you start a project or when you start to work on a new product team, you want to align the team on what the goals are, what you want to achieve with the specific product, what do you try to achieve for the users especially, and make sure that everyone understands that.

[00:14:06] I think it's essential that you have the time to ask questions, not only in this kick-off meeting but in general, and ideally also from people involved in the strategy. So that could be, if you have an all-hands meeting for example, that people can ask questions there as well. Or you can organize maybe a fireside chat with someone from the leadership team who can really answer questions from everyone in the team about where the company is going, where the product is going. Maybe someone from the product leadership team can explain what do we want to achieve for users, and that should help the developers, the designers and the team to answer these questions when they arise.

OKRs, product vision and dual-track development

[00:14:54] Then another tool would be clear OKRs, but also the product vision, and research time. I will show you those three in a bit more detail. So, OKRs. I guess now everyone is familiar with OKRs. I'm not sure OKRs are really in every company. I've seen many companies also doing weird versions and maybe not always very helpful ones. But essentially, if it's done properly, OKRs should be a way to ensure that every employee really contributes to the overall goals of the company, because as you see here in the graph, everything is linked to the company objectives. So that also ensures that not only should everyone understand the why and the how, but also that they have a direct impact on that.

[00:15:44] There is another tool, that is the product vision board, or product vision in general. You don't have to use this specific template, but basically the idea is to have a one-pager where you have all the essential information about your product. For example, who the product is for, who's the competition, what you want to achieve, how do you get revenue, these kinds of things, on one page, on one board that is easy to access.

[00:16:11] Why is it important? Whenever there will be questions on what solution to decide on or which way to go, then it's easy for the team to go back to this and reflect and take their own decision. Because your job as the product manager is not to come up with all the solutions, right? It's to empower the team to build things that make sense for both the users but also for the business. And this is possible if you give them all the information they need, and they have very easy access.

[00:16:45] If you're a developer and you don't have this, maybe ask your PM: maybe they have it and they can share it. If you don't have it, maybe you can create it as a team. That's also a very nice exercise to do as a team, to work on this together. And if you are a PM and you're not able to answer all these questions, then maybe you need to do some more work, and then make sure that you have all the answers in case questions pop up down the path.

[00:17:09] The other one is dual-track development. The previous talk also mentioned this graph with discovery and delivery in terms of design. There are basically similar things for product development. So you have two phases. One is discovery, which is essentially about building the right things, and then the delivery, which is essentially about building the things right. And we say usually that design and product should be involved mostly in discovery and then developers should be involved mostly in delivery.

[00:17:52] But still, even if this is true, I believe it doesn't mean that they are silos. So developers have to also give feedback on ideas, on solutions, on prototypes, on a regular basis, and really be also part of this discovery as well. How can you do this? You can maybe decide together as a team with your stand-ups, and every time after the stand-up we take six, ten minutes and we discuss solutions or prototypes. You can also say, once a week you have a meeting where we discuss solutions and prototypes. Find what works best for you, but have this discussion and really include all the teams and all the team members not only in how to build things afterwards, but also in deciding what you are building and what might make sense, and use all the skills from every expert you have around you to really shape the best solutions.

When the PM is non-technical

[00:18:40] Another thing that came up a lot was the teams where you have a PM in the team and the PM is non-technical, and this creates a lot of issues. Mostly coming up here on solutions, because the PM doesn't [?] such an idea, and that happens mostly when you don't involve the team in this discovery phase that I just discussed.

[00:19:06] It can also lead to underestimated work. Mostly a PM thinking that's super easy to implement, we'll do this, it's a no-brainer, and then they don't realize that behind this there's this huge pile of legacy code that cannot really be touched, or it's much more complicated than expected. And this leads to promises to stakeholders about when this can be done which are not reachable, and you have this loop of frustration coming up. Also sometimes just not being aware of the dependencies, and what might appear should be easy at first sight might involve different projects, different people, different technologies.

[00:19:43] And also the appreciation. That happens when you think this feature was done very, very easily and very fast, and then you don't really appreciate the developers for making the effort and the investment of time sometimes, and you don't really appreciate how good the solution or the feature was.

[00:20:05] For this there are different things that I like to do. One is shadowing. Shadowing is essentially like pairing, but when you're not able or ready to give any good input to the developer. So that means you would pair with your project manager, for example — the product manager will just see what you do and can ask questions. That would be shadowing, which is helpful when you want to understand better how someone works, but also have the option to ask questions about things you don't understand.

[00:20:39] Another way to teach a non-technical PM to be a bit more technical is to have catch-up sessions. And I say planned catch-up sessions, because I believe this is essential: if you don't plan them they won't happen. But having those catch-up sessions really helps in the sense that you can have a dedicated person you can ask questions whenever you need. And that can be for example a CTO — I was once in a team where the product was very complicated and I had an hour every week to ask. But it can also be a lead developer[?] or any developer. You can also rotate, if no one wants to spend an hour every week. Decide how much time you need and who can do it, but really make sure to plan them so they happen, because otherwise this always comes back at the very back of the list. So make sure to plan this and get on board, and the more you do them the more technical you become.

Technical debt

[00:21:39] Also related to this: when you're not so much a technical PM it's really hard to deal with technical debt. So that's also something that Rory mentioned earlier[?]. Obviously we want to avoid having technical debt, but sometimes you also want to be out there really fast, to learn really fast, these kinds of things, and it will happen anyway. So how can you deal with this? This gets frustrating when the business doesn't really see the value of fixing or addressing the technical debt.

[00:22:09] For this, what can be helpful is just empowering the developers to create their own tickets and then pitch them, and you as a product manager, you should be there to help them to assess the impact and then plan these against other features, for example. But also what worked for us about the technical debt was, because we were working with OKRs and we had these two weeks of alignment every quarter, that we took those two weeks to work on technical debt. So we had, per quarter, two weeks dedicated to this, and then we ignored it[?]. But then also it's up to you to define what debt you have and what's the impact of it: is it needed to address it now or can you address it later, and how do you want to address it?

Feedback and impact

[00:22:51] And then, feedback. That's one of the core things I've discovered by talking to people about what they enjoy about the job: it's really to see that they've done something that is used by people and that it has an impact somehow. I believe this is not only restricted to developers, I think also for many other jobs this is very important, that you see that you're doing something that is valuable and that has an impact. But this is also true for developers. I've seen many times that they were not really aware of users using the products, or not really aware of the impact that it has on the business, or not really aware of the impact at all. So they do a great job but they have no feedback; this feedback loop is missing.

[00:23:44] For this, there are three very key elements to consider. One is, if you're working in a product team, most likely you have KPIs or metrics that you want to move. If you're a PM, probably you check those metrics, but maybe you don't share them with the team. If you don't, maybe start doing this. And if you're a developer, maybe ask your PM to share this. It's nice if you have a dashboard they can go back to, but I also think it needs to be a bit more actively shared. So if you have team meetings, make sure to include a bit of time where you go through the metrics and you can really show the impact you had. Maybe you can also have discussions on what can be done to go in that direction even better and move those metrics even more.

[00:24:26] Another one is the user feedback. That is essentially seeing how people use your product, or discovering how they use it. That can be, if you work on an app, go in the App Store, in the Play Store and see what people write in the reviews. That can be, if you have a support email, maybe check in the inbox and see what people complain about in your product. Maybe you can also go on Twitter and see what people tweet about your product — I don't know if people tweet that much any more about products, but see where the conversation is happening about a product — and then get this feedback and this understanding of what is said. It might hurt a bit at first, but if you don't check it anyway, you're not aware of what you can improve.

[00:25:13] And user testing. This was mentioned as well. I think designers and PMs are pretty used to that, and I see more and more developers also getting involved in that. But if you're not doing it yet, maybe ask to be involved in the user testing, or maybe you get videos and then you can get the whole team together and watch videos together and then also discuss solutions and issues of users interacting with your product. I've seen the best solutions coming from the developers seeing the users using the product, and most of the time they also thought about things that I would never think of, because we don't have the same skill set and we don't have the same mindset either. So join all the forces and check what you can do together.

Freedom to try new technologies

[00:25:57] The last one is the freedom to try new technologies. New technologies are something that is, I think, especially important for developers, because you always have new things coming up and you want to try them. And as cool as it is to work on impactful things, I think it's also very important that you have this freedom to innovate and try new things as well.

[00:26:26] This is not always possible, for different reasons. First, because the business doesn't always see the value in this and doesn't always understand why it's essential to also innovate and also keep people up to date with new technologies. Another thing is that usually, especially if you're in a start-up environment, you're always kind of in this firefighting mode where you don't have time to do new things and we just want to get things done as fast as we can and create value, these kinds of things. So the business does not always see the value in this, and it's not always accepted, which leads to frustration, leads to people leaving. This is something you want to avoid.

[00:27:07] But luckily there are ways, there are always ways[?] to show this value to the business as well. You just have to tweak a bit the scenario and the narrative here. One is for example pet projects. We had a developer who wanted to learn Go, but we had no Go in our environment at the moment. So what we did: we needed a microservice, and then he managed actually to pitch that this microservice would actually be a really good fit for running Go, and then we got two people working on the prototype for this microservice in Go, and that's one of the services that we have running now.

[00:27:45] Another thing is you can dedicate time. I think Google is very famous for this, and not everyone's Google of course, but maybe you want to dedicate one day every month, or every Friday afternoon, or you can say every Friday. It depends on the company setup, I don't know what you need to do, but see how you can dedicate time on a regular basis to allow people to try new things.

[00:28:10] And if you need to have this business impact a bit more present, you can also go for hackathons or hack days. Many more companies are doing this now than a few years ago. But basically you can go from a business problem that you want to solve, or even user problems that you want to solve, and then leave the creativity to the teams to really experiment and come up with solutions. So that can be a good way for them to try new things and at the same time to have an impact for the business.

[00:28:38] Another thing that can be done is also internal conferences. Internal conferences can also be a way for people to grow[?] their skill sets and then maybe teach others or have a talk about it. And if you give them a few hours to prepare for this, that's also a good way to push them to go a bit deeper. So with those examples, you can really see how much time you have and how much time you can let people invest in this learning. But there are ways to do it, because if you don't do it, the issue is that people will get frustrated and other companies might have these options for them.

What I would recommend

[00:29:09] In short, what I would recommend. I truly believe communicating is very, very important. Without communication you don't understand what the issues are and you don't understand the frustrations, which let people leave in the end. So if you're a developer, be proactive. If you're a product manager, be proactive in asking your team what can be improved. But either way, if there's any point of frustration that starts to arise, be proactive in addressing this, communicate and ask feedback.

[00:29:47] So it's very important that you have this psychological safety in teams where you can really share issues and also ask for feedback on what can be improved in the team. Define what's not working and see really what is the issue. If you feel you have too many meetings, is the issue the number of meetings or is it the quality of the meetings? Maybe some of the things may be essential, maybe some things can be dropped, maybe the format can change. Really try to understand what the deep problem is and not only what is the tip of the iceberg.

[00:30:22] Then find a solution that fits that problem. If you have a small problem, there's no need to have a heavy solution. You don't want to kill a fly with a bazooka. So try to really understand the problem and find a solution for that specific problem. And obviously review and iterate as needed. I think if there's one thing that needs to be kept from all the other methodologies, it would be the retrospectives, or any way to really reflect and iterate, because that's the only way you can manage it in the long term, I believe.

[00:30:58] Here are a few references that I mentioned. If I share the slides[?] with you, you will have access here to all the different things I mentioned. Another one that I didn't mention is the Health Monitor for teams from Atlassian. They have a website — even if you don't use Atlassian, they have a website full of super nice playbooks and tools that you can use. If you've never had any experience with assessing what can be done together as a team, highly recommended, super helpful.

[00:31:29] But also, if you have more questions, or if you have more issues that I haven't addressed here in the talk, I'm always happy to discuss this, because it's really a pet project of mine. I really do enjoy getting feedback and iterating myself on what can be done for teams. So do share it with me, or join me at five and let us discuss this. Here are the details where you can reach me. Share your feedback, ask questions, and I'm happy to have a conversation.