0:09

Welcome to conversations in software development

0:12

podcast intended primarily for students who

0:14

want to learn more about software development. I

0:16

am your host for her Sotomayor . I am a senior lecturer

0:18

in computer science at the university of Chicago, where

0:21

among many other things, I teach a class on software

0:23

development. This is our fourth episode

0:25

overall, but it is the first episode since

0:27

we launched a website for the podcast. So I just want to

0:29

remind everyone who's listening, that you can go to

0:32

podcasts , not software.fm, to

0:34

see a list of all of our episodes, as well as more detailed

0:36

information about each episode. So

0:39

in this episode, we are going to be talking about product

0:41

development more often than not software

0:43

development projects are actually product

0:45

development projects. The goal is to develop a product

0:48

and that product is going to have users with

0:50

specific needs, but developing a product

0:52

involves a lot more than just writing software.

0:54

It does involve software developers, but it

0:56

also involves working with a variety of other people

0:58

in different roles, including designers, product

1:00

managers, project managers, marketing, and sales

1:03

teams, and many others. In other words,

1:05

it involves a product development team

1:07

to help us explore this topic. I'm joined today by Jenny

1:10

Farber, a Chicago based technology leader

1:12

with many years of experience in product development.

1:14

Jenny, thank you so much for joining us today. So

1:18

before we get started, could you tell us

1:20

a little bit about yourself?

1:21

Yeah, sure. Uh, I'm actually

1:23

in between my full time jobs right now. Uh,

1:26

that's allowing me to spend a little bit more time

1:28

on my hobbies and I'm also spending some

1:30

more time advising a few companies here in Chicago

1:33

that , uh , I'm interested in. Uh,

1:36

I guess at this point in my career, most of my

1:38

work is about running technology businesses

1:40

, um , including managing teams.

1:43

Uh, for me that shift from writing

1:46

code , uh, happened

1:48

when I was at a startup that I joined called

1:50

citizen analytics. Uh, that was actually my

1:52

first job after having taken

1:54

a few years off to spend time with my kids. Uh,

1:57

and they're at Silva , so we were growing

1:59

quickly. And so I got promoted quickly

2:01

and there I was. And

2:03

, uh , I was there for a few years and

2:06

um, in the last , uh, last

2:08

two years, I guess that I was there, I was , um,

2:10

managing product development teams, including engineers,

2:13

but also designers and

2:15

product managers. Um , and since

2:17

then I've been at a few other technology startups here

2:19

in Chicago.

2:21

So let's , uh , let's maybe start with the basics.

2:24

You know, I said earlier that more often

2:26

than not, when we say software development, we actually

2:28

mean product development, but uh we're

2:30

where do you draw that line? When, when does software

2:32

development become product development?

2:35

Uh, I think it often is

2:37

because usually in software

2:40

projects you have users

2:42

and you care about your users and you

2:44

care about their usage. And

2:46

so even if you're working on a software

2:48

project that is going to be used

2:50

internally inside of the company

2:52

that you work at, or even if

2:54

you're working on a software project where the

2:57

person using your software is just

2:59

engineer, maybe you're working on an API

3:01

and that API is going to be consumed by other software

3:04

engineers. If you care about

3:06

that user and you care about how successful

3:08

they are at using the thing you built

3:10

, um, then you're probably going to

3:13

want to approach it as product development. Uh,

3:15

so in fact, it's kind of hard

3:18

for me to come up with examples

3:20

of software projects that don't have

3:22

those attributes. Uh, I perhaps could

3:25

come up with some , uh, and

3:27

of course on internal projects , um, there's

3:29

some concerns that go away. You might not

3:31

have to , um, figure out how

3:34

somebody is going to pay for your software.

3:36

Um , maybe you don't have to market to them

3:38

because they're just kind of forced to use the

3:40

tool that you build for that because they work at

3:42

that company. But even,

3:44

so you tend to care whether they're successful,

3:47

you tend to care whether , um , the

3:49

project is successful. Uh , and

3:52

so many software projects are

3:54

in fact product development projects.

3:56

And this is going to involve more than just , uh

3:58

, we we've, we've sort of hinted at this, but this

4:01

is going to involve more than just software developers or

4:03

engineers to be able to develop that product.

4:05

Right?

4:06

Yeah, that's right. I mean, code is just part of that,

4:08

but , um, it

4:11

turns out that it's really easy in software

4:13

development to build the wrong thing. And

4:15

, uh

4:18

