NOEL:  Hello and welcome to Episode 29 of the Tech Done Right podcast, Table XI's podcast about building better software, careers, companies, and communities. I'm Noel Rappin. After you listen to the episode, you can join the conversation. You can follow us on Twitter @tech_done_right where you can get notifications of new episodes or contact us to let us know what you think. You leave comments on our website at TechDoneRight.io where you can also see our full catalog of past episodes. We're really curious about what you like and don't like about the show and who you'd like us to have on in future episodes. So, please let us know. And if you want to help other people find the show, leaving us a review on Apple Podcasts is a great way to do that. Thanks. 

Today on the show we're going to do something a little bit different. We're going to talk about developers from the external perspective of product owners. My guests are Cat de Merode who's the VP of product at Peapod and Matt McNamara who was for several years the product owner for Dickson, a Table XI client. We're going to talk about how they like to work with their developer teams, how to collaborate between developers and product on estimates, how important it is to communicate between the various stakeholders and a team and what developers can do to improve their relationship with the product owners. This is a show that I've wanted to do ever since the Tech Done Right podcast got started. I'm really excited that we were able to put it together. And here we are with myself and Cat and Matt.

Matt, would you like to introduce yourself?

MATT:  Yeah. My name's Matt. I am a product manager. I most recently worked for eight years at a small manufacturing company. And I'm now headed to a much larger, multinational corporation to do product management in their building management division. 

NOEL:  And Cat? 

CAT:  Yeah, so my name is Cat de Merode and I'm the VP of Product at Peapod.com. I started my career in the early days of Grubhub. So, I got to experience working in all sorts of different capacities, but really enjoyed working with the dev team on the frontend and the backend side of the software development process.

NOEL:  Yeah. And so, this is going to be a little bit of an unusual episode of this podcast we're not talking to developers necessarily as much as we're talking about developers. So, both of you have worked for the last several years closely as the product owner to a developer team. And we're going to talk about, what's that like? What developers seem like to non-developers and how you can improve the way that you work from both sides, both for people who are product people and want to work with developers, and developers who want to improve the way that they deal with product people. So, I think maybe to start with a real general question, what is a thing you wish you'd known when you first started dealing with developer teams that you know now about the way developer teams work or what makes them successful?

CAT:  Well for starters, that we all have to deal with each other, apparently. [Chuckles] The thing that I wish I would have known off the bat and it took me far too long to really understand is that we all are driven by something. We're all driven by the value that we're producing for the customer, for the company, for our own paychecks. And that each one of those individual motivations is different. And so, in order to get a team to get from point A to point B, it's my job in product to be able to make sure that I can tap into that motivation for each individual.

MATT:  Yeah, I'd echo a lot of that as well. For me, I learned on the job through and through. I had never had any product experience prior to this. So, a lot of what I learned about product management, I learned from the developers. So, that had a big impact on how I approached it. I've always been a little bit more technical, so that went a long way. But a lot of it as Cat said was just "What motivates people?" and "How do you get them to see your vision of the product so that you can ultimately deliver what's best for the customer?"

NOEL:  So, do you think that in the cases that you've been in, that the developer team is motivated differently from the product team? And does that make a difference whether the developers are in-house or are not? 

MATT:  That's a good one. I think the developers definitely have different stake in the matter than I do as the client. Namely, my goal is to provide a good product that I can sell to my customers. Where a developer, particularly one that is a consultant, would generally want to just get the work done, meet their hours, in kind of more of a, "Is this complete? Does it meet the requirements?" standpoint. They don't have as close of a relationship
to the customer or the end user as whoever is offering the product itself. 

CAT:  So, I would say that there are some distinctions in the value that each team member perceives. And there's obviously some common threads among them. So, what motivates me is, as Matt mentioned, the benefit that we're bringing to the customer, to the business. And there as aspects of that, that I understand there's value in, like resolving technical debt or unit testing or other non-functional requirements; performance, and things like that, that the developer might be a lot more motivated by than I am. And as long as we're all on the same page of, "Yes, I find value in that," and we have these particular constraints on timing or in terms of being able to learn from what we're able to release, then I think that it's really great to have both sides of that represented.

NOEL:  What kinds of things can you do to help developers understand your motivation and your goals? 

