Transcript
Barmash: First of all, this talk is about collaboration between technical leaders and product managers. A very quick agenda - we'll start talking about keys to effective collaboration, then we'll talk through a few scenarios and frustrations that Khadija and myself brainstormed that are common based on our experience. We'll do a little scene at the end about conflict resolution.
Ali: Just a little bit about myself: I'm currently a director of product at Better.com. Before this, I worked at Compass for four and a half years. I was with that team for quite a long time and before that, a senior PM at Chloe and Isabel.
Barmash: I currently work as VP of engineering at Komodo Health, which is a healthcare analytics startup. Prior to that, I also worked at Compass. Together, we worked for about 18 months side by side, day to day. We shipped three new products, as well as did major revisions for two other products. We had a lot of things that we jointly owned.
Ali: Yes, this is an authentic relationship. This is a relationship where we were tech lead and PM on the same team.
Barmash: Yes. It certainly took some ups and downs for us to create that collaborative relationship. We're going to try to share some of the lessons learned here.
Defining Keys to Effective Collaboration
First of all, what are the keys to effective collaboration? The five that we came up with are empathy, building trust, communication, role clarity and accountability around that role, and negotiation and conflict resolution. In fact, those of you who have been to a few of our sessions, you can see that this mimics a lot of the topics that we talked about in this track: communication, asking questions, empathy, negotiation, and other good stuff like that.
Let's quickly talk about what are some of those things. Empathy is perspective taking. It's, do I understand what the other person is going through? What are some of the pressures that they're under, so that I can understand their perspective, and maybe come up with a solution that isn’t just "me, me," but also takes into account what their needs are.
Building trust - hopefully, most of us know what trust is. It's basically being able to rely on the fact that the person you're working with will do as they say, and having a track record. One framing that I like to think of it is, there are two dimensions, there is intent and then there's capability. Maybe I trust your intent, but I don't think you're up to the job. Or maybe I think you're very capable, but I fundamentally think you're out to get me. Therefore, that's obviously a barrier to trust. The goal in pretty much all of collaboration relationships is how do you create that environment of trust together?
Ali: Communication is a big part of my job, but sharing information and context with each other is so critical to my relationships with my tech leads at work, and for us to actually effectively produce great products. The key is not to make assumptions; the key is to ask whenever you don't know. I prefer for folks to actually overcommunicate. I think that goes on both sides, not just product, but also on the tech lead side. Another key part that I think a lot of people miss out on the communication skill set is also knowing when to communicate and when not to communicate, that's also key. I won't talk a lot about when not to - that I think is very specific to each one of your organization and stakeholders.
Then role clarity and accountability. I find that as a product manager, a lot of folks even on the engineering team do not fully grasp my role. A big part of this is because in many organizations, product managers are different. To be honest, we have to have a real "come to Jesus" is what I call it, where the truth is about product, it's different in most organizations depending on their needs. With that said, it's so important to, one, ask questions, don't make assumptions on what your product manager thinks their job is and the same for the tech lead also. For product managers who sometimes are far more technical, they'll assume some sort of a tech lead position. You're, "No, that's not your job," so, holding yourself and each other accountable.
Let's just go ahead and define the roles, I mentioned a little bit about it. On the tech lead side, point blank, engineering owns the how. I really am big on respecting this. When I go into a meeting with a tech lead, I'm not going to say, "This is how we should build it," that's technically not my job. I'm very clear about that, I appreciate that because I did not have an engineering interview when I joined the company; I had a product interview. On the flip side, on the product side, we focus on the what and the why and part of the why is the who. That's a big part of our job. To be honest in practice - I put it up there - but it is important to know there's a lot of gray in between these two. That doesn't mean that I own it, and only I can contribute to it; I think we both have some room for collaboration on both of these responsibilities.
Barmash: Yes, in practice, there are a lot of gray areas because once again, this is a partnership, so things do get blurred. A lot of this talk is trying to explore some of those blurs and how to think about different things. Let's get a little bit deeper. Technical leads, as Khadija mentioned, they own the how. What does that mean? First of all, fundamentally, it's about creating a technical strategy as well as delivery strategy around either the business goal or, in this case, the product goal. Tech leads are typically supposed to be focused both on the immediate delivery, "How do I get this feature out the door?", but also thinking a little bit more medium, as well as long-term, about the health of your technological system or architecture.
You should also be obviously rigorous about engineering practices, "Do I have right deployment, do I have the right build, are the code reviews being done?" You also care about non-functional requirements, so things like performance, scalability, security. Product managers will obviously come in with a point of view on those, but a lot of times, you will be the person who will bring up the issues there. In general, I very much ask of my tech leads and myself to come up with a point of view to the discussions, for example, road mapping.
Product's job is fundamentally to come up with a bunch of features that will bring value to customers. Our job is to think about what are the needs of the technology systems, so that we're delivering now, as well as in the future, with a reasonable and hopefully, increasingly high velocity. Then, of course, tech leads have other jobs that start crossing over to people management, such as coach and mentor engineers on the team, even if you're not explicitly a people manager.
Ali: In terms of product management, I get this question sometimes from engineers, usually more junior engineers: Why do PMs exist? Why do we need them? To be honest, I can see why this question sometimes arises. It's because a lot of times, engineers don't actually have a lot of insight into what we do day to day, who do we interface with, and what are the key parts of our job that we may not be showcasing every day to them. It's a huge part of our job to understand what to build. That's so important to the business. It's also really difficult to define, to be quite honest. There's a lot of room for failure there.
Not only that, but in determining that are also facilitating stakeholders’ needs, designs, thoughts, as well as engineering. Just sitting in the center of all that and bringing it all together from a strategic perspective is a big part of my job. Keep in mind - I think this is something that people do not also pay attention to a lot - a PM usually is not the person building the product, sometimes can't even build the product, may not even understand how it's built. Then they're also the person who's not designing the product. Typically, a good PM can wireframe, but they're definitely not going to be better than their UX counterpart.
On top of all of that, they are working with all these folks, managing them to help deliver this product, but none of them actually report to them. Imagine, you're working with all these people, and you're, "We’ve got to get this done. This is the strategy. This is what's key for the business," but you really don't have any authority over anyone. Going back to Roi's [Ben-Yehuda] presentation, which was earlier if some of you were here, a big part of our job is influence for the benefit of the business and our customers.
Barmash: The fifth major aspect of great collaboration is negotiation and conflict resolution. We're equal partners; neither one of us reports to another person. We must discuss disagreements and come to some compromise for the best thing to do for the business. This is a great opportunity for win-win. The way that I think of it is, the roles are designed to be in conflict. One role wants "More, more features." The other one is, "I really care about architecture." Clearly, there's a very fundamental tension here. We need to come together and figure out the best solutions.
The reason why I think this ultimately works, and a lot of organization adopted product manager, tech lead, dichotomy, is specifically to get the best out of teams. If one person has one perspective, and another person comes with a different perspective, and we figure out what is the most valuable thing that we can possibly ship in a reasonable amount of time, that's ultimately the way we deliver the most value.
Here, I wanted to remind you that the Venn diagram of the two is, yes, there are a bunch of product concerns, there are a bunch of engineering concerns, but fundamentally, we both have a very common goal, which is deliver value to the customers or deliver against the mission of the team. Therefore, we have a lot of common ground to build on. Once again, the five major keys of collaboration: empathy, building trust, communication, role clarity and accountability, as well as negotiation and conflict resolution.
PM and TL Frustration Examples
Ali: Now, we want to look at some real world scenarios that have it all the time between product and engineering, in terms of frustrations, some which I've actually experienced in my career. One is architecture. An engineer wants to spend weeks and weeks on thinking through the architecture, or would actually rather build it in a much more scalable way when we haven't really effectively tested even the feature. How would you deal with this?
Barmash: Well, Khadija [Ali], that's because we do have to think about things. We want to design the product in a way that we're not just delivering something right now, but we'll be able to continue delivering for you when you come with additional features. Also, I know that when you design this feature, by the time you came up with the product spec, you spent weeks, maybe months, talking to different stakeholders, thinking about the different interplay there. Hopefully, I was there with you in some of that journey. You actually spend a lot of time. Now, we're trying to spend the time on our side, to think through the problem from a technical perspective so we can come up with something that's pretty great for you.
The engineering frustration is when a PM asks for a large feature, and it's so large. You're, "Ok, this is going to be many months of work, why is she asking for that? There are clearly ways that we could potentially phase it, doesn't seem like she thought through how we might phase it over here. It seems like we might be able to perform some experiments to direct some stuff. What gives?"
Ali: Actually, I'm so guilty of this, just to put it out there. I'll tell you why, I have a very good reason. Earlier in my career, I used to actually come in with very scoped features. What I actually realized is my engineering partner then didn't have a vision of actually what I wanted end to end from an experiential perspective. This is a huge mistake that PMs do. I want to present you with the big picture and then us work together to phase it out. It can only be done effectively that way. PMs come in with features that are super MVP, and I know there was a world where that was super celebrated, but I think the key is "Let's partner up together to actually figure out what those phases are and how we have actually develop those experiments." Because then, we're setting ourselves up not only just for the product success, but also how we actually intended to build it. That doesn't necessarily mean that everything will be done from an architectural perspective. If we decided to hack, it's a hack, but we're on the same page and we know why.
I actually think this is something that should be encouraged. As tech leads, I think the one thing that you guys need to keep in mind is that don't make assumptions and say, "You just came in with a five-month long feature. Is she serious?" No, actually, maybe you should ask and say, "You do realize this is five months long? Let's talk about how we can break this out." The other thing is they may not actually know how much it costs, so it's fair for them to come in with a big feature and for you to cost it. Again, your responsibility or accountability, role clarity, and communication all wrapped in one here.
Barmash: Who here experienced this frustration? Quite a lot. All right, PM frustration. Go ahead.
Ali: I get this all the time - I want a perfect spec, I cannot start building this until you have thought through every use case, every edge case, every little thing you want. It's just unrealistic. I get it, you're working with a computer, and computer is really dumb. Essentially, in order for you to do your job well, you don't want to make any assumptions. In some instances, it makes a lot of sense. This is one thing I'm really frustrated with, but I'd love to hear actually, Jean [Barmash], how you would go about it.
Barmash: From my perspective, an engineer on the team, first of all, should have some business context overall with problem they're solving. Certainly, they need to understand the product, it's pretty fair that you give them 85% of the solution. There are some gaps that they should be able to close by themselves. Of course, they can always also reach out, ask additional questions, point things out during the sprint planning "Have you thought about this?" No person is perfect. In terms of having empathy, your product manager did not have infinite time to write every single ticket. They're trying to move things along.
We take some compromises, because we could spend another day on cleaning up the code and making it super elegant, same thing from the product perspective. We just need to work together to figure out what's the best thing. Engineering frustration is when the PM does not act as the CEO of product. There's a whole thing in the industry that the PM is the CEO, and why aren't they just calling all the shots when it comes to product features?
Ali: I hate this. I literally think this is the biggest mistake when they coined this term as the CEO of the product, because I think a lot of people first off - actually the majority of people - do not know what it's like to be a CEO, so you can only assume what they think of when they see this. It's the person who comes into the door and goes, "I'm in charge now. This is what we're going to build, no questions asked. Don't answer back, build it now." How many PMs do that? Very junior, hopefully. Nobody senior in your organization is doing this. But I think this was a very huge mistake.
I think we're now figuring it out in the product industry that this is really not the way it should be. We are facilitators. We are the folks that yes, we do make the call, we take accountability when the product does not work out or is not a success, it's on us. The business can point to me and say, "Khadija [Ali], what happened?" But at the same time, I want to make sure that I'm taking into consideration your thoughts as engineering leads, but also my stakeholders, and especially the real CEO. I always tell junior PMs, "Yes, you're the CEO of the product, but there's actually a real CEO here." I think this is a really great one, I hear the frustration.
Barmash: Plus, I think the CEO obviously has a additional source of power, which is that everybody reports to them, where product manager does not. It's much more of an influencing position through ideas.
Ali: I have had this happen where a tech lead is involving himself or herself in product work. I think product is really sexy for some people, because it looks like all I do is just say, "Yes, do that. Yes, do this. Call the shots." It looks really glamorous if you really don't know what's happening. At the end of the day, I say, "I'm the janitor. I'm the person doing the QA when there is no QA. I'm the person who needs to facilitate everything and any gap that is happening in the product development process to get the job done." That's not really always glamorous, especially if you're dealing with challenging stakeholders, which I'm sure we all have in our organization. How do you broker that deal? How do you negotiate? How do you manage these conflicts?
Barmash: I think this is definitely one of the gray areas because as an engineer, you're hopefully thinking about the product. The product manager thinks about the product 80% to 90% of the time, you're probably thinking about different product features and understanding user frustration 10%, 15% of their time, but obviously, you do have ideas. A good product manager should be humble enough to realize that great ideas come from anywhere.
Sure, maybe you shouldn't write a 10-page spec for new product feature unless you specifically discuss it with your product manager, but certainly coming up, "Have you thought about this way? What about this approach? Did you realize that from what I heard, there seems to be a problem with customers in this area? Would this solve it?" So approaching it from a very both humble perspective, and that's where some of the influencing negotiation stuff comes in.
Ali: In some instances, there really isn't a PM on your team. If you need to fill this gap, I totally get that too, and it happens. I just want to highlight that, that's an important note.
Barmash: Another frustration is when PMs don't include engineering in the planning process. Anybody here face that? Ok, quite a lot.
Ali: Yes, this is a common mistake. I think, to be honest, it's so important to be empathetic. I know, as a PM, I'm asking for empathy on this one. The reason why is, I think, as a product manager, you make a lot of assumptions. One is, "My engineering team doesn't really have time to be involved in planning. They're so busy trying to get this done." The other one is, "I don't think my engineers are going to be so excited to be sitting in on user studies or design prototype." There's a lot of assuming.
I think when you see something like this, it's about communication. "Khadija [Ali], I would like for us to be involved in planning a lot earlier." To be honest, this is a real story between Jean [Barmash] and I. I think being heads down so much and just in that rat race of going at full speed, especially if you're working at younger companies, you sometimes forget, "Oh, yes, I should include." Jean actually reached out, and was, "I'd love the team to be more involved in planning up front." I'm, "Yes, it makes total sense."
Barmash: As an engineering leader, this is also an opportunity for you to set expectations with your team. For example, if you're working on a product that gets shipped to users, then certainly understanding your users for engineers is hugely important. You can set that expectations that you are product engineer, you need to at least know something about the users. Yes, you're not going to go to every user feedback session, but maybe you'll read the summary once every few weeks, and you should attend once every month or once every few months.
Ali: This is a big one. You come to your tech lead with a feature and they just say, "No, it can't be done." It happens all the time. I love it, it's like a showdown, it can't be done. I'm, "Ok. Do you have maybe other options, or can you explain some tradeoffs?" Then they go, "I didn't expect you to ask that." Jean [Barmash], you've been in this situation with a PM. How do you actually help to alleviate this frustration?
Barmash: Once again, this is your job as a tech lead. If you're not offering options, then what are you doing there? If you're there to just say no, that's not really collaboration. I think this is an opportunity to understand where the sources of value are. What is the most valuable thing that we could be doing? Because maybe you can actually find the things that are relatively cheap to do and relatively fast to do that are the most valuable, so until you have that engagement and really understand. Thinking about options, and being able to communicate them effectively is very much one of the core aspects of the job of a tech lead. I guess another frustration is when a PM does not prioritize technical debt.
Ali: How am I supposed to know? Literally, how am I supposed to know?
Barmash: This is an opportunity for you to come in with a point of view. The product manager is thinking about what is the value on the business and customer side. Your job is to come in with a list, as well as explain what is the return on investment of the different initiatives, but have a very real conversation. Only if you put everything on the same chopping block, can you then tradeoff technical improvements from product features. I know, at the end of the day, it's always difficult to do something that's maybe not clearly functional. Yet again, part of your job is to get better at explaining the return of investment.
For example, "We're building this humongous new product, but first, we need to spend two months refactoring, and here is why, because we created some model that no longer makes sense in the new product that we're trying to build. We can't avoid but having to basically remove it." Everybody understands that feature exists. Everybody understands that this feature will not exist in the new product. Obviously, some work needs to be done in order to address that delta.
Ali: I think from a product manager perspective, we'll return the favor of you actually bringing this up and making sure that it gets placement on the roadmap, and highlighting the risks of not doing it now versus later, by going in and actually defending this item on the roadmap with business stakeholders. If you can't explain this to a PM, imagine explaining it to someone in marketing. They're, "This doesn't have business value right now. This is not really addressing a need. How is this serving customers?" There's always this suspicious, "Are you guys just making stuff up?" It's like, "No, the PM will actually be your partner and help to break that down, and really take a lot of the ambiguity around what this really means and how this will actually impact the business in the future."
Negotiation & Conflict Resolution
Barmash: Let's come back a little bit to negotiation and conflict resolution. We'll basically go through a very quick scenario that I think is very common, which is product puts pressure on engineering to deliver something quickly. We're going to do a little role play. As we do the role play, here are a few things for you guys to keep in mind.
Ali: This is the scene. I'm going to lay it out really quickly before we actually get into it. We both work at a SAS company, Imagine. I'm coming in with a request.
Barmash: Here, this is what's happening, Khadija [Ali] is going to try to hold me accountable. I am going to try to understand a little bit more about the business. Then the product manager will explain a little bit some of the pressures that she's facing from her side. I'm going to try to basically understand how much flexibility there is in what she is really asking me for. Then we go into solutioning mode, and hopefully come up with something useful.
Ali: Do you remember that feature I was talking to you about, the invite feature?
Barmash: Yes.
Ali: I need this in a two-week sprint.
Barmash: Yes, I talked to the engineers. We did some thinking, it's about four weeks. Minimum of four weeks, unless we completely hack it in a super crazy away.
Ali: I'm having some difficulty with that estimate. Four weeks is a lot, that's a whole month. To be quite honest, I just feel like maybe there's no clarity around the business need and urgency around this feature.
Barmash: Yes, can you maybe tell me a little bit more about what are the drivers behind this feature? The way that I am understanding it, you want to invite additional users. There are internal users, external users, as well as groups of users, right?
Ali: You're right, those are the three use cases I highlighted that are a need for us for this feature. To be honest, digging in a bit more, I can explain the drivers. We need 1,000 paying users. The urgency is really that we're raising right now. We're raising our D round. We need to paint this really perfect picture to investors around growth, obviously, most companies, meaning more than 1,000. For this instance, it's 1,000.
I actually did some digging with the data. The past sales pitches that recently happened to our users - looked at about 1,000 of them - and realized that they all didn't sign up because of not having this one feature. The ask is really to be able to share within the company between coworkers the dashboard feature. They can't do that today. I think that makes a lot of sense, I wouldn't pay for something if I couldn't collaboratively work with you in the same company and give you some insight into my dashboard and work. Raising is happening in two weeks. That's the other added pressure there.
Barmash: Sounds like you confirm that if we deliver this feature, that will move the needle?
Ali: Yes, definitely.
Barmash: Ok. Can you tell me more about what the most important things are here? For example, to give you a little bit of context, I think inviting internal and external users is actually going to be relatively easy, maybe one and a half weeks or so. The group users, that's basically majority of the four weeks estimates, frankly.
Ali: Actually, to be honest, that's a good point. I really don't need group invite, that isn't even part of the initial built. Really, again, going back to the drivers, it's really being able to share internally with another coworker. I think just one is fine. Then they can share it with someone else, instead of doing a whole group invite together. We can not include that for the initial build. To be honest, external invites, as well as don't really need it, just the internal invite feature.
Barmash: Once you do the internal, you can do external for almost no additional effort. If we're going to do one, we might as well do the other.
Ali: Just a quick question, just to remind me, that's not the build of the hack that you're quoting. You're thinking about building this in a scalable way?
Barmash: Yes. One and a half weeks is an actual build out. I think if we hacked it, there was about three days. However, we would still need to pay that one and a half weeks of full build out right afterwards because that's something that we're going to need to do to build the group feature.
Ali: Ok, I see. All right, this makes a lot of sense. Let's just settle on the internal and external since they're dependencies. I'll go back to the business stakeholders, and just let them know. Obviously, we still need to account for bugs and things that we may not know that could come up. I'll add some padding on to that as well.
Barmash: Ok, that sounds good. And scene. Those are some of the tensions that we observed. Once again, these are the keys to the collaborations that we have thought about: empathy, building trust, communication, role clarity. How do we make sure we understand what each other's job is, and to make sure that we are both doing it in the appropriate way. Then of course, conflict resolution and negotiation.
Questions and Answers
Participant 1: My question is, how do you sell this relationship up the chain? I think a lot of us understand this intrinsically and how these roles work. How do you get the CEO to understand how these roles work?
Ali: That's a really great question. I think I look to the CTO and the chief product officer to help me sell it. I think the thing is with CEOs who may not really understand this relationship - which to be honest, in New York I have encountered that - is that they need to see the proof in the pudding. You can't go pitch something and they don't actually see the result of it. I think the idea is having that open line of communication. I think definitely making sure you constantly say, when you have successes, "This is because I have a great tech lead, I have a great relationship, a great collaboration."
Another thing that Jean [Barmash] and I used to do is I used to go to rooms. We had already spoken before we got into our room about that agenda. There were no surprises, we were aligned around what we were trying to achieve in that meeting. Even with the CEO, we would say, "This is a problem I think is going to happen. He's going to ask about this. What are your thoughts on it?" We already had a mutual understanding of where each of us were coming from before we entered into that room, which meant that they met a team that was very much already aligned. It wasn't a matter of someone just spinning off their own thing on the side.
Barmash: I think the way that I would approach selling it to somebody is, first of all, to have a person who can both think about the needs of the business deeply and is technical enough is very difficult. Those people do exist, but they're basically founders of companies a lot of the time. I think you can point out that, if you have a working relationships, then you do get the best solutions. Once again, most value for lowest cost and the fastest.
Participant 2: I work for a team that is in the middle layer building APIs for all of our applications. I don't have a product owner; I have all the product owners. I have good working relationships with them, but is there any way to get out of the infighting between the product owners about priority of projects?
Ali: Sorry, I want to make sure I understood that question. Is the question, how do you define the priorities for the product managers or help them understand it?
Participant 2: How do I avoid being in the middle of that priority negotiation that they're working on?
Barmash: Sounds like you have a lot of people coming at you with different priorities, right?
Participant 2: We do. They work very hard to follow priority plans, but in the middle things get changed. My team has to switch gears, etc.
Barmash: Given that your team is very technical, unless your tech lead is able to have those conversations, which sometimes works as well, then I would encourage you to think about bringing in the technical product manager, because that's exactly the skillset that, I think, at least at a high-level would solve that problem. Somebody who’s able to talk to the different product people, somebody potential also reporting up the chain to the product organization. Therefore, they can get high-level priority from their leadership as well as adjudicate some those conflicts, but then can still translate those conversations to a more technical roadmap that your team requires.
Ali: Unfortunately, it sounds like you actually may have to play that role until you get that person. It's unavoidable, to be quite honest.
Participant 3: I think my question is similar, but from a different perspective. The role play you did was for a small feature that involves one team. Oftentimes, from what I see, there is an initiative. For example, we want to globalize our platform. That means almost the entire engineering organization is making changes across many teams and working. How do you suggest different product owners across the organization work with each other to make an initiative like that happen? Who should work along with them to make that happen, because obviously, there are many leads of different teams?
Ali: In your organization, is there a CTO and a head of product?
Participant 3: It's not a startup, it's a very large enterprise. You want to globalize the entire platform, something like that. That was one of the things where I've seen a problem.
Ali: I think this is where a tech lead is incredibly powerful. Product managers, yes, do make this mistake, but as a tech lead or anyone in that role, can definitely put their hand up and say, "This actually affects a lot of different places. Can you please go check with your other PMs before you come back to me about this?" I've actually had that happen as well. They may just not realize that it's making changes across. A lot of times, they will, especially if it's something as big as an initiative like that. If you put the onus on your PM to go do that work, they will mobilize together. You just need to tell one and just say, "We can't start on this until you've talked to everyone and really highlighted the dependencies." This is not something we can assume a PM would know, but more you highlight to them. It could be dependencies within the tech stack, all sorts of things that they don't have insight into. I think that's a good piece of advice there.
Barmash: Another additional thing to think about here is, first of all, are there executive sponsors for this initiative? Because this clearly seems like a very large initiative. Then, what is the execution mode around that initiative? It might make sense to have a product manager who’s thinking across multiple products and defining what is the work, as well as technical program manager who’s going to be in charge more of an execution piece, and tracking things down across the larger organization. I think the question is, what is the right supporting structure to facilitate that initiative? Because, yes, it does require a lot of communication, a lot of decision making, a lot of prioritization, which is its own job or multiple roles in a larger organization.
Ali: If there are gaps, don't assume that people understand those gaps. You will see it. Just say, "These are the gaps." I think there's so much power in that communication and even the person who's the tech lead of your team. I think that's key.
Participant 4: I think I've been in most of the scenarios you described. You touched a little bit on the technical depth. I guess my question is around, how do you negotiate or communicate beforehand and plan for when you're trying to build for an MVP? In that case, you are going with, not the perfect architecture, not the perfect solution, because you want to get something out fast and see if there's value to what you're building. Then let's say that the MVP actually goes really well, so you decide to build for that solution. You have to re-platform the entire thing. That will take basically duplicate the effort, and you can't use what you've built so far. How does that communication go between the tech lead and the product person?
Ali: I think in the beginning, as a PM, it’s communicating the use cases that I want to build for the need and what I think are, from a hypothesis perspective, the impact on the business. Whenever I go into a situation with a tech lead, where he or she has expressed to me that it will be a hack, I'm ok with that. I just think that we're going into this together. I'm going to communicate that to the business stakeholders and say, "We're going to test this out. This is just a hack. There's a much better and scalable way to build this," and probably Jean [Barmash] can speak to it more, "but by the way, I think right now, it's probably not worth building the scalable version, because it's just too costly, and we really need to test it."
Also, let them know early on that if this actually works, we'll have to revisit it. I think that's the mistake that a lot of people make, that communication is not happening very early on in the beginning of a test, or a hack, or MVP. It's like, "This is an MVP, let's build it. Ok, let's test it. Oh, damn, it worked. Now, we got to build on it." But nobody was involved in actually briefing everybody else involved around exactly what decisions we're making, and the result of that, and the impact in the future roadmaps. I think that's when you have set yourself up for success.
Barmash: To be fair, this happens a lot. Sometimes it's frankly unavoidable because you have an MVP that becomes a successful product, then you have to start moving fast. I think if you do communicate clearly to Khadija's [Ali] point, then at least you can set the expectations that, "Two months from now, I'm going to come to you. I'm going to ask for a bunch of time to catch up," and you as a technical lead should still come up with some kind of architecture and technical vision that you want to start pursuing, because even if you don't have time to actually execute on it fully, having a vision will allow you to start aligning around where you would like to be going. Definitely challenging situations. I recognize it is very rare - if you fail, nobody cares, you throw it out, you move on. If you succeed, that's when it becomes more challenging. But at least at a minimum, you can say, "Remember, I warned you. We're going to pay downs and re-platform before we move forward.
Ali: Another thing, too, to build a case even further, and I think this is important to know, is the business might really just not have time for you to build it the right way. It's the real world, businesses have to make money. I think sometimes in product and engineering, we forget that piece unless you're really involved in the revenue piece, which happens sometimes for product folks. But I think that at the end of the day, there is that pressure of getting users, telling the story to the investors or literally just hitting your bottom line that month. I think you have to take into account all of the pieces of data that influence your decision and then try to build something in a scalable way, especially if an MVP is a success and compromise. Part of our job is everyday decisions that we have to make a compromise on together.
See more presentations with transcripts