, people are very good at finding

4:20

ways not to use it, even if, you

4:22

know, you build a, an internal tool at a company

4:24

and everybody is forced to use

4:26

it. I guarantee you that people

4:29

find ways not to use it. People

4:32

are very good at working around software that

4:34

they don't like. Uh, so , um,

4:37

so yeah, building the right thing

4:39

in the first place is very critical and

4:41

it's also just, it's just not very

4:43

much fun to build software that doesn't get used.

4:46

Uh, and unfortunately , uh, it's

4:48

an incredibly common experience in our careers

4:50

as software developers, that things

4:52

we build don't get used. Uh, maybe

4:55

not as much as we'd like, maybe not at all.

4:57

They never see the light of day. And so,

4:59

you know , for all those reasons , um , uh

5:02

, we should spend a lot of time paying attention

5:04

to whether we're building the right thing in the first place. And

5:07

it turns out the building, the right thing in the first place.

5:10

Um , and you know, they're the right thing means

5:12

it's good for users. It helps them accomplish

5:14

their goals. Um, uh,

5:17

building the right thing in the first place , uh,

5:20

is often just as important as

5:22

how well it was built. And as engineers,

5:25

we tend to focus our schooling and our education

5:27

and our professional development, a lot on

5:29

issues of build quality, how fast, how

5:31

scalable, how maintainable , um,

5:34

but whether it was the right thing in the first place as often

5:36

, uh , you know, sometimes

5:39

the most important concern.

5:41

So, I mean, it sounds like this is one of

5:43

the things that , uh , like students

5:45

of computer science or just, you know, engineering

5:47

or software engineering in general might find a little bit

5:49

, uh, sort of shocking that, that

5:51

, uh, you know, when you're learning

5:53

, uh , how to code, like, yes, like you

5:55

just said, like, there's this sort of like focus on, well, you

5:57

have to build something that uses the

6:00

right algorithms and the right data structures and

6:02

so on and so forth, but you're never really

6:05

sort of exposed to,

6:07

you know , uh, figuring

6:09

out whether what you're building like actually makes sense

6:11

or whether it's actually , uh , a sort

6:13

of a , uh , a viable product.

6:16

Uh, so how , how , you know,

6:19

can you maybe tell it's a little bit about what,

6:22

what is actually involved in like figuring

6:24

out whether a product is, is

6:26

worth building or not, or I guess another

6:28

way of thinking about this is how do you avoid being

6:31

in a situation where you build something that then like

6:33

no one wants to use?

6:34

Well, I wish I could

6:36

promise that it could , could be avoided. Uh

6:39

, unfortunately almost

6:41

every engineer I know, I think has had this experience , um

6:44

, what goes into avoiding that is it's

6:46

a lot of things on the business side of a technology

6:49

company. So how big is the market

6:51

for this? How many users would

6:53

there be? Are they willing to pay for

6:55

it? What do you need to charge

6:58

in order to , um, to make

7:00

it viable? Um, if you're not going to charge money,

7:02

how are you going to make money? Um,

7:05

who are the competitors and what is their offering

7:08

and can you really beat that and how

7:10

, um, and so yeah, building the right

7:12

thing takes in a lot of those concerns.

7:14

And then there's also kind of just the

7:18

list is kind of nearly infinite, including

7:20

things like, does it feel good to use

7:22

this product? Is it a fun experience? Does

7:24

it like emotionally engagement engage

7:26

us? Um, so yeah,

7:29

it feels like the , the , like a go on and on

7:31

list is pretty endless. And, you

7:33

know, I think the reason that , um

7:35

, as engineers, we're not so focused

7:37

on this in our, in our educations, it's just

7:39

that the technical execution

7:42

that , you know, is it scalable? Is it maintainable?

7:44

Is it fast? Those, our

7:47

teams are looking at us to have those

7:49

answers because if we don't have those answers, nobody

7:51

has those answers. So it is our professional responsibility

7:54

to think about those things. Um , it's

7:56

kind of uniquely our responsibility usually.

8:00

Um, and so that's , that's why we place that happy

8:02

emphasis, but, but then of course, all those

8:04

other factors come into play.

8:06

So, you know, this being

8:08

able to develop a product , uh , as I mentioned

8:10

earlier, you know, involves a

8:12

lot more than just software engineers , uh,

8:15

involves their product development team. Uh, that

8:17

includes a number of roles that , uh,

8:20

you know, someone can study to be a

8:22