CAT:  There's no arguing with data. If you can get everybody rallied around the same metrics and understanding the same potential value proposition or benefit that their work stands to accomplish, there's really no way to argue with that, if you take all the emotion out of it. And those metrics by the way also apply not just to performance on things like conversion or reduction of bounce rate or other… I'm from the e-commerce world so a lot of our metrics come around revenue and things like that, based specifically on behavior of the site. But also, time to market and velocity for a given team and the burn-down chart and all of those data points that as long as we can all understand them and agree to them, we're removing the emotion. And so, it's less about opinions and more about learning and making data-driven decisions. 

MATT:   The business case impact from the product owner was really important to make sure the developers understood. But also, me understanding the technical debt that Cat mentioned and how that was going to impact our system or future growth of that system was really important for me to learn and understand how that impacted any decision I was making from a business standpoint as well.

CAT:  Yeah, the cool things that come up in some of the conversations in sprint discussions or estimation or planning meetings, some of the cool discussions that come up, I would be completely unaware as a product owner that there's this one specifically nasty piece of the codebase. And it works and we don't know why it works. And if we do anything in a remote distance of that area, it's going to multiply the estimate tenfold. So, that's really information that I take to heart and I try and avoid touching that codebase or that functionality in my future plans. 

NOEL:  Well, that's interesting. So in that case, when a developer is telling you there's something in the codebase that is very complicated or this is going to be more trouble than you thought, first of all, what kinds of things do you do as a team to build up a common understanding of the problem? What do developers do that's successful in getting that point across? What do developers maybe do that isn't as successful?

MATT:  At the end of last year, we did a kind of project retro that really worked well to, I mean we just went through the normal process. What worked well? What didn't work well? And a lot of it came about of what was the business case, that whole making the argument for the business case came about because of that meeting. It wasn't something I was doing particularly well before. But just expanding upon, "Why does this matter?" was really good. So for us, it was just having a normal conversation that you would do as part of project management, particularly an agile one. And that worked really well for us. So, just putting the topic on the table. 

We also had a meeting specifically dedicated to "What does the infrastructure of our system look like? And what does it need to look like to grow over the next year, two or three years, etc?" just to get an idea of "What were we going to be facing? What did we not need to start thinking about now?" So, it's more, again I hate meetings, but there were two meetings that just were really good in terms of helping outline some of those exact things and getting on the same page there. 

NOEL:  What you'd say then is it's very important for developers to have the ability to discuss with the developer team the issues that might be problematic in advance and not when everyone's under the gun and it's a heated discussion already. Is that a fair way to say it?

MATT:  Absolutely. But yeah, before things get contentious, just being able to talk that through when cooler heads are prevailing, just because it's just a general kind of conversation as opposed to maybe a postmortem on "Hey, this went wrong." Those are two totally different approaches to that meeting. So.

CAT:  One of the best traits that I've always found in a senior engineer is somebody who can just speak the language of whoever they're speaking to and with. So, if that means that I am fairly technical and they can sort of read that on me, then it's fine to use that type of language and help me understand what piece of the codebase is particularly gnarly. And then for example, if they're talking to somebody in the business and trying to explain "Well, actually that's going to involve 16 more teams for us to negotiate on dependencies with," then being able to speak whatever language and communicate with whomever is actually a part of that conversation. It's very helpful. 

The other thing that I think product might not get enough credit for is that we can smell BS. We can smell when… [Laughs]

NOEL:  I don't know what you're talking about. I wouldn't know.

CAT:  We can absolutely see right through some of those things. And so, part of the product responsibility is just building and spending social capital at all times. It's a very specialized skillset that you have to be able to have to do that. And so, when I start smelling that BS, somebody just doesn't want to do it as opposed to, please don't ever try and make an enhancement to that feature again, it helps for me to be able to sort of tease that out a little bit. Maybe bring somebody else into the conversation who I know can help translate back and forth. And call in the negotiators when necessary. [Laughs]

NOEL:  Yeah, especially really early in my career, I had a strong tendency to say "This can't be done" when what I meant was "This can't be done easily."

CAT:  Yeah, that's bogus. It's our technology. We can do whatever we want with it. [Laughs]

NOEL:  Yeah. And now I'm more likely to say, "We can do whatever we want. It's just a question of time and money."

CAT:  Exactly. 

NOEL:  What do developers do that helps build trust? Like you say, you can smell BS. What kinds of things can developers do to help you believe them when they say something is hard?

