The Costliest Mistake with Engineering Teams
Key Points
- The common belief that shipping an imperfect product is the most wasteful use of engineering time is a myth; delivering a deliberately imperfect MVP can be strategically valuable.
- Conversely, the idea that over‑polishing a product is always the biggest mistake is also a myth; some contexts demand high quality and safety before release.
- Effective product planning should treat engineering effort as an “elastic time constraint,” matching the amount of work to the specific risk‑reward profile of the initiative.
- High‑stakes domains—such as drone delivery—illustrate cases where absolute reliability is non‑negotiable, requiring engineers to solve critical problems fully before launch.
Full Transcript
# The Costliest Mistake with Engineering Teams **Source:** [https://www.youtube.com/watch?v=CEDXz_M-5BE](https://www.youtube.com/watch?v=CEDXz_M-5BE) **Duration:** 00:11:07 ## Summary - The common belief that shipping an imperfect product is the most wasteful use of engineering time is a myth; delivering a deliberately imperfect MVP can be strategically valuable. - Conversely, the idea that over‑polishing a product is always the biggest mistake is also a myth; some contexts demand high quality and safety before release. - Effective product planning should treat engineering effort as an “elastic time constraint,” matching the amount of work to the specific risk‑reward profile of the initiative. - High‑stakes domains—such as drone delivery—illustrate cases where absolute reliability is non‑negotiable, requiring engineers to solve critical problems fully before launch. ## Sections - [00:00:00](https://www.youtube.com/watch?v=CEDXz_M-5BE&t=0s) **Debunking the Imperfect Release Myth** - The speaker argues that shipping an imperfect product isn’t the most expensive mistake for engineering teams, emphasizing flexible time constraints and proper MVP trade‑offs instead. ## Full Transcript
what is the number one most costly thing
that you can do with your engineers if
you're in product management or frankly
if you're an engineering leader what's
the most costly thing that you can do
with your engineering team we're going
to talk about that today and we're going
to dispel some common myths that people
spread pretty widely around Tech around
what is the most expensive uh or costly
thing that you can do that wastes
engineering team time and
talent number one this is a we're going
through the myths first we'll get to the
thing that that is the actual cost C at
the end so the first
myth it's it's incorrect to say that
building and releasing an imperfect
version of your product is the most
costly mistake that you can make with
your engineering team that's just not
true and part of the reason why that's
not true is that oftentimes you want to
be deliberately imperfect so that you
can trade off and get to Market faster
so there's that whole conversation
around what a minimum viable product
looks like and how minimum is to minimum
I'm not going to get into that whole
discussion today but I did want to call
out if you're thinking about the highest
and best use for your engineering team
you want to be thinking about products
in terms of an elastic time constraint
so that you can say this is the correct
amount of time to spend on this product
for the risk and the reward that we're
looking at and that can include shipping
imperfect product that's not necessarily
a waste of your engineering teams time
and if you hear otherwise that's a myth
it's myth number one myth number two is
the opposite it's it's a two perfect
version and I do hear people who love
the idea of an MVP saying that the worst
thing you can do with your engineering
team is to spend too much time on the
product and to make it too perfect and
too polished I don't think that's always
true I think it's sometimes true just
like a lot of things in product it
depends on the context for example if
you're trying to solve a problem that
needs to be all the way solved before
it's solved at all you're going to need
to polish the edges uh a great example
of that is the iPhone was released in a
fairly polished State even in version
one and I know we look back on that now
from the perspective of like our iPhone
15 over here or whatever it is and we
say I cannot even imagine being in 2007
and calling that phone polished but at
the time it was polished I'll give you a
different example that's not Apple if
you are trying to solve the problem of
uh drone delivery I heard a good talk on
this actually when I was at Amazon you
need to be sure that your drones will
never ever ever fall out of the Sky
because the cost of that would be
killing a customer and that's way too
expensive you can't ever afford that
that's never
acceptable and so you have to solve the
problem of safe flight and safe package
delivery completely before you release
it all and so it would be incorrect in
that context to say you're wasting your
energy by spending too much time
perfecting the product because you're
not wasting it because that's the bar of
the product demands I'm going to make a
second point though here that is rarely
made and that I want to stand behind it
is also true that the most wasteful
thing you can do with your engineering
team is not is not to over perfect a
product that you could have released
sooner that's still not a great thing to
do so if you are in a world where you
can release a scrappy minimum viable
product and those things do exist not
everything is high stakes like drone
delivery great maybe you're releasing a
sort of a small proof of concept piece
of software it maybe you spent too much
time on it with your engineers that's
not a great choice it's still not your
worst choice and we're here today
looking for your worst Choice as an
engineering manager or engineering
leader because I think understanding
that helps you understand where you can
put your time most and this goes for
product okay so if you if you spend your
time on creating imperfect versions of
things that's not the worst thing you
can do if you spend your time creating
two perfect versions of things that's
myth number two that's still not the
worst thing you can do and the reason
why is neither of those things play with
the core risk factor involved those are
all playing with engineering time as the
key risk factor and that is a false
Assumption of risk your biggest expense
here is not the cost of your engineers
and people assume it is and so when they
talk about you built it to imperfectly
now the engineers will have to go back
and do it again it still translates to
engineering time as the basic unit of
economics if it's too perfect it goes
back to engineering time as the basic
unit unit of
Economics it's based on a full flaw
assumption because at the end of the day
engineering cost is not the biggest risk
risk factor for your
business and I'm going to give you one
more example on the engineering cost
fallacy so the third one that people
often do is they say Engineers need to
maximize the time they spend on keyboard
and not planning and thinking right
there's this assumption if the engineers
aren't producing code they're not doing
work and anyone who's worked in
engineering will tell you that that
doesn't make any sense at all but
Business Leaders sometimes make that
assumption and sadly product managers
will sometimes along with that is
absolutely not a mistake a problem
something that needs to be corrected
engineering thinking and planning before
they go into coding is actually a great
choice and so this is one of those
things where there's not really in my
mind much of a debate you want to make
sure you have time for your engineers to
think and plan carefully but people do
because they think of engineering cost
as time it takes to produce lines of
code assume that you have to have your
engineer sort of maximizing the number
of lines of code out and any engineer
will tell you it's actually not the
number of lines that you want to
maximize it's the efficiency and
elegance of the system and the way it's
able to solve problem and so we have
this factory production mindset that has
crept in from frankly the 19th century
and the early 20th century when we did
assembly lines where we assume that
Engineers are workers on assembly lines
mentally and therefore they need to be
working to make code all the time and
the core cost that we're dealing with is
like how quickly can they turn out the
code and is the code the right quality
and that factory mindset underlies all
three of these that's what we talk about
and think about when we say this time
unit cost of engineering as our biggest
risk factor I want you to take that
whole mental model and just put it to
the side it's not super helpful in
actually understanding the real cost
because at the end of the day that is
the wrong mental model to understand
software software is not a factory you
do not make software on an assembly line
like that instead software is a series
of bets that you're playing on how you
can assess product Market fit using
software and if you get the BET right
software gives you tremendous leverage
to unlock that value farther and that's
why software isn't like factories
because it's not like you're making five
different kinds of cars and you can make
a thousand of them cheaply as soon as
you get one to work you're actually
committing to a production run and
you're making them linearly when you're
dealing with physical goods and physical
products I've had to do that
but with software it's actually really
elegant and really easy to make these uh
thesis or bets and see if they fit and
that brings me to the part that is the
biggest cost what is the biggest cost
for your engineering team in a world
where you actually understand how
software is made in the unit economics
of software it's aiming incorrectly it
is producing bad thesis or bad bets that
you will then follow up and have to
spend time on when you shouldn't be
spending time on the BET in the first
place and that is why product is such a
high leverage higher because at the end
of the day a product manager's job is
not to make bad bets they need to make
bets that are as high quality as
possible that doesn't mean you expect
every single one of them to work but it
does mean that you expect them to be in
a direction of a learning Loop really
deliberate as high quality as possible
grounded in customer as much as
possible and that you expect the product
manager to be able to learn and adapt
quickly and so when you're hiring for
PMS that's what you're looking for and
when you're looking at the cost to your
engineering team you're looking to
basically say is the engineering team
spending their time on the right
bets and so in a sense the value of the
engineering team is contingent on the
value of product Direction and whether
or not you get your product direction
from a product manager or from an
engineering leader or from your CEO
that's still the fundamental question
are you putting your engineering team
against the right bets because each bet
you start is like a little thread across
an unknown landscape and if you start
that thread just the motion of momentum
tends to carry you forward on that
thread and you will put inordinate
effort into trying to prove out that
thread going forward it will take you
longer than you expect to stop longer
than you expect to release fast follow
features that's just the way software
works so you better get where you want
to start right and that's the key risk
if you are bad at pick in where you want
to start at exploring what I would call
a latent space for product where you're
trying to figure out whether the product
fits or not if you pick incorrectly if
you frame the problem wrong if you pick
the choice of features for your MVP set
so you're not actually learning
something that's going to be a problem
that's a bet that you can't take back
very easily that's something that's
going to be very expensive because your
entire effort from your engineering team
would be poorly poorly in tested and
poorly chosen from day one like it
doesn't even matter if it kind of works
if you frame the problem badly enough it
won't be
scalable in a sense it is possible to
get your engineering team going in a
direction where it will take months to
unwind whatever you do you will learn
nothing and your bet will be wrong from
the GetGo and I have seen that happen
and that that is the actual risk of how
you waste time with engineers and it's
not just product managers that do that
I've seen business leadership do that
sometimes I've seen enging leaders do it
and if you understand how software Works
getting your engineers focused on the
wrong bets is the number one biggest
risk you can you can face so make sure
that you are betting correctly and that
is probably a separate video we'll do a
separate conversation on how you aim or
how you set up your bets correctly but I
wanted to call out those myths because a
lot of people think oh it's about over
perfecting your product that's the most
expensive thing you can do with
Engineers no it's or it's about under
perfecting the product you're releasing
a flawed product that's the most
expensive thing you can do because
you'll have to to rework again no unit
cost is not the problem and unit cost is
also not the problem when your engineers
take time to think which is the third
major myth none of those are really the
issue because factory models of
production for software are a flawed
mental model software is about bets and
the core value that you have is making
the right bet and it follows that the
core risk that you take is making the
wrong bet that is the most expensive
thing you can do with your engineering
team and I recommend not doing it let me
know if you have any uh bad bats or good
bats that you want to chat about in the
comments uh cheers