designer, can study to be a product manager or

8:24

a project manager, et cetera. But if you think about

8:26

someone who's learning how to code and how to

8:28

develop software, it's very rare

8:30

for as part of your, sort of like your formative

8:33

years. And especially if you're in college, et cetera,

8:35

to be in a position where you actually have

8:38

to work with a designer or have to work with,

8:40

you know, a product manager or a project manager , uh

8:42

, et cetera. Um , so

8:44

can you tell us a little bit about, you know, these various

8:46

roles that are involved in, in product development

8:48

and that, that someone might end up having to

8:50

, uh, uh, to work with?

8:53

Yeah, sure. Um, and aren't , there

8:55

can be quite a lot of different roles

8:57

and , um, you

8:59

might not have all of them involved in the team. It

9:02

would depend on what you're building. Um,

9:04

the three most common that I think people

9:06

often think of is just the core triangle

9:08

of software, product development , uh,

9:11

is engineering product , um

9:13

, product management and user

9:15

experience design. Um

9:17

, and so those three are

9:19

the most common participants.

9:22

Um, so, you know, design, product management

9:24

and engineering , uh , we kind of assume

9:27

that we know that what engineers do, let's assume that we

9:29

know what engineers do. Um, and

9:31

maybe talk a little bit about those other

9:33

two jobs. Um, designers

9:36

are there to ensure that a user has

9:39

a successful experience with the project

9:41

, uh, with the product, excuse me, often

9:45

we think about design as it's

9:47

visual embodiment. So we think of designers

9:49

is making a beautiful product. Um,

9:52

nice . Uh , I often, you know , it

9:54

feels great to use a beautiful product , um,

9:56

but , uh, there's much more to it than

9:58

the visual element of that. Um, it's

10:00

really the usability. And so,

10:02

you know, is it easy for the user

10:05

, um , to complete a task and that task

10:07

might be something very small, like filling out

10:09

a form, or it could be a more abstract

10:11

task, a creative task, like making a

10:13

slide deck. Um, and so

10:16

typically the product has

10:18

an opinion on what success looks like.

10:20

And that's one of the things you need to define upfront

10:23

success might be clicking the button

10:25

that makes you money at the end. Success

10:28

might be that you spend more time

10:30

in this product and somehow the , um,

10:32

the organization makes more

10:34

money or somehow more satisfied

10:37

by having spent more time. Um,

10:39

so, you know, you need to kind of decide to

10:41

find what success looks like, and then you designers

10:44

help take apart. What are all the things that

10:46

make that success difficult? And how can

10:48

I smooth all those barriers to ensure

10:50

success so that you

10:52

know, that you need an understanding of

10:54

what success looks like. You need an understanding

10:56

of what makes that difficult.

10:59

Um, and I think taking an example

11:01

kind of is a helpful way to, to put

11:04

this all together in lots

11:06

of kinds of software. We have

11:08

the D what's essentially the blank

11:10

page problem. So imagine

11:13

yourself about to go do an

11:15

assignment, like a homework assignment

11:17

or something that is difficult. Um

11:20

, and the first thing you do when you open

11:22

your piece of software is you're looking at a blank

11:24

page and that might be a Google doc

11:26

blank page or a black like spreadsheet.

11:29

Um, it could be something else, but

11:33

that feeling of looking at a blank page

11:35

to most of us, even though we think of ourselves

11:38

as creative is kind of scary

11:40

and daunting, it's like that first piece struck,

11:42

like, what am I going to do? And people want different processes.

11:44

They start with an outline, et cetera. So

11:47

designers can help us there . So a

11:49

good designer will help us think, you

11:51

know , given what the task is, how can I help

11:54

that user feel less

11:57

jarred by the blank page and more

12:00

excited to get on with the task you

12:02

start to use. If you pay attention to

12:04

software, you'll see that lots of different pieces of software

12:06

have different strategies for having

12:09

you overcome this fear. So,

12:11

you know , if it's like a , um,

12:14

you know, they may cue you like,

12:16

Oh, maybe you want to do this thing, or maybe you want to put

12:18

in a picture, or how about this? You know, they

12:20

kind of suggestions on how to get started. They

12:22

might give you , um, placeholder

12:24

text or , or other kinds of things to like,

12:27

get you to keep, keep going. Um,

12:29

so, you know, that's just one example of

12:32

a common problem that prevents

12:34

the user from accomplishing their goal and

12:36

good design can , um , can

12:39

overcome that. And that has, it does have