CAT:  Well for one, there's the resolution part of conflict resolution. That is just so important. It is fine and it is healthy for us in fact to disagree on the regular, as long as we can accomplish that resolution part of it where we both start to see each other's perspective and then come to a conclusion that we're both bought into. That's what builds the most trust for me, is being able to disagree and get on with your work and do an even better job as a result of the disagreement.

MATT:  For me, it was pausing development and taking the time to explain a particularly technical concept. Or even when it's not technical but in the product development, the coding of it or the architecture of it was going to become complicated because of just the nature of that feature, just taking the time to sit down with the product owners and explain that so that they could then take that knowledge back to their teams or their stakeholders to explain that, I always found that to be really, really, really beneficial.

NOEL:  Do you find that developers have trouble explaining technical architectural decisions to the product owners? Or do you find that in general, we do a better job of that than we think?

MATT:  The ones I've worked with have been very good at it. So, maybe I've just gotten lucky. 

CAT:  Yeah. My favorite engineers are always the ones who can speak my language and I hopefully can speak some version of their language as well. There's a big conversation about whether or not product people should or should not be technical. On the one hand, we should really care about the product and defining the goal so crystal clearly and explaining the goal so crystal clearly that we're all working to solve that goal. Ideally I shouldn't care how it's done, right? Aside from perhaps some UI elements or usability or experience like that, I shouldn't really care about the technical guts of it. I will say that having a good technical understanding of your own website and how the puzzle pieces fit together does help you avoid a lot of thrashing in either the planning or the development process that's easily avoided.

NOEL:  It seems to me like you should know the internals to the extent that they're going to influence future decisions, to the extent that one decision may make future decisions more or less expensive or more or less complicated. That's a useful piece of information to get across.

CAT:  Yeah, exactly. And so, there's always going to be, you're always trying to get the maximum value for the minimum effort in pretty much everything that you're prioritizing or doing. So, being able to explain why… I started to elicit patterns too over time where, okay, any time we touch system X, it automatically amplifies the estimate. Or every time we have to pull from a design property that doesn't already exist on the site or things like that. So, just being really deliberate about your thought process and speaking your thoughts and thinking out loud and all of that, I'm picking up on much more than you might think, in terms of patterns.

NOEL:  Does team size make a difference? Does it matter? The relationship you have with a smaller team versus a larger team and the communication?

MATT:  I've always wished for a larger team so we could get more done. But that would inevitably add complications, I'm sure. The most developers I've had on my projects have been 2 and a half, roughly. So, I think that's relatively small. And we got a lot done when we had that amount, but we were able to get into a great rhythm. We got to a point where our velocity was pretty stable. We knew about how much we were going to get done every iteration. And that was awesome. So, I can't speak to a larger development team. Again, I would love a bigger one just to accomplish more in the same amount of time, but that comes at a clear cost, both dollars and cents, but also probably, potentially some efficiencies, depending on the makeup of your team. 

CAT:  I would say actually that your company culture probably has more to do with your ability to product manage for few or many developers. There's a lot to be said for a company culture that encourages backing one another up and teamwork and collaboration. And if I show up to a meeting and I'm totally unprepared, I know one of my colleagues is going to step in and try and carry the torch for me. So, I would argue… I had a very unique experience in the very early days of Grubhub where I was the first product owner. And as we were growing and hiring like crazy, I ended up with probably eight engineers before we started hiring more people into product. And so, the culture there was just, it was early days. It was so high-growth, so fast-paced that everybody was doing everything. So, we were all the Jacks and Janes of the startup world doing all things at all times. So, that was a totally sustainable or temporarily sustainable pace for all of us, I would say. Nowadays it's, with bigger companies, that changes.

NOEL:  What are some of the specific things that you try to get in a company culture that leads to communication? What are some specific behaviors you try to model or something like that?

CAT:  For me it all begins with trust. There has to be this base layer of trust where I know that if I fail, I'm safe and we're all going to learn from it together and move on and that my colleagues want me to be more successful and I want them to be more successful. And so, with that base layer trust in place, that's what enables the communication and that's what enables the collaboration that actually helps people work better together. 

MATT:  The ability to fail without drastic repercussions, this is all relative to what the issue is I guess, but the ability to mess up and learn from that as opposed to come down on people and whatever, that's huge. I really like that trust point. I'd add to it probably, and this might sound a little cliché but general communication skills. Just being able to clearly convey how you're feeling about something or how that's going to impact X, Y, and Z is also really important. So, we look for people who can just have a good conversation about whatever topic they're in charge of.

