Conversations in Software Development
Conversations in Software Development
Episode 004: “Working in a Product Development Team” with Jenny Farver
More often than not, software development projects are actually product development projects. The goal is to develop a product that will actually be used, and where our users will have specific needs. The team that develops that product will involve more than just software developers and, to help us explore what product development entails, and the various roles that are involved in a product development team, we spoke with Jenny Farver, a Chicago-based technology leader with many years of experience in product development.
Welcome to conversations in software development podcast intended primarily for students who want to learn more about software development. I am your host for her Sotomayor. I am a senior lecturer in computer science at the university of Chicago, where among many other things, I teach a class on software development. This is our fourth episode overall, but it is the first episode since we launched a website for the podcast. So I just want to remind everyone who's listening, that you can go to podcasts, not software.fm, to see a list of all of our episodes, as well as more detailed information about each episode. So in this episode, we are going to be talking about product development more often than not software development projects are actually product development projects. The goal is to develop a product and that product is going to have users with specific needs, but developing a product involves a lot more than just writing software. It does involve software developers, but it also involves working with a variety of other people in different roles, including designers, product managers, project managers, marketing, and sales teams, and many others. In other words, it involves a product development team to help us explore this topic. I'm joined today by Jenny Farber, a Chicago based technology leader with many years of experience in product development. Jenny, thank you so much for joining us today. So before we get started, could you tell us a little bit about yourself?
Speaker 2:Yeah, sure. Uh, I'm actually in between my full time jobs right now. Uh, that's allowing me to spend a little bit more time on my hobbies and I'm also spending some more time advising a few companies here in Chicago that, uh, I'm interested in. Uh, I guess at this point in my career, most of my work is about running technology businesses, um, including managing teams. Uh, for me that shift from writing code, uh, happened when I was at a startup that I joined called citizen analytics. Uh, that was actually my first job after having taken a few years off to spend time with my kids. Uh, and they're at Silva, so we were growing quickly. And so I got promoted quickly and there I was. And, uh, I was there for a few years and um, in the last, uh, last two years, I guess that I was there, I was, um, managing product development teams, including engineers, but also designers and product managers. Um, and since then I've been at a few other technology startups here in Chicago.
Speaker 1:So let's, uh, let's maybe start with the basics. You know, I said earlier that more often than not, when we say software development, we actually mean product development, but uh we're where do you draw that line? When, when does software development become product development?
Speaker 2:Uh, I think it often is because usually in software projects you have users and you care about your users and you care about their usage. And so even if you're working on a software project that is going to be used internally inside of the company that you work at, or even if you're working on a software project where the person using your software is just engineer, maybe you're working on an API and that API is going to be consumed by other software engineers. If you care about that user and you care about how successful they are at using the thing you built, um, then you're probably going to want to approach it as product development. Uh, so in fact, it's kind of hard for me to come up with examples of software projects that don't have those attributes. Uh, I perhaps could come up with some, uh, and of course on internal projects, um, there's some concerns that go away. You might not have to, um, figure out how somebody is going to pay for your software. Um, maybe you don't have to market to them because they're just kind of forced to use the tool that you build for that because they work at that company. But even, so you tend to care whether they're successful, you tend to care whether, um, the project is successful. Uh, and so many software projects are in fact product development projects.
Speaker 1:And this is going to involve more than just, uh, we we've, we've sort of hinted at this, but this is going to involve more than just software developers or engineers to be able to develop that product. Right?
Speaker 2:Yeah, that's right. I mean, code is just part of that, but, um, it turns out that it's really easy in software development to build the wrong thing. And, uh, people are very good at finding ways not to use it, even if, you know, you build a, an internal tool at a company and everybody is forced to use it. I guarantee you that people find ways not to use it. People are very good at working around software that they don't like. Uh, so, um, so yeah, building the right thing in the first place is very critical and it's also just, it's just not very much fun to build software that doesn't get used. Uh, and unfortunately, uh, it's an incredibly common experience in our careers as software developers, that things we build don't get used. Uh, maybe not as much as we'd like, maybe not at all. They never see the light of day. And so, you know, for all those reasons, um, uh, we should spend a lot of time paying attention to whether we're building the right thing in the first place. And it turns out the building, the right thing in the first place. Um, and you know, they're the right thing means it's good for users. It helps them accomplish their goals. Um, uh, building the right thing in the first place, uh, is often just as important as how well it was built. And as engineers, we tend to focus our schooling and our education and our professional development, a lot on issues of build quality, how fast, how scalable, how maintainable, um, but whether it was the right thing in the first place as often, uh, you know, sometimes the most important concern.
Speaker 1:So, I mean, it sounds like this is one of the things that, uh, like students of computer science or just, you know, engineering or software engineering in general might find a little bit, uh, sort of shocking that, that, uh, you know, when you're learning, uh, how to code, like, yes, like you just said, like, there's this sort of like focus on, well, you have to build something that uses the right algorithms and the right data structures and so on and so forth, but you're never really sort of exposed to, you know, uh, figuring out whether what you're building like actually makes sense or whether it's actually, uh, a sort of a, uh, a viable product. Uh, so how, how, you know, can you maybe tell it's a little bit about what, what is actually involved in like figuring out whether a product is, is worth building or not, or I guess another way of thinking about this is how do you avoid being in a situation where you build something that then like no one wants to use?
Speaker 2:Well, I wish I could promise that it could, could be avoided. Uh, unfortunately almost every engineer I know, I think has had this experience, um, what goes into avoiding that is it's a lot of things on the business side of a technology company. So how big is the market for this? How many users would there be? Are they willing to pay for it? What do you need to charge in order to, um, to make it viable? Um, if you're not going to charge money, how are you going to make money? Um, who are the competitors and what is their offering and can you really beat that and how, um, and so yeah, building the right thing takes in a lot of those concerns. And then there's also kind of just the list is kind of nearly infinite, including things like, does it feel good to use this product? Is it a fun experience? Does it like emotionally engagement engage us? Um, so yeah, it feels like the, the, like a go on and on list is pretty endless. And, you know, I think the reason that, um, as engineers, we're not so focused on this in our, in our educations, it's just that the technical execution that, you know, is it scalable? Is it maintainable? Is it fast? Those, our teams are looking at us to have those answers because if we don't have those answers, nobody has those answers. So it is our professional responsibility to think about those things. Um, it's kind of uniquely our responsibility usually. Um, and so that's, that's why we place that happy emphasis, but, but then of course, all those other factors come into play.
Speaker 1:So, you know, this being able to develop a product, uh, as I mentioned earlier, you know, involves a lot more than just software engineers, uh, involves their product development team. Uh, that includes a number of roles that, uh, you know, someone can study to be a designer, can study to be a product manager or a project manager, et cetera. But if you think about someone who's learning how to code and how to develop software, it's very rare for as part of your, sort of like your formative years. And especially if you're in college, et cetera, to be in a position where you actually have to work with a designer or have to work with, you know, a product manager or a project manager, uh, et cetera. Um, so can you tell us a little bit about, you know, these various roles that are involved in, in product development and that, that someone might end up having to, uh, uh, to work with?
Speaker 2:Yeah, sure. Um, and aren't, there can be quite a lot of different roles and, um, you might not have all of them involved in the team. It would depend on what you're building. Um, the three most common that I think people often think of is just the core triangle of software, product development, uh, is engineering product, um, product management and user experience design. Um, and so those three are the most common participants. Um, so, you know, design, product management and engineering, uh, we kind of assume that we know that what engineers do, let's assume that we know what engineers do. Um, and maybe talk a little bit about those other two jobs. Um, designers are there to ensure that a user has a successful experience with the project, uh, with the product, excuse me, often we think about design as it's visual embodiment. So we think of designers is making a beautiful product. Um, nice. Uh, I often, you know, it feels great to use a beautiful product, um, but, uh, there's much more to it than the visual element of that. Um, it's really the usability. And so, you know, is it easy for the user, um, to complete a task and that task might be something very small, like filling out a form, or it could be a more abstract task, a creative task, like making a slide deck. Um, and so typically the product has an opinion on what success looks like. And that's one of the things you need to define upfront success might be clicking the button that makes you money at the end. Success might be that you spend more time in this product and somehow the, um, the organization makes more money or somehow more satisfied by having spent more time. Um, so, you know, you need to kind of decide to find what success looks like, and then you designers help take apart. What are all the things that make that success difficult? And how can I smooth all those barriers to ensure success so that you know, that you need an understanding of what success looks like. You need an understanding of what makes that difficult. Um, and I think taking an example kind of is a helpful way to, to put this all together in lots of kinds of software. We have the D what's essentially the blank page problem. So imagine yourself about to go do an assignment, like a homework assignment or something that is difficult. Um, and the first thing you do when you open your piece of software is you're looking at a blank page and that might be a Google doc blank page or a black like spreadsheet. Um, it could be something else, but that feeling of looking at a blank page to most of us, even though we think of ourselves as creative is kind of scary and daunting, it's like that first piece struck, like, what am I going to do? And people want different processes. They start with an outline, et cetera. So designers can help us there. So a good designer will help us think, you know, given what the task is, how can I help that user feel less jarred by the blank page and more excited to get on with the task you start to use. If you pay attention to software, you'll see that lots of different pieces of software have different strategies for having you overcome this fear. So, you know, if it's like a, um, you know, they may cue you like, Oh, maybe you want to do this thing, or maybe you want to put in a picture, or how about this? You know, they kind of suggestions on how to get started. They might give you, um, placeholder text or, or other kinds of things to like, get you to keep, keep going. Um, so, you know, that's just one example of a common problem that prevents the user from accomplishing their goal and good design can, um, can overcome that. And that has, it does have visual elements, but it also just has what we call usability elements to overcome those problems. Um, so that's the, that's the job of a user experience designer. And then the third part of that triangle is the product manager, um, product managers. Uh, I think a lot of us find it really hard to define this with pinpoint accuracy. Um, I've heard it said that they are kind of the CEO of the product, um, in some ways I agree, although, um, I never want that to give, um, other participants permission to check out of decisions. Um, but I think that the reason it rings true in some cases is that our product manager is usually bringing together lots of information across different expertise and bringing together information to make important choices. So if you think about, um, if you think about products that we use where there's different pricing tiers, like there's the free tier and the cheap tier and the really expensive tier, um, the product manager is typically making the decision about what features go in, what tier and so, like what information do you need to make that decision? Well, you need to understand, um, your user's willingness to pay, like how much money is in their pocket book that they're willing to devote to this problem. And you need to understand, you know, what's the, what's the value to them of the really expensive feature. Like how much would they be willing to pay, to have unlimited storage, for example. Um, but you also have to have an understanding of, you know, what's, you know, you're thinking about future features, what is the technical feasibility of that? Um, what are our competitors doing? Um, how much does it cost us to provide that feature? So there's just like a lot of information that goes into that final thing, which is it's$29 a month, or it's$80 a month. Um, and so product managers are often working across different, um, domains to bring that all together and make those final decisions. And, um, as you can imagine, it's, it's like being a generalist is helpful and being a strong communicator is helpful.
Speaker 1:Is there, is there a difference between a product manager and a project manager? Uh, you know, sometimes I've, I've heard those terms, like used it a little bit interchangeably, you know, uh, is there a clear dividing line between the two?
Speaker 2:Yeah. Um, so my opinion is that there should be. So I do think that because product managers are typically strong communicators and organized people, it's very tempting for them to become project managers. And the project manager is a person that keeps track of lots of little things in order to like keep a group of people on task and on time doing a complicated thing. Right. Um, so it's very tempting for somebody who is a good communicator organized to take on that work. And sometimes they do. Um, and, you know, in teams where I've been involved, I've tried to resist that temptation because, um, some of those business activities and those, those activities about users, about market and about like price or marketing, uh, if the product manager doesn't do them, they will not happen. And so I tend to think that every time a product manager does every time a product manager does a project management task, I moved the card across the JIRA board, or I, you know, you know, ask somebody, you know, some little status report question. It's taking time away from those questions about users and money and, um, usage and market and all those business questions. And so, you know, what is the real cost of doing that? And is there a better way to manage, to do the status report stuff, to do the project management stuff? So that's my bias. I think they should be different, or I don't think that the job of a product manager should be project management. Um, and then that's my reason why,
Speaker 1:Ah, okay. So in, in previous episodes of this podcast, we've, we've explored how software development is a team sport. Uh, but we've looked at this mostly from the perspective of collaborating of software developers, collaborating with other software developers and, uh, you know, clearly product management is also a team sport. Uh, but, uh, as we've sort of already mentioned a couple of times, uh, already, it's not the kind of collaboration that you're easily exposed to as, as a student in, in which you might not even get exposure to in an internship where, you know, you may be solely focused on software development. Do you think there's anything different between collaborating with other software developers versus the, the kind of collaboration you experienced as part of a product development team with, you know, the product management, the engineering, the design, et cetera.
Speaker 2:Um, you know, maybe there is some like little milk that's in bolts, things about, you know, how to chatter and get hub or something. But I think the best starting point is that collaborating with non-engineers on your team, non-developers on the team isn't different. And that's kind of a point, um, I think, uh, early career engineers having been exposed to some of these other roles, um, the most common mistakes is that they think it's all about engineers. Um, they think that, you know, software companies are all about engineers. They might think that they're the smartest people on the team. Uh, and so that's actually the biggest mistake to avoid. Uh, so if, instead you understand a little bit about what the different roles are and why they're so important and how much expertise goes into those roles. Um, then it's easier to just start saying, okay, well, if I understand that, you know, I am not God's gift to software development. I am not the only person. I'm not the smartest person on the people. Then what do you do? Um, then with that kind of humility, uh, then you're in a good position to start seeing like, okay, what do I do now? You know, the answer is essentially to draw the best out of all the people around you to like satisfy your own curiosity about what they know that you don't know. And, you know, you, so somebody with that mindset is likely to just, um, they're likely to ask questions, um, to learn about what they don't know, uh, you know, and when you do that, you tend to find yourself in these like really exciting rabbit holes of all the things that go into software development.
Speaker 1:So it sounds like one takeaway, you know, here, uh, is that, uh, you know, if you're someone who is interested in pursuing a career in software development, that, uh, a, you know, it's not just going to be, you know, you working with software developers all the time and the software developers are not the sort of center of the, uh, of the universe, which I think, again, I think some, some students might find surprising, uh, but also that having the ability to work with all of these other people in these other roles can be a very, uh, sort of fulfilling experience.
Speaker 2:Absolutely. I mean, I think the danger is that when you, when you start to see the things that go into a successful software product, it's easier to go down these rabbit holes and be like, wow, like, look at all these interviews we've done with users. And I can just like read the transcripts of these interviews or like a, you know, huh. I didn't know. The designers have like a go to way of solving this problem. Or I'm like, you know, you might realize that the product manager actually has, has a number. Like if somebody signs up for our product today, that product manager knows that on average, that person will use our product for seven months or 15 months. And your product manager might also know that whether they, uh, like whether they use the new cool feature is more likely to retain them. They're more likely to stay for another six months if they use that new cool feature. And so like, once you start to realize that people have thought about these things, often they are these kinds of like artifacts of other people's work are out there. And they're readable. It's very easy to be. If you're a curious person to be down a rabbit hole of finding them all, and then you kind of have to like pull yourself back and say, okay, like, how am I going to manage my own time? I'm here to write the software, knowing enough about these things helps me do my job. It satisfies my curiosity. Um, it helps me get, be excited, be excited and stay excited at work. And all of those are, those are all good things. And then also people just need me to write the software. So how am I going to manage my time and manage my career to like balance those factors?
Speaker 3:Okay. So I think with that, we can wrap things up. Uh, Jenny, thank you so much for joining us today.