Cabinet Doors Should Open: Avoiding Assumptions in Product Requirements
In this episode of "How Many CTOs Does It Take?" podcast, hosts Scott Porad and Brad Hefta-Gaub discuss the critical importance of clear requirements in both hardware and software projects. Using the analogy of a home renovation project, they explore how detailed planning and frequent communication between builders and requesters can prevent costly mistakes and ensure customer satisfaction. They relate this to the software development world, emphasizing the need for ongoing dialogue between product managers and engineers to clarify assumptions and avoid misunderstandings. The hosts debate the pros and cons of Agile versus waterfall methodologies and stress the importance of engaging engineers early in the ideation process to harness their technical insights and achieve more efficient, high-quality outcomes. They conclude with reflections on fostering a collaborative culture that values clear communication and thorough planning.
Resources:
-
How Many CTOs Pod: https://howmanyctospod.com
-
Scott Porad: https://www.linkedin.com/in/scottporad/
-
Brad Hefta-Gaub: https://www.linkedin.com/in/bradheftagaub/
#TechPodcast #EngineeringPodcast #DevTalks #PodcastForDevs #HowManyCTOs #Podcast #CTOs #CTOPodcast #ChiefTechnologyOfficer #Technology #Engineering #SoftwareDevelopment #SoftwareEngineering #TechLeadership #EngineeringLeadership #EngineeringCulture #TechDebates #ProductManagement #Agile #ProductRequirements #ProjectRequirements
Scott: If you are the builder,
have a conversation to be clear with the requester that you are building what they want you to build. Between requester and builder,
there has to be clarity.
Brad: episode of the How Many CTOs Does It Take podcast.
I'm Brad Hefta-Gaub,
and this is my co-host.
Scott: I'll pull around.
Brad: All right. And Scott,
today,
what do we want to talk about today?
You pinged me recently and mentioned something about requirements and the frustrations that can come from poorly written requirements.
Or tell me more about what was on your mind about requirements.
Scott: I'll tell you what's on my mind.
Brad,
I am doing a...
a renovation project at my house?
Brad: Wait,
we're talking software or we're talking hardware here?
Scott: Well,
we're talking both, actually. That's what's really interesting about it.
I'm doing a renovation project at my house and it involves we're getting new kitchen cabinets. So they took out all the old kitchen cabinets,
they're putting in new kitchen cabinets.
And every Monday, we meet now they started this project two weeks, three weeks ago,
and every Monday we meet with the builder, the carpenters, they have a list of questions and stuff to ask us.
And what has been really surprising to me, they've got, you know, they've got some blueprints.
blueprints they're not blueprints but you know drawings of what's supposed to happen including all these cabinets and how they're all supposed to fit together and all work and it has been fascinating to me the level of detail they are going through in advance to avoid
problems so last week most recent meeting we're sitting there and the builder his name is zach you say okay you see this corner where there's like two countertops that come together in a corner and the way these cabinets are they're not going to be able to open all the way because the hinge is going to get pinched right and so you're going to have these two cabinets that don't you're going to be you are going to be unhappy because neither of these will open all the way because of the way this
this design and he had some ways we can solve it but I thought it was so fascinating how much time he spent studying drawings and these are just drawings drawn by an architect you know they're not real-world mock-ups or anything
just looking at them thinking about like each little detail how is this going to open how is this drawer going to work how is this cupboard cabinet going to work or not cupboard cabinet how's this cupboard door going to open he's he clearly had spent time thinking through every detail of these pictures before they started building and then brought it to us with his concerns saying look i've observed these things and these are challenges that you're going to run into because clearly he knew that
Once we order these cabinets and have them delivered and he goes to install them, it's going to be very expensive to deal
Brad: Yeah.
Scott: with it. First of all, we paid for a cabinet that we can't take back.
Second is it's going to stop his whole project, right?
He's got a whole schedule of contractors and subcontractors and all these people all queued up to make his whole thing really efficient.
And if all of a sudden he has to stop for two weeks because our cabinet doors.
don't open right in this one corner or if you get to the end of the project where the cabinets are in the countertops are in the floors have been done everything's done and we go back into our brand new kitchen and we're like well Zach these
Brad: Again
Scott: door this door sucks this thing sucks I can only open it like three quarters of the way because we can see it hits this other one
I just thought that was fascinating.
Brad: I'll tell you, you're glad you've got that contractor that's paying that much detail because I have horror stories from times I've done remodels where like, you know, the two examples I can think of is a little mini fridge in the in the wet bar area of the media room where the.
They didn't measure the overhang of the countertop correctly and the door for the mini fridge wouldn't open because the countertop was overhanging into the door,
you know, and so they had to solve that problem after the fact because the fridge was built and the countertop was made. It's like, ah,
it's horrible. And another example similar where the.
toilet chosen for the powder room the dimensions of it didn't allow the toilet to go into the actual drain uh that the toilet goes to right like they had to you know jerry rig a solution there or buy a different toilet and it's just like you know i remember that toilet was sitting in our garage for like um two months while they figured out a plan to fix the fact that we'd already ordered the toilet and it didn't work
Scott: That's right.
And so as soon as this happened, I'm in this meeting,
and when I say it's a meeting,
I mean, it's just us getting together at our house and talking.
It's a meeting.
And I instantly thought about our business and software and just requirements.
So this wasn't actually a requirement.
I mean, we just had a requirement that there's two cabins in the corner,
Brad: Well,
Scott: but I just
Brad: and thought, you could open
Scott: yeah,
Brad: them.
Scott: I thought that was a requirement.
But I just instantly thought about what we do.
And I mean, I don't know if I reached a conclusion.
conclusion like i was like huh maybe we should spend a lot more time being a little more water folly and specking this stuff out like it was one thought that came to my mind we just like thought about like wow look how detailed this guy's doing and everyone in our industry like we'll just go in there and start coding right i just thought that was a fascinating difference
Brad: Well,
I so it's so interesting you say that like I okay so
the the example of him saying like hey if we did the cabinets the way we talked about it you won't be able to open them like they'll pinch each other you won't be able to open them completely and to then step back and go well of course
I didn't feel like I had to say it's a requirement that I be able to open my cabinets completely.
Like,
Scott: Yeah,
Brad: why would you think that that needs to be listed as a requirement?
It's so obvious that that's a requirement.
Do you
Scott: yes
Brad: even need to write it down?
Scott: Yes, that's right.
Brad: And I feel like I was like literally just today we were in a sort of like mid sprint demo on a new feature.
And apparently like there was something that was assumed by, you know, the product owner assumed that it would be drag and drop and real time update of the drag and drop to everybody else in the app at the same time, kind of like they all saw the thing being dragged in real time.
But that was an assumption.
And that was never written in any of the product requirements.
And the developer, of course, didn't think to build that, but was like, well, I just assumed, you know. So how many times has that happened in our careers?
Scott: I think the assumption is really interesting.
And there's a difference,
right?
Zach,
who's roughly about your or my age, might be five or ten years younger.
He lives in a house with a family.
He can make reasonable assumptions.
assumptions about how a person might like their cabinets to work because
Brad: Because he
Scott: he
Brad: has cabinets.
Scott: has a house he has a house with cabinets whereas so much of what we do in this in the software business i mean even
Brad: It's a big secret.
Scott: when we're not doing something novel it's new and there's no there's just no standard agreement for how these things should work in fact i was on a website recently i wish i could remember what it was
and the navigation was so poor on this website and it just made me think about like there are so few standards for how anything works with software applications and it makes this job so much harder and it comes back to this assumption there's so few reasonable assumptions like the cabinet should open all the way
Brad: Yeah.
Scott: Did it make our job harder? What conclusion do you think? Is there something that we should take from what the home builder who doesn't want the customer, doesn't want to have his job get behind schedule,
doesn't want to have to redo the work,
doesn't want to have an unhappy customer,
so has taken the effort to go through these plans up front in detail and have a conversation in advance before we've even ordered the cabinets?
I feel like there's something we should take from that in order to do a better job.
I'm just not sure what it is exactly.
Brad: It's a great question.
And I think that, you know, if you sort of like you, you, you, you already keyed this up as a description of more water folly in nature,
right, versus I think what is mostly the norm these days, which is more of some variation of an agile process.
I spend most I've spent most of my career in the in this in the startup game where we're doing novel stuff and we're doing stuff where a lot of times we don't.
we don't really know what we want,
right?
There's so many, there's so much in the sort of like entrepreneurial space out there saying like,
you know, try to be able to move rapidly.
Don't, don't be too fixed in what you believe the customer wants.
You need to experiment and give them, give them something good enough to criticize and then adapt quickly.
Like that is a model that is adopted by a lot of software companies.
And then, yeah, every once in a while it can bite you where you thought you were, you know, like I think when we had Greg Conklin on the show, you know, he was talking a lot about like get really clear about what your what your core principles of your product are.
Like if performance is a core principle,
right,
then you better say that out of the gate. Right. Because, you know, I think he told a story once where it's like they were dealing with a system where the architect was like, wait a second, like.
I thought you wanted, you know, an RV.
If I'd known you'd wanted a Lamborghini, I would have designed this completely differently,
Scott: Mm
Brad: you
Scott: -hmm.
Brad: know.
So certainly there can be cases where dramatic misunderstandings at the start end up painting you into a corner where you kind of like really struggle to achieve your outcomes.
But there's so much energy right now in the space around,
you know.
iterate quickly,
don't be too beholden to one idea because
You don't really know what good looks like.
And I think that's this wave or this gravity that pushes against the thing that you're asking,
should we do more of?
Scott: Yeah, and I'm going to try and split the baby.
It goes like this.
Agile said don't document all these crazy plans up front because you don't really know if the customer wants them. So build something and see if they want it.
And what we're really saying is something different,
which is if you were the builder,
have a conversation to be clear with the requester that you are building what they want you to build.
Now, the requester might not know what the customer wants, so they might want you to build it rapidly,
but at least between requester and builder,
there has to be clarity.
And what I would take from this actually is not as I think there's actually a different prescription than being more water folly.
I would say if you were an engineer,
if I were an engineer, my ticket then pulling off the wall to go work on could just have one line. It could just say, you know, go add a flux capacitor to the DeLorean,
but go take,
it is worth it to take a minute just like Zach did.
with my wife and I, Lisa,
to look at that carefully and have a conversation with the person requesting and saying,
well,
this is what I see here.
Is that what you really meant?
Because your cabinet's not going to open.
Brad: Yeah.
Scott: And by the way, I've built software before and I have a hunch you're going to want your cabinet to open when I'm done with it.
So let's just talk this through.
We don't have to build a whole spec. Let's just have a conversation.
Brad: Yeah, I by the way, I think that's 100% good,
good practice, you know, in the in the in the current scale of organizations that I'm working with very,
very small scale so I can kind of be in the room when those types of conversations should be happening.
And 100% those are what I am trying to teach and encourage engineering teams to do is to create these very open,
you know, frank,
whatever you want to call it, but like, you know, curious conversations between the engineers doing the work and the product owners describing the work. And also.
wherever possible involved in that conversation should be a here's what I think you're asking for am I hearing you correctly right am I understanding what you're asking for correctly so that's like a that's required that's table stakes but another part of that conversation should be my instinct is it's going to be this expensive to build what you've asked for have you considered tweaking these pieces of your ask
Because in my experience, if I tweak these pieces of what you're asking for,
it will have a different cost outcome.
Like it'll be less expensive.
It'll take me less time to build it.
For example,
I can build it the way you're asking.
I can build you what you're asking for.
But if I take that requirement off or I add this other slight nuance,
it changes your investment profile.
Have you considered that?
I think that is a super important conversation that also should be happening and probably doesn't happen enough.
Scott: Yeah, that's right.
In fact, that's similar to what happened with Lisa and I in our cabinet.
Because we wanted to have the cabinet a certain way and I won't go into the detail and he could figure out a solution,
right?
Or we could have it a little different.
I think what we're really saying though is we're saying a lot of things, but another thing we're saying is as an engineer,
to be a really good one, to deliver a high quality thing that your customer will be happy with that's on time.
time and sometimes your customer is just the requester it's not the end user but just to deliver a thing on time that's high quality that meets your standards of quality etc you're not an order taker you have to be engaged in the process it is a creative process
Brad: Yeah.
Scott: You got to participate and you can't just pick a ticket up.
The expectation that someone can write a perfect ticket implies that they have the forethought to say and the cabinet should open all the way.
Brad: Yeah, right.
Right.
Exactly.
Scott: Isn't that obvious?
Brad: Right. And we've talked about, you know, recently we spent some time talking about software development lifecycle.
And one of the parts that we talked a lot about was this question of like,
well,
you know, and we talked about quality and we talked about the idea that like.
quality begins and your software development lifecycle begins way upstream when you're just trying to figure out like what are you building what are you what problem are you trying to solve
Scott: Mm
Brad: right
Scott: -hmm.
Brad: not the writing of the code but the description of the problem you're trying to solve is
Scott: Yeah.
Brad: is critical one of the other practices that I encourage teams to implement and I'm seeing some good success with this in some of the projects I'm working on now is
That back and forth, that dialogue, that curious conversation between the future implementers and the ideators, right,
the product team and the development team,
you don't even want to wait. You would like to get that conversation started as soon as the ideators are starting to ideate.
Scott: Mm
Brad: Right.
Scott: -hmm.
Brad: Because if they can say,
hey, we've been thinking about adding a new feature X and here's some stuff we think we want to do with that. Right.
Right out of the gate, the engineers can start thinking about it and go, yeah,
OK,
you're not done with your.
You don't know your requirements on us yet,
but here are some things on our mind that we're going to want to ask you when you finally do come to us with this idea.
We're going to want to ask you about, is it real time?
Does it need to work on low-end machines?
Does it only work on high-end machines?
The things that are going to pop into – because most engineers,
as soon as they hear the description of the thing,
they start to imagine how they will implement it.
Scott: Mm-hmm.
Brad: And they can start to ask questions early that then might inform and hopefully improve the.
The actual feature requests the requirements before the okay now we're really trying to understand your requirements
Scott: Well, and they can,
I think this is something I see a lot.
Engineers can push it further in two different ways.
One is a technology way,
which is like, I'll give you a simple example. It's not perfectly simple,
but if else,
so conditional,
a conditional solution.
versus a probabilistic model solution.
Lots of times someone will come and say, I want to build this thing.
And if the customer does this,
then we should do this. And if the customer does that, we should do this. An engineer might be able to say,
we know actually a better way to solve this is to use an ML model.
right because we actually get might get all types of different scenarios with customers and we want to respond appropriately so that's one example of where engineers can bring their understanding of what technology can do to the table the
Brad: Yeah.
Scott: second the second place I see it happening a lot and I'll be honest earlier in my career I think I I think I earned a lot of the success that in my early career because this is something that I was good at bringing to the table
example is a requester or product manager would bring an idea we should do this and I would be able to sort of say well like okay here's how we could make that generic so like we can solve that specific problem but then like the thing we build will solve many problems in this category so I think I've maybe mentioned on this podcast if I haven't like the first three companies I worked at
back in the early days of the internet i worked on content management systems right and so that's very much someone say hey i want you to put a web page up on the site that has these words on it right and i was okay well i can do that for you i can build the system and then you can put up any pages you want on this website right and that's where you take one category of solution and then extract it to a
generic solution to solve it and I think when that when product pulls in engineering and when engineering is involved earlier and engaged in the process those are two actives what can technology do that you're not thinking of and how can we make this generic to solve a greater set of cases instances of this
type this is the way to put it right yes
Brad: Yep. I have certainly seen in some organizations a reluctance in product teams to engage in those early conversations.
So first, have you observed that in your past and what do
Scott: i've
Brad: you think that might be about?
Scott: observed it i think it is about i think it's cultural
And I think my initial reaction is that it has two aspects to it.
One dimension of the culture is I don't want to spend,
this comes from the product management direction,
I don't want to spend a single minute of my time having my engineers do anything other than coding.
So I want to get as much out of these engineers as I can get.
Brad: Which is clearly that right there is a misunderstanding of what it takes to have.
engineers be efficient.
Scott: Yeah.
I think another aspect of the culture is from the engineering.
I don't want to go to a meetings. Can you just put it in the ticket?
Can you just write the PRD? I'll just put it in the PRD. I'll just do it. Just whatever the PRC says,
I'll get it done.
And that reminds me of a conversation about
This is a little bit of a tangent,
but it has to do with just writing things down.
An engineering manager I worked with, his name is Johan Heller.
He actually now is an engineering director at the company I'm at now, but he was an engineering manager then.
He gave a presentation at a company we worked at a few companies ago about the importance of being specific in your requirements.
And he talked about if you give me a requirement that says I want a...
the square i talked to you about
Brad: Yep.
Scott: this before okay
Brad: Yeah,
you mentioned this in an episode in the past.
Scott: well then i'll be brief and our listeners can go back and find that easter egg but there are many definitions for a square is it a square cash register is it a square box what kind of square do you want is it a square is it a t-square for for measuring things so it was just a really visceral explanation that non-technical people could understand for here's why as an engineer i need specific requirements
But I only bring this up to say, I think culturally on the engineering side,
we have engineers who say,
I don't want to go to meetings. I want to have conversations.
I want to do this. I don't want to be engaged with it. I just want to take tickets and crush them.
Brad: Yeah.
Scott: That's contributed to it also,
I think.
Brad: Yeah, sure.
And I, you know, look,
I think it takes all kinds, right? So I know there are some engineers that are most effective when they don't have when they can just be given tickets and crushed it. And I think that's we should try to find ways in our organizations to support those types of engineers.
I prefer to see engineers that are really, really interested in engaging.
And I think that, you know, in a prior episode,
we were talking.
We're talking about the Dora metrics around AI and this notion that some organizations have more user-centric engineering cultures,
Scott: Mm-hmm.
Brad: right?
To me, user-centric engineering organizations are the types where engineers tend to be really, really curious about understanding the needs of the users,
and therefore they probably are more likely to want to have those conversations early on.
They're less likely to be just writing in a ticket and I'll build it type.
type person um but that being said um yeah i think you're right that like it's cultural one cultural thing you didn't mention that i think i have observed um which i think maybe is good enough to call it an anti-pattern that we want to try to fix if we saw it in an org is a fear of um it's not yet ready for review
Scott: Mm-hmm, mm-hmm.
Brad: Right.
And or fear of I don't want to be criticized because I'm not yet done with it or I'm not yet ready for it to be critiqued. I'm going to go so far as to say that's a that's an anti pattern that we should try to.
If we identify it, we should probably try to address it, you know, culturally.
I mean, the earlier we critique it, the better, honestly,
right?
Like if there's a glaring problem in it, we want to find that sooner,
not later.
Scott: Yeah, that's right. That's right.
And yeah,
I'm going to take a page out of my lazy developer playbook, which is
Sometimes when there's a thing I need to do and it needs to be more thoroughly fleshed out,
I will actually intentionally do a very,
very quick and rough and not ready for primetime first pass on purpose and put it out there.
just to get just to get the feedback like it's better to spend 10 minutes on it and just get something out there and start getting feedback and feel like i need to spend two hours or two days and then get it out there and still get feedback and so there are moments where i feel like oh god i don't even know what to do here and i'm just like well effort i'm just going to throw something on paper or whatever it is and just put it out there and just see what people say and it's remarkable how effective that is first of all people are glad that they're getting something
Some people are so good at reacting to things.
They're glad they're getting something to react to.
Brad: Mm
Scott: And-hmm. it's super helpful for me because I'm like, oh, yeah,
here's all these things I hadn't considered and it's helped sharpen my thinking. And then usually I can just pound out whatever the thing is because I've got that input.
Brad: You know, it's so funny is I think was it our first real episode out of the gate, not after our sort of like why we call ourselves how many CTOs and introducing ourselves was our interview with Marcelo Calbucci about his PR
Scott: Is it here?
Brad: FAQ book.
And didn't he say that one of his little magic tricks that he personally uses is even if he's he's labored over something when he sends it.
Sends it out for review.
He tells people it's
Scott: Yeah,
Brad: a draft.
Scott: interesting.
Brad: And as you recall,
if you recall his reasoning behind that hack is there are a class of people who are less likely to give you.
you know, candid critique if they believe that you will take it personally if you give them candid critique.
Scott: Yeah, or,
you know, you spend a lot of time on this already.
I don't want to hurt your feelings,
that kind of thing.
Brad: Yeah.
And so it's, that's a, that's a, so these are, I mean, again, like, so,
so we started this conversation down the whole question of like, how do we get better requirements before building things?
And it feels to me like what you and I seem to be gravitating towards is, man,
the more conversations we can have earlier,
the better.
Scott: For sure. I thought of another cultural thing,
though. Before we wrap up, can I share the other cultural thing?
Brad: Yeah,
absolutely.
Scott: You had mentioned the cultural thing is not ready for review.
I think there's another cultural thing, which is sometimes,
you know, people bring us the solution they want us to build.
But they're not totally dialed in on the problem they're trying to solve always.
I mean, they kind of know the problem they're trying to solve. But now engineers often say,
well, just give us the problem and we'll find a solution.
But it's in between,
right?
It's like whether
Brad: Yeah, totally.
Scott: it's the product manager or the CEO or the startup or whatever needs to be able to engage with the engineer on both the problem and the solution.
Right.
Brad: Yeah.
Scott: Like, let's let's not only talk about the solution you brought me and I see that.
OK,
go back to my cabinet example from the beginning of the thing, which is, OK,
the problem you saw was these cabinets were going to have a pinch point.
What's the what's the problem you guys are trying to solve here? Well,
this is a corner cabinet and we want to utilize all the space.
So we're trying we're trying to have one of these pull out.
kind of lazy Susan kind of things
Brad: Lazy
Scott: and
Brad: Susan thing.
Scott: that's what that's that's that's what we're trying to put there it's not fitting he's like oh okay your problem you're trying to do is solve is trying to maximize the use of this space let's see what so we had to engage in both the problem now that was obviously self-evident because he's a builder and builds kitchens all the time so he knew what we're trying to do but with within software it's that same thing I think
One of the cultural things is people come to engineering teams just with the solution.
the engineering teams react and say that react with the pendulum swinging all the way the other way which is just bring us the problem don't bring us the solution but actually it is in the middle it is you got to engage in both the problem and the solution and it reminds me of something i just posted it on linkedin recently i'm just we're would work and we're doing some creative thing and this guy worked with just he just kind of said innovation is messy
right and that's what it is you got to get in there and just explore these things and it's messy it's not
linear waterfall like we want you know like we talk about it is you got to talk about the solution the problem the solution the problem maybe go think about it come back iterate on it a few times it's messy yeah
Brad: Yeah.
And agreed on that. And on the whole point of like, understand your problem before starting to discuss solutions.
I think that's a that's a there's certainly very good.
uh wisdom to be found in the do you really understand the problem uh part of the solutioning i agree with you i've seen cases where there's essentially a pendulum swing and a blowback like don't ever bring me solutions only bring me problems right and and um i'll come up with a solution and i agree with you that that's a that's equally an anti-pattern right like
Scott: It's a further anti-pattern.
I think this is where a lot of that comes from.
I don't, this is what I say a product manager writes it.
They might not say it, but implicitly, I don't really know the problem.
My boss just told me this is what I was supposed to do.
Someone told me I needed to go put a flux capacitor in the DeLorean.
So that's what I'm asking you to do is put a flux capacitor in the DeLorean.
I don't know why. I guess they want the car to go faster. That's what it seems like. I don't know. Right.
So who
Brad: Yep.
Scott: wants the car to go faster?
Why do they want to go faster? You know, et cetera, et cetera.
Brad: They want to go faster or do they want to go safer?
Are you sure they want it faster?
We
Scott: Well,
Brad: don't know.
Scott: for anybody who doesn't catch the reference I'm talking about,
it has to do with Back of the Future. Right. And and and and what was the guy's name? The professor.
whatever he wanted to go back in time was there a reason he wanted to go back in time do we remember why that he wanted to go back in time or did he just want to make a time machine because he thought it was fun
Brad: I think it was just he wanted to make a time machine because he thought it was fun.
But then it turned into all kinds of trouble when you go back in time, you got the you got the, you know, meet yourself paradox.
What happens if you meet your parents and break up your break up your mom and dad and you cease to exist?
Scott: Things get very messy.
So yeah, I think I think part of the problem there is the requester doesn't always know because they've been instructed.
Brad: So think, yes,
100 percent that happens.
Uh,
and, you know, as long as we're kind of like talking through all the cultural things, right? Like the key here is that as leaders, we want to be able to identify when there are these, you know, cultural impediments to actually,
you know, making progress in the business objectives and meeting the needs of customers,
right?
And then we, so being able to identify them are a pretty important part of that,
you know, and we should.
We can't look past the fact that a lot of people's ego is wrapped up in the solutions that they come up with.
And that can happen on both sides of the equation.
It can happen in the engineering team. It can happen in the product team.
And ultimately,
building software is a team sport.
We need to encourage people to have a team mentality about it and recognize that the team as a whole deserves the credit for.
solving customers'
needs.
Scott: It is truly a team sport.
Engineering, product,
design,
data all have to be working together to make this thing work.
Brad: So there you go.
Work together,
people.
Scott: Yeah, I mean, I think the lesson to take from all this is it is a requirement of a cabinet door that it opens.
Brad: did it be able to open it seems obvious but sometimes we got to write down the obvious it's
Scott: All right, Brad, it's been nice talking today.
Brad: been good talking to you this is a good episode remember what do we say kill
Scott: Smash that subscribe button,
rate and review,
leave a five-star rating,
tell all your friends.
I actually,
believe it or not,
This is a little bonus episode on our episode.
Met my first person in the wild who is a listener of our podcast.
Brad: That you didn't know?
Scott: I didn't really know them. They were they were a friend of a friend.
And
Brad: Uh
Scott: so
Brad: -huh.
Scott: there was a relationship that they probably that's how probably the algorithms got it in their feed and they clicked on it and thought it was interesting.
Brad: Nice.
Scott: And the person is not a software engineer.
They're a data scientist analyst type.
They worked they work at Starbucks. They work on.
whatever you call labor capacity management basically scheduling people but how to efficiently schedule people in stores and i met this guy and he listens to our podcast
Brad: Nice.
That's
Scott: so
Brad: cool.
Scott: he's one of the faithful 39 all
Brad: There you go. All right.
All right. Well,
next week, we'll have more.
Scott: right bye
Brad: Bye.
This episode of How Many CTOs Does It Take podcast was edited by Saffron Epigow. Our theme song was AI Generated by Brad.
Please follow us on all the social media platforms at at HowManyCTOsPod.
You can find us on YouTube,
LinkedIn,
Instagram,
Facebook,
Threads, X,
TikTok,
and Patreon,
or at our website at HowManyCTOsPod.com.
And remember to rate, review,
and subscribe on the podcast platform of your choice.
How many CTOs
Thanks for listening.