CAT:  If you're looking for specific actions that an individual can take to build the trust, collaboration, communication, all of those things, number one is always food.

[Laughter]

CAT:  Second of all I think always and forever offering the full context of what you're talking about just inherently removes anybody's maybe sarcasm or cynicism that might be present as to why they have to do this thing. If they can understand the full circumstances around it, then it becomes more logical. "Oh, I get it. So, there's this whole other department that's suffering this one problem that I don't really understand. Now I get the value of why you're asking me to do this."

NOEL:  I feel like trust is a big deal in the sense that almost any successful process is based on trust. The details of your agile process or whatever are less important than the idea that all the stakeholders trust each other. That almost any process can work if you have that trust and if you don't have that trust, then a lot of your process time is going to be spent fighting the fact that you don't have that trust. And you waste a lot of effort and a lot of time making up for that lack of trust.

CAT:  Absolutely.

NOEL:  One common point of contention between a product team and a developer team has to do with estimation. How do you like developers to present estimates to you and what sort of issues do you see in the way that developers present estimates of future work?

MATT:  I think one of the things I like best was just more context. Just saying "It's going to take long" or that no, my expectations as the product owner are not actually correct in how long I think something is going to take is really helpful to A, just set my expectations right then and there, but also B, help me moving forward to just get a fuller picture of maybe that ugly part of the codebase that Cat mentioned. Just so that when I want to touch that area later on, I understand that "Oh, this is probably going to be a five-pointer, not a two-pointer."

CAT:  I couldn't agree more with needing all of the context we can get. And being able to elicit those patterns on why something is more or less difficult than I might have thought it was. It also helps obviously to track over time. So, especially if I'm new to a company and just getting to know the product and just getting to know the systems, then it's really helpful for me to be able to either look back in the tools or in the backlog and see how things have gone historically. We just went through an exercise recently to sort of recalibrate our estimations both from a QA standpoint and from a developer standpoint, just to understand. We test across all devices. We test across all browsers. We also do full accessibility testing. So, any of these patterns that I start seeing, "Oh, this one's going to be tricky for accessibility," or "This one's going to be tricky because we have to support a mobile layout," or whatever the case is, helps me identify those patterns in advance.

NOEL:  Yeah. I think that's a case for getting as many people involved in an estimate, getting as many of the stakeholders involved in making an estimate, as possible. To what extend do you go back and track, or how do you track estimate performance?

CAT:  Personally, I really don't love burn-down charts. But I'm open to them because I know I've never seen them used really effectively. [Chuckles] There is a certain gut level, especially if you're working with a small team and you're able to do that over time, where you just understand people's velocity. And you get a good gut sense for how much work exactly could fit into a sprint. And then I take my best guess and then we discuss it with the team.

NOEL:  We have an entire podcast about how bad velocity is as a measurement, earlier.

CAT:  [Laughs] 

NOEL:  We'll put that in the show notes. 

MATT:  I totally think it's a gut thing. There are ways to quantify it, but after a while if you've been working with the same developers for a while and the same project managers and same product owners, you really do get a sense for what is the cadence of the team and how much is actually achievable, with the information you had at your planning meeting or whatnot. So, I 100% back the gut feel, even though that is the least scientific option here.

NOEL:  Right. It becomes very hard to sell to somebody outside your team, I think, especially when things get a little tight, I suppose. 

CAT:  Outside the team, they really shouldn't be caring whether it's a two-point story or a five-point story, right? And that's kind of the whole point, is yes it's not scientific, but in relative estimation, you're estimating in jelly beans. They shouldn't really mean anything specific.

NOEL:  To me, as my own idiosyncratic way that I estimate, the estimate is a measure of the complexity of the problem, not really the, we assume it's going to be proportional to the amount of time it takes. But ultimately, the estimate is from my perspective, a discussion of complexity, because that's the part that I feel like I can understand. From my perspective as the developer, it is my job to tell you how complicated this problem is and that it is your job as the product person to tell me how valuable that is and to prioritize it once I tell you how complicated it's going to be and roughly how much it's going to cost.