12:41

visual elements, but it also just has what

12:43

we call usability elements to overcome

12:45

those problems. Um , so that's the, that's

12:48

the job of a user experience designer.

12:51

And then the third part of that triangle

12:53

is the product manager , um,

12:57

product managers. Uh , I think a lot of

12:59

us find it really hard to define this

13:01

with pinpoint accuracy. Um,

13:04

I've heard it said that they are kind of the CEO

13:06

of the product , um, in

13:09

some ways I agree, although , um

13:11

, I never want that to

13:13

give , um, other participants

13:16

permission to check out of decisions. Um

13:20

, but I think that the reason it rings true

13:22

in some cases is that our product

13:24

manager is usually bringing together lots

13:27

of information across different expertise

13:31

and bringing together information to make

13:33

important choices. So if you think about

13:35

, um, if you think about products

13:37

that we use where there's different pricing

13:39

tiers, like there's the free tier and

13:42

the cheap tier and the really expensive

13:44

tier , um, the

13:46

product manager is typically making the decision

13:48

about what features go in, what tier

13:51

and so, like what information do

13:53

you need to make that decision? Well, you need to understand

13:55

, um, your user's willingness

13:57

to pay, like how much money is in their pocket

13:59

book that they're willing to devote to this problem.

14:02

And you need to understand, you

14:04

know, what's the, what's the value to them

14:06

of the really expensive feature. Like how much

14:08

would they be willing to pay, to have unlimited

14:11

storage, for example. Um,

14:14

but you also have to have an understanding of,

14:16

you know, what's, you know , you're thinking about future features,

14:18

what is the technical feasibility of that?

14:21

Um, what are our competitors doing? Um, how

14:23

much does it cost us to provide that feature?

14:26

So there's just like a lot of information that goes

14:28

into that final

14:30

thing, which is it's $29

14:32

a month, or it's $80

14:34

a month. Um, and so product managers

14:36

are often working across different

14:39

, um , domains to bring that all

14:41

together and make those final decisions. And

14:44

, um, as you can imagine, it's

14:46

, it's like being

14:48

a generalist is helpful and being a strong communicator

14:50

is helpful.

14:52

Is there, is there a difference between

14:55

a product manager and a project manager?

14:57

Uh , you know, sometimes I've, I've heard those terms, like used

14:59

it a little bit interchangeably, you know , uh

15:01

, is there a clear dividing line between the two?

15:04

Yeah. Um, so my

15:06

opinion is that there should be. So

15:09

I do think that because product

15:11

managers are typically strong

15:14

communicators and organized people,

15:16

it's very tempting for them to

15:18

become project managers. And the project manager

15:21

is a person that keeps track of lots of

15:23

little things in order to like

15:25

keep a group of people on task and on

15:27

time doing a complicated thing. Right.

15:31

Um, so it's very tempting for somebody who is

15:33

a good communicator organized to take

15:35

on that work. And sometimes they

15:37

do. Um, and,

15:39

you know, in teams where I've been involved,

15:41

I've tried to resist that temptation

15:44

because , um, some of

15:46

those business activities and those,

15:48

those activities about users, about

15:50

market and about like price

15:53

or marketing , uh , if the product

15:55

manager doesn't do them, they will

15:57

not happen. And so I

15:59

tend to think that every time a product

16:01

manager does every

16:04

time a product manager does a project management

16:06

task, I moved the card across the

16:08

JIRA board, or I, you know , you

16:10

know, ask somebody,

16:12

you know, some little status report question.

16:15

It's taking time away from

16:17

those questions about users and money

16:20

and , um , usage

16:22

and market and all those business questions. And

16:24

so, you know, what is the real cost

16:27

of doing that? And is there a

16:29

better way to manage,

16:31

to do the status report stuff, to

16:33

do the project management stuff? So that's my

16:35

bias. I think they should be different, or

16:38

I don't think that the job of a product

16:40

manager should be project management. Um,

16:43

and then that's my reason why,

16:46

Ah , okay. So in , in previous

16:49

episodes of this podcast, we've, we've explored

16:51

how software development is a team sport. Uh,

16:53

but we've looked at this mostly from the perspective of collaborating

16:56

of software developers, collaborating

16:58

with other software developers and , uh, you know,

17:00

clearly product management is also a team sport. Uh,

17:02

but , uh, as we've sort of already

17:04

mentioned a couple of times , uh , already, it's

17:07

not the kind of collaboration that you're easily