MATT:  The costing was tough for our organization because our stakeholders, like my manager and other managers above me, wanted to know, "How much is this going to cost to develop this feature?" How many thousands of literal dollars? And I'm like, "That will cost you two weeks," or "That will cost you four weeks." And it was really hard to translate that to dollars and cents because other things crop up in those iterations. You push something out. You reprioritize if necessary. You don't like doing that but sometimes that's the nature of the game. That does get really hard to convey to outside stakeholders, even though they shouldn't necessarily care, as long as you've decided that this is the path for the product. Depending on the nature of your organization, that's not always how it'll play out.

CAT:  Yeah, it's true. So, at Peapod we are, you may or may not know this, the world's first e-commerce company. I mean we were invented before the internet, and 30 years ago. [Chuckles] So, we have a fair share of technical debt in certain areas that haven't been modernized yet and that are still on the roadmap. 

NOEL:  That sounds terrifying.

CAT:  [Laughs] Yeah. So for me, especially when I was brand new here, I would go into sprint planning meetings with all these big dreams and basically just have no concept of the estimates going in. And I thought that based on prior companies and past experience that I could sort of t-shirt size this myself. But I was so far off that I would leave the sprint meetings and just have no idea what was going to be developed any time soon. [Chuckles] So, that made it extra hard for me to go to the business and say "Okay, cool. You're going to get this feature," or "Yes, we can deliver that in such and such a period of time." It made it really difficult. So, after the conversations that we just discussed around how to communicate and collaborate and all of those kinds of things, that process gets easier. But just looking at it with fresh eyes, it's going to be really tough. And there needs to be a really solid on-boarding process for new folks in product in particular, I'd say. 

NOEL:  How do you like to deal with the paradox of an estimate that the people that you report to want to have the estimate… As Matt said, they want to know dollars upfront, when from the developer side we know or we believe that the worst time, the time you know the least about how much something is going to cost at the beginning. How do you manage that tension?

CAT:  I try and understand the full context of why somebody is asking me that. Are they asking me because they literally have to write me a check? Are they asking me because they have to, they're planning the budgeting for capitalized software? So, there's different levels of fidelity that they might be asking for and so, I try and meet their needs with the best response that I can. And if the answer is yes, they need a finite dollar amount, I can give them a confidence interval of "That's plus or minus 50%. We don't know yet. But I can update you in three weeks."

MATT:  Yeah. Having the, as you said Cat, the fidelity is really important. For us most of the time, it was just budgeting purposes. And so, I needed a relatively broad number and adding a, I'll use your words again, confidence interval, was a good way to do that. Or a buffer might be another good way. Again, having the context from the developers of what could make this more difficult to get a sense of "How much do I need to buffer?" was really important. So, circling all the way back to that, I think is important as well, as you try to build what is that amount.

NOEL:  One thing that makes me happy as a developer is when someone comes to a feature request and I can say "This will cost X, but I can give you 90% of it for 10% of the cost, if that's okay." That makes me very happy to be able to do, and a lot of times that works out. It helps for me as the developer, the better I understand the real business goals, the more I have the ability to make that kind of judgment or present that kind of decision for you.

CAT:  Yes, and that is where your expertise is so incredibly valuable, because we're all on the same page there. We all want the 80/20 effect as often as we can get it. But I might have a limited capacity to think of those plans and ideas just based on, I don't know how to read the codebase. 

MATT:  The last product I owned, it was my baby. I started with it literally from day one and saw it to five years later, multimillion dollar product. And so, my vision, it was literally always my vision until we brought in another product manager. And so, sometimes I was just focused. I had tunnel vision on "Here's my vision." So, having a developer be like "Well, have you considered this way to do it?" was really important. That feedback is so crucial. And oftentimes… there are so many ways to achieve the same end goal and if one's going to cost you X but one costs you 10X, I'd rather go with the X if it's going to be pretty close to the same end product. 

NOEL:  Yeah, I have a relationship with a product manager that I work with, not Matt, who will very commonly request a number of... the initial request of all the complexity. And they're very open to the idea of "Hey, this 80% is pretty easy. This piece is going to be complicated. How important is it?" But it becomes incumbent upon me to make that cost decision in a way that sometimes… sometimes it's incumbent on the product manager to curate that in advance and sometimes it's better for the developer to curate that. My normal feeling honestly is "Tell me all the stuff you want and I'll tell you which part of it is expensive," rather than having you as a product owner pre-decide which things are complicated and which aren't so that I don't get the opportunity to give you that piece of information. Do you like doing that curation of features on your own or do you prefer to get the developer input first? Or does it matter or does it depend on the situation?

MATT:  Since we always worked with consultants, I like doing it the first pass myself because it saves costs. But really, I think it depends on what resources your organization has, how technical is that product owner, who are your customers? I alluded to a minute ago that I like that flexibility. But in the later stages of the product I owned, we worked with compliance companies, so pharmaceutical companies, and they need all the details really nailed down before you can release something. So, in the end I should have been giving more thought to that earlier on. So, it really depends on a whole multitude of things. But I really think it's what resources you have and what skills do they bring to the table to decide? Who leads and when does that happen? 

CAT:  So, part of it is the context of the company as we mentioned earlier. So, in a startup I learned to mercilessly cut scope. We had arguments about whether or not we needed a link to the home page because people knew or didn't know that they could just click the logo in the top left of the screen. That becomes a very serious discipline. And I keep that with me even though I'm no longer at a startup. I keep that with me just because it's critical to remember what actually grants functionality to the feature or the site. And so, if it's shippable in that context, you may or may not make the decision to ship it and to introduce it to your customers at that point. But that's how I like to present the features. Yes, in an ideal state I would love to present a full set of features and understand that "Okay, for an extra 13 points total, we can get these super valuable pieces, features, into the product, and then we're going to be comfortable shipping it much sooner." So, if that's the input that I'm getting from that conversation, that's beautiful.

MATT:  At what point does that become user experience debt to a certain point, though? There's the ship early, ship often mentality I guess. And there's a fine line there between pushing a feature out that does do what it's supposed to do and then having it fully fleshed out. Again, 13 extra points, that's a lot of development work there. Well, I guess that's relative to your schedule. But yeah, it can be. But I don't know. That was always a hard balance for "Yes, I think this is great," but again, I'm the product owner. I want to release as early as possible. But for some of our customers, if it wasn't… we had the full spectrum. We had the most basic computer illiterate person to a CTO using our product. And there's a nice medium somewhere in the middle there. But that… where does it become not technical debt but UX debt of sorts?

CAT:  Yeah, there does become a chicken and egg situation at some point. "Did the product not succeed because you didn't invest enough or should you stop investing because nobody's using it anyway?" kind of thing. I've definitely experienced that. But in general, my feeling is that you should strip down to the absolute bare necessities for the sake of time to market and learning. And then basically use your iterations as, line those up with your marketing plan for the product. How much weight are you going to throw behind it? How many people are you going to introduce it to? Because you can even get those extra 13 points in, or whatever the case is.

NOEL:  But it's helpful for the developer team to know what those 13 points are on the roadmap because sometimes that may affect code architecture decisions. Although in general, I don't like to make code architecture decisions based on things we might do in the future. That can sometimes lead to over-design. My experience I think is that shipping is a muscle. It's learned behavior. And aversion to shipping is also learned behavior. And I've certainly seen products get in the situation where we're always one more thing away from releasing, forever. And if you get in a situation where you culturally feel like doing a release is a low-cost thing, that we're going to do another one very shortly thereafter, we can roll it back quickly if it becomes a problem, that makes it a lot easier to deal with some of those technical and UX debt issues if it's not a major event to deploy stuff to production. And I think yeah, I think the industry's gotten, especially the web industry, has gotten much, much better at this over the last five to ten years.

CAT:  Yeah. And feature toggles have done wonders for that, right? So, I can even as a business person who's not a developer I could potentially flip a feature on for a subset of customers.

NOEL:  Yes, feature toggles are good. It helps to have built them into the product from the beginning. It can sometimes be tricky to retrofit that into an application that… or I should say, it can sometimes be tricky to retrofit that into an entire process that hasn't been set up around feature flags. But yeah, anything like that where you can make moving code to production a non-event, that reduces a tremendous amount of friction in a team. It's surprising to me how nice an effect being able to rapidly deploy is all the way through the product process. It just makes all kinds of decisions seem less consequential than they otherwise might.

What is something you don't like about the way developers work that developers should know when they deal with product owners?

CAT:  Our job is to make ourselves constantly available to you. So, every sprint retrospective I think I've ever been in for the last 10, 15 years of my career, every retrospect has asked for more details in the stories. And I could detail 'til I'm blue in the face. And when I do, you never read them. So [Laughs] it's my job to be persistently available to you. Just walk over to my desk please, if space allows. [Laughs] And ask a question.