17:09

exposed to as, as a student

17:11

in , in which you might not even get exposure to in an

17:13

internship where, you know, you may be solely

17:16

focused on software development. Do you think there's

17:18

anything different between collaborating

17:20

with other software developers versus the , the kind

17:22

of collaboration you experienced as part of a product

17:25

development team with, you know, the product management,

17:27

the engineering, the design, et cetera.

17:30

Um, you know, maybe there is some like little milk

17:32

that's in bolts, things about, you know, how to

17:35

chatter and get hub or something. But I think

17:37

the best starting point is that collaborating

17:39

with non-engineers on your team, non-developers

17:42

on the team isn't different. And

17:44

that's kind of a point , um, I think , uh,

17:47

early career engineers having been

17:49

exposed to some of these other roles

17:51

, um, the most common mistakes

17:53

is that they think it's all about engineers.

17:56

Um, they think that, you know , software companies are all about

17:58

engineers. They might think that they're the smartest

18:00

people on the team. Uh , and so that's

18:02

actually the biggest mistake to avoid. Uh,

18:05

so if , instead you understand a little

18:07

bit about what the different roles are and why they're so

18:09

important and how much expertise goes

18:11

into those roles. Um , then it's easier

18:13

to just start saying, okay,

18:16

well, if I understand that,

18:18

you know, I am not God's gift to software development.

18:20

I am not the only person. I'm not the smartest

18:22

person on the people. Then what do you do? Um

18:25

, then with that kind of humility

18:27

, uh, then you're in a good position

18:29

to start seeing like, okay, what

18:31

do I do now? You know , the answer is essentially

18:33

to draw the best out of all the people

18:35

around you to like satisfy

18:37

your own curiosity about what they

18:40

know that you don't know. And, you know , you , so

18:42

somebody with that mindset is likely

18:44

to just , um , they're likely to ask questions

18:46

, um, to learn about what they don't know , uh,

18:50

you know, and when you do that, you tend to find yourself

18:53

in these like really exciting rabbit holes of all

18:55

the things that go into software development.

18:58

So it sounds like one takeaway,

19:00

you know , here , uh, is that

19:03

, uh, you know, if you're someone who is interested

19:05

in pursuing a career in software development, that

19:07

, uh , a, you know, it's not just

19:09

going to be, you know, you working with software

19:12

developers all the time and the software developers are not

19:14

the sort of center of the , uh , of the universe, which

19:16

I think, again, I think some, some students

19:18

might find surprising , uh,

19:21

but also that having the ability to work with

19:23

all of these other people in these other roles can be a very

19:25

, uh , sort of fulfilling experience.

19:28

Absolutely. I mean, I think

19:31

the danger is that when you, when you start

19:33

to see the things that go into a successful

19:36

software product, it's easier to go down these

19:38

rabbit holes and be like, wow, like, look

19:40

at all these interviews we've done with users. And I

19:42

can just like read the transcripts of these interviews

19:45

or like a , you know

19:47

, huh. I didn't know. The designers have like

19:49

a go to way of solving this problem.

19:51

Or I'm like,

19:54

you know, you might realize that the product manager actually

19:56

has, has a number. Like

19:59

if somebody signs up for our product today, that

20:01

product manager knows that on average,

20:03

that person will use our product for seven months

20:06

or 15 months. And your product

20:08

manager might also know that whether

20:10

they , uh , like whether

20:12

they use the new cool

20:15

feature is more likely

20:17

to retain them. They're more likely to

20:19

stay for another six months if they use

20:21

that new cool feature. And so like, once

20:23

you start to realize that

20:26

people have thought about these things, often

20:28

they are these kinds of like artifacts

20:30

of other people's work are out there. And they're readable.

20:33

It's very easy to be. If you're a curious person to be

20:35

down a rabbit hole of finding them all, and then

20:37

you kind of have to like pull yourself back and say,

20:39

okay, like, how

20:42

am I going to manage my own time? I'm here to write

20:44

the software, knowing enough

20:46

about these things helps me do my job.

20:49

It satisfies my curiosity. Um

20:51

, it helps me get, be excited, be

20:53

excited and stay excited at work. And all of those are,

20:56

those are all good things. And then also people

20:58

just need me to write the software. So how am I going to manage

21:00

my time and manage my career to like balance

21:02

those factors?

21:04

Okay. So I think with that, we can wrap things

21:06

up. Uh, Jenny, thank you so much for joining

21:09

us today.