MATT:  Yeah, absolutely. That would be top of my list, too. Just the "Ask before developing" would save a lot of time, frustration, money, so many things, so early on. And I always found it interesting how a feature definition was interpreted, or executed might be the right way to say that. So, yeah.

NOEL:  Yeah, as a developer you don't often, depending on how the story is written when it's handed to you, you don't often even realize that some of the things are ambiguous or open to interpretation in the story as you get it. You don't even realize the things that you should be asking. And I think setting up a culture of consistent feedback where the product owner is free to check in on the current progress and the developer has constant opportunities to ask the product owner what's going on, is great. I know Matt, you often were colocated with, even though the team was consultants, I know you often made an effort to be colocated with them. And I think that is super helpful. 

MATT:  That was helpful. And the other thing that was really helpful and this is before Slack offered a guest account, but the developers added me to their Slack channel for our project. And just the quick being able to do @MattM and ping me with a quick message was so helpful just to ease that communication barrier. Because it didn't require you switching applications, going to an email, write that, and wait for a response. It was pretty immediate. So, that was another really big advancement as well, I'd say.

CAT:  That's a great callout, the open, public chat channels in Slack and other, Flowdock and HipChat and all of those other chat programs. Those allow for a really great amount of accidental learning. And so, if I go in there and I see a bunch of chatter about a particular story that somebody's working on, they're asking for help from other developers, things like that, that's a lot of great context for me to understand.

NOEL:  Okay. What should I have asked you that I haven't asked you yet?

CAT:  One thing I will tack on actually, to the last question of what I wish developers would, not something you don't know but maybe something that developers would recognize a little more often, is that part of the role of product owner is a tremendous amount of emotional labor. Your job is to herd cats, to get the right people in the right room at the right time, to understand as I mentioned at the very beginning of the conversation, to understand each individual's motivations and how they, what really rings their bell, and try and play into those so that they feel energized and competitive and excited about the work that they're doing. That takes a tremendous amount of energy. 

And it's not simply because we are some type of human that thrives on doing all this additional labor. [Laughs] So, if you take over ordering the lunch for the retrospective every now and then, if you recognize "Hey, I really appreciate you gathering, chasing down those 16 people that had to participate in this conversation. Hey, I really love how you never call me into meetings. I appreciate that." [Chuckles] Those are the kinds of unsung heroes that [Laughs] really burn out quite easily. So, I would tack that in there.

MATT:  Yeah. We've talked the developers and the product owners a lot. I think at least in the case of my product or with my developers, one of the unsung heroes who, this kind of relates to what Cat is saying, is it was our project manager. She was fantastic and a lot of that was herding cats, you know. "Are you signing on to the Goto meeting? Are you calling into this? Are you going to be at this meeting? Can you update this ticket?" Just so many things that they had to pay attention to but that kept so much moving so smoothly that it was just, it often goes unappreciated and sometimes unnoticed. But a lot of that is, that's another component to the team that just can really make it a successful operation.

NOEL:  Cool. Where can people reach you online if they want to ask you some more questions about this?

CAT:  You can reach me on LinkedIn. Otherwise, I live under a rock.

[Laughter]

MATT:  Yeah, LinkedIn is probably the best for me as well. I don't do… I'm not a tweeter. And Instagram, I like photography a lot. So, Instagram you'll see me there, too @McNama4. 

NOEL:  Thank you both for your time and giving us the product owner perspective. I really appreciate having you on.

CAT:  Thank you.

MATT:  Thank you.

NOEL:  Tech Done Right is a production of Table XI and is hosted by me, Noel Rappin. I'm @NoelRap on Twitter and Table XI is @TableXI. The podcast is edited by Mandy Moore. You can reach her on Twitter at @TheRubyRep. Tech Done Right can be found at TechDoneRight.io or downloaded wherever you get your podcasts. You can send us feedback or ideas on Twitter at @tech_done_right. 

Table XI is a UX design and software development company in Chicago with a 15-year history of building websites, mobile applications and custom digital experiences for everyone from startups to storied brands. Find us at TableXI.com where you can learn more about working with us or working for us. We'll be back in a couple of weeks with the next episode of Tech Done Right.