Config 2024: The heirloom tomato org chart (Nan Yu, Head of Product, Linear)
Summary
TLDRThe speaker shares insights on startup org chart structures, critiquing the uniformity inspired by the 2012 Spotify model. They discuss the importance of aligning team structure with product goals, emphasizing the pitfalls of symmetrical team setups and advocating for a more purposeful, asymmetrical approach that reflects the unique needs of each product. The talk highlights the impact of Conway's Law, the challenges of scaling, and the necessity of making informed, context-aware decisions when structuring teams for optimal productivity.
Takeaways
- π The importance of org charts in startups is often underestimated, but they play a crucial role in shaping the product and the company's direction.
- π The speaker observed a lack of variance in team structures across early and mid-stage startups, often defaulting to a model inspired by Spotify's 2012 paper without fully understanding its context or applicability.
- π The speaker's experience with startups revealed that team structures often led to a loss of focus and increased technical and product debt, contrary to the intended efficiency.
- π€ The key question posed is whether the current team structure truly supports the company's goals and whether team members understand how their work aligns with the company's broader objectives.
- π‘ Conway's Law is highlighted as a significant principle, suggesting that the structure of a company's team will reflect in the product it develops, emphasizing the need for a well-thought-out team organization.
- π The danger of symmetrical team structures is pointed out, as they can dilute focus and lead to a product that lacks a clear main feature or direction.
- π The speaker advocates for org charts that reflect the actual shape and needs of the product, rather than following a one-size-fits-all approach.
- π Resisting the urge to create symmetrical org charts is crucial for startups aiming to focus on their main product offering and avoid spreading resources too thin.
- π Historical references, such as the 'two-pizza rule' and 'high output management', are not absolute and should be critically evaluated in the context of modern communication and work practices.
- π¬ The speaker emphasizes the need for clear communication and understanding within teams, ensuring that everyone is aligned with the company's goals and their role in achieving them.
- π The conclusion encourages founders and companies to trust their intuition, start with a clear understanding of their product, and shape their org chart around that vision.
Q & A
What is the main topic of the talk in the transcript?
-The main topic of the talk is the structure of organizational charts (org charts) in startups and how they can impact product development.
Why is the speaker passionate about org charts?
-The speaker is passionate about org charts because they are one of their pet interests and they have spent a lot of time thinking about them and observing their impact on various startups.
What was the speaker's observation about team structures in early and mid-stage startups?
-The speaker observed very little variance in team structures across early and mid-stage startups, with most teams being small, cross-functional, and covering a narrow scope of their product.
What common structure did the speaker find in many startups?
-The speaker found that many startups followed a structure similar to what was described in a paper by Spotify in 2012, which included terms like squads, tribes, and chapters.
What problem did the speaker identify with the widespread adoption of the Spotify model?
-The problem identified was that many startups adopted the Spotify model without considering whether it was suitable for their specific circumstances, leading to issues such as slower progress, lack of focus, and accumulation of technical and product debt.
What is Conway's Law and how does it relate to team structure?
-Conway's Law states that the structure of a company's product will reflect the structure of its team. If teams are set up in a certain way, the product will likely mirror that structure.
Why did the speaker suggest that startups should resist the urge to make everything symmetrical in their team structure?
-The speaker suggested that startups should resist making everything symmetrical because it can lead to the dilution of focus and resources, which is counterproductive to the main goal of the product.
What is the significance of the 'two-pizza rule' mentioned in the transcript?
-The 'two-pizza rule' is a principle from Amazon that suggests a team should be small enough to be fed with two pizzas, implying that a team should not exceed a certain size to maintain efficiency and communication.
What is the speaker's view on the number of direct reports a manager should have?
-The speaker believes that the number of direct reports a manager should have is not a fixed number like the commonly cited 5 to 8, but should be determined based on the context and needs of the startup.
Why did the speaker suggest that startups should start with a clear understanding of their product shape and then structure their teams accordingly?
-The speaker suggested this approach because it allows startups to make purposeful decisions about team structure that align with their product goals, rather than following generic advice that may not suit their specific situation.
What is the speaker's advice on how to handle teams that are focused on less important or 'table stakes' aspects of the product?
-The speaker advises that the default number of people working on less important aspects should be zero, and only assign team members to these tasks when absolutely necessary, to avoid overbuilding and maintain focus on differentiating features.
Outlines
π The Impact of Org Charts on Startups
The speaker begins by expressing surprise at the audience's interest in org charts, a topic they're passionate about. They recount their experience working with startups across various industries and stages, noting a lack of diversity in team structures. Early and mid-stage startups often default to small, cross-functional teams, a trend they attribute to the influence of a 2012 Spotify paper widely cited in management literature. The speaker criticizes this uniformity, suggesting it leads to slower progress and technical/product debt, and proposes that companies should critically evaluate and tailor their team structures to better align with their unique needs and goals.
π The Dilemma of Team Structure and Focus
This paragraph delves into the disconnect between company leadership's clear objectives and the teams' ability to align with these goals. The speaker discusses how the narrow focus of small teams can lead to confusion and a lack of contribution to broader company goals, referencing Conway's Law to illustrate how team structure influences product development. They argue against the addition of complex systems like OKRs to address this issue, advocating instead for a reevaluation of team structure to ensure it reflects the desired product outcome, and caution against the instinct to create symmetrical, balanced teams that may not serve the product's needs.
π The Challenge of Team Size and Provisioning
The speaker addresses the common misconception about team size, particularly the adherence to the '5 to 8' team member rule, which they trace back to outdated management wisdom and the constraints of the 1980s. They contrast this with modern examples, such as Nvidia's management style, to highlight the need for context-appropriate team structuring. The speaker suggests that startups should consider over-provisioning their main teams to handle user feedback, maintenance, and to manage technical debt, while being cautious about pre-committing to narrow scopes that may not be necessary.
π― The Importance of Team Scoping and Product Focus
The speaker emphasizes the importance of team scoping, suggesting that teams should be given the largest possible scope to make reasonable trade-offs. They warn against the tendency to create narrow scopes that can lead to 'kingdom building' and over-optimization of minor features. The speaker advises startups to start with a broad team scope and only introduce narrow scopes when there's a clear need, avoiding the pre-commitment to structures that may not be beneficial. They also touch on the challenges of morale and development when teams are assigned to less desirable tasks, advocating for a dynamic approach to team composition.
π Conclusion: The Origin and Evolution of Team Structures
In the concluding paragraph, the speaker reflects on the initial stages of startups, where the focus is on shipping the main product aggressively due to limited resources. As companies grow and resources increase, they often seek external advice, which can lead to the adoption of standardized team structures that may not be optimal. The speaker encourages startups to trust their initial intuition, understand what makes their product unique, and let that guide their org chart and team structure decisions, rather than relying solely on conventional wisdom or widely circulated management theories.
Mindmap
Keywords
π‘Org charts
π‘Conway's Law
π‘Cross-functional teams
π‘Spotify model
π‘Squads, Tribes, and Chapters
π‘Technical and product debt
π‘OKRs (Objectives and Key Results)
π‘Over-provisioning
π‘Two-pizza rule
π‘High Output Management
π‘Nvidia
Highlights
Speaker's passion for org charts and their impact on startups.
Observation of little variance in team structures across early and mid-stage startups.
Common team structure influenced by a 2012 paper from Spotify.
Startups implementing team structures without fully understanding their context or suitability.
Problems arising from the adoption of the 'squads and tribes' model, leading to slower progress and technical/product debt.
Importance of aligning team structure with company goals and the product's main focus.
Conway's Law and its implications for product development based on team structure.
Critique of the tendency to create symmetrical org charts without considering the product's needs.
The fallacy of the 'two-pizza rule' and the need to critically assess the context of management advice.
Over-provisioning teams to handle user feedback, maintenance, and iterative development.
The risk of 'kingdom building' when teams are given too narrow a scope.
Strategic team scoping to allow for better trade-offs and less overbuilding.
The challenge of disbanding teams that have fulfilled their purpose.
The benefits of starting with a clear understanding of the product's main differentiator before structuring teams.
The example of Linear's org chart, organized by region with a core product function.
Encouragement for founders to trust their intuition and product understanding when structuring teams.
Final thoughts on the importance of shaping the org chart around the product, not the other way around.
Transcripts
[Music]
I'm very impressed that everyone showed
up to hear a talk about org charts of
all things so uh you know it's one of
the um it's one of my pet uh it's one of
my pet things that I really think about
a lot and hopefully uh you know this is
a subject that you might have uh a more
you know well-developed or stronger
opinion on uh after this talk so I want
to start with a story that's really
rooted my career uh I've spent most of
it building startups at different stages
uh across different Industries I worked
on everything from uh direct consumer
Brands to uh design tools and business
intelligence and now uh developer
productivity and in between my last two
roles
I took some extended time off to uh you
know work with some Founders and and
startups um you know across the bay and
also around the world uh to uh help them
you know solve their problems and for me
this was an opportunity to apply my
experience a little more widely but also
to learn from people um I wanted to see
how uh you know how different people
solved different kinds of problems and
uh came to different solutions and and
really what they took for granted
and when uh when I did this I saw a lot
of variance in things like uh their Tex
Stacks um like you would expect uh in
things like go to market and even in
fundraising strategy uh but something uh
kind of surprised me which was uh there
was very little variance in team
structure uh this is mostly early and
mid-stage startups and when I asked why
uh they chose this um particular uh this
particular structure this is the same
basic setup that I I saw
you know everywhere right you would have
these uh these very small teams that
they would be cross functional and you
know maybe you have a PM on each team um
and they would they would cover a very
narrow scope of their product and when I
asked folks why they chose this setup
the answers were not entirely satisfying
um either this was just the way they
like did it before or they did some
Googling and they or they read some
management books even um and often the
response that I heard was hey we we saw
this paper uh that was written by some
Spotify guys in 2012 and I'm you are
laughing because you've seen this paper
right this paper is everywhere um it's
constantly getting referenced in blog
posts and like content marketing pieces
and those pieces themselves are getting
re-referenced by other things uh so it
just becomes like self-perpetuating in
fact if you ask chat jpt how should I
structure my startups epd team the
answer it will come back with like 50%
of the time it's going to have you know
somewhat unique sounding terms like
squads and tribes and chapters and
guilds these are terminology that is
directly from this paper and the
companies I would work with they would
you know this is what they get back and
they would implement the stuff that
sounded reasonable you know the the more
exotic stuff they would just kind of
ignore and then what they would end up
with right was this uh the structure
that we kept seeing and part of the
reason I'm here with you today is almost
like an SEO thing because I want
companies and and Founders in this
position to have maybe something else
for the for them to reference right not
the same thing over and over again um
hopefully something that's like a little
more applicable to their
circumstance because these companies
they don't look anything like Spotify
right they're not even close in terms of
even Spotify 2012 they're not even close
in terms of scale or trajectory or
culture but especially product but the
information that they found is so widely
available and it's just everywhere so
they found it they followed it and it
kind of got them into a little bit of
trouble and that's where they ended up
calling me um and you don't go out of
your way to do this unless you're having
a lot of difficulty and that's really
hard for you to crack and the difficulty
I kept hearing from these companies was
hey we added a bunch of people then
somehow we got slower right we're moving
more slowly than before um or I can't
get the team to focus on anything we're
just going in so many different
directions at once and on top of this
we're kind of drowning in Technical and
product debt
and uh you know when when people told me
this it was almost with like this sense
of nostalgia or like lost because there
was still institutional memory at these
places of what it felt like to be very
fast and focused and not be drowning in
debt uh but they changed the way they
operated and this is where they ended up
so to help diagnose the the problem you
know we just start by asking simple
questions like well what do you think
right as a leader of the company what do
you think the team ought to focus on and
conversely
if you ask the same question what do
they think they ought to focus on and to
leadership of these companies the answer
in their heads at least was very clear
they gave you know very tight all hands
presentations on like what the next goal
was um and what the next major objective
was and here's the metrics you want to
look at but then as as people would get
back to their desks or off of Zoom you
know depending on your culture um you
know this setup would kind of take what
they just heard and and confuse it or
muddle it or or weaken it
uh because it was often hard to answer
the question how does my little narrow
part of the product surface actually
contribute to the thing we just we just
heard at the All Hands meeting um and
what often would happen is they would
say like well you know I'm going to try
to find some backwards way to contort my
logic to get it to make sense and they
would just end up doing what they were
doing in the first
place what these Founders really
discovered was that if you break up your
team into little bits right and ask them
each to just cover a very narrow scope
uh that's you know pretty much mutually
exclusive from the other teams and then
you you want to like tell them the focus
it's probably it's probably not going to
work because they ran head first into
this thing uh that I'm sure you've heard
of called Conway's
law which you know there's a lot of
words to describe it right but at its
very core what it really says is if you
uh if you have a structure for your team
that's set up in a certain way that the
your product is going to look very
similar to it right this is so
referenced in Silicon Valley that it's
almost like a meme but I still don't I
still don't think we take it seriously
enough because at its core it's really a
Saye you will ship your or chart right
however your team is structured will be
reflected directly into your product so
if you have like five to eight squads
each pursuing a different mandate you're
going to you're not going to ship one
product you're going to ship five to
eight vaguely related products
and this uh you know this is something
that some Founders actually really
recognize they're like oh I see what's
going on thanks for helping me diagnose
um so we're going to we're going to do
this thing we're going to layer on like
okrs or something right we're going to
we're going to add some goal setting uh
layer on top of uh on top of the teams
and hopefully we'll patch things
together that way but the problem now is
that if you're going to add okrs to the
situation now you have to learn how to
calibrate them right then well you got
to have metrics so let's start you know
instrumenting all the things and we got
to hire data analyst to like analyze
what we just collected and what did we
what were we even what were we even
doing in the first place and the the
problem here is that they were trying to
solve a situation that was already too
complex by layering on even more
complexity and uh that was never going
to work so what we ended up doing
instead was kind of taking it back right
where look let's start with Conway's law
and let's really take it seriously and
if you believe like if you truly believe
that you're going to ship your or chart
then make an or chart that you actually
want to ship you can make very very
purposeful decisions not mindless ones
not ones you read on the Internet or you
know you just accept because that's just
what you've seen before you can make
very purposeful decisions on uh how you
want to address the the shape the size
and the scope of all of your development
teams so that you actually do end up
reflecting what you want to
build and uh this is what we're going to
talk about today so we're going to start
with shape and uh if there's one
takeaway of from this that I want you to
have uh it's going to sound a little
stupid is that you have to really resist
this very human urge to like make
everything symmetrical right you know
there's a lot of designers in the room
if you see something that's a little bit
out of place it's not really balanced
I'm just going to fiddle with it until
it is like that is not that is not how
you want to like design your teams and
uh the problem is when you read
management books or papers or block
posts or whatever uh they always show
you charts that look like this right
they're perfectly balanced they're like
binary trees or little pyramids or like
perfect grids or whatever um but this is
not the goal right having pretty looking
charts is not your kpi if the the Ora
chart is a tool that's designed for a
purpose if you take these two tomatoes
one of them is designed to taste good
and the other one is designed to be a
sphere and depending on which one you
choose right you're going to have a
different outcome if you're a startup
and you're trying to hit escape velocity
your product probably has one main thing
and that main thing it better taste good
you might have a couple of supporting
things or some other stuff you really
wish you didn't have to do but if your
or chart looks perfectly symmetrical
like this then that should really make
you suspicious because where's the main
thing right this this is going to spread
your attention everywhere and it's what
happens when we fall in love with
symmetry you start with a shape that
looks really nice and even and then you
force fit your product into that shape
right like if you if you have an even
shape you're saying like look I'm going
to divide my product into even parts
does your product want to be divided
into even parts or does it have one main
thing if you do this Conway's lot takes
over and now the team gets some focus in
they paying equal attention in like five
directions now if you take something
ugly and sort of lopsided looking like
this then hey at least it has a point of
view you can read out what is the main
thing what is the supporting thing and
what do you wish you didn't have to do
and when when you have this situation it
ends up being shaped like ideally like
how your product is actually shaped the
biggest thing to notice here is there's
just a ton of variation in size of these
teams and some teams are going to be
over provisioned right to provide you a
lot of bandwidth and some teams are
under-provisioned you can't have the
teams all be 5 to8 people and in
practice this was quite a sticking point
with uh with teams I worked with because
um they got really stuck on this number
58 they kept hearing it everywhere and
then you know it was just something that
uh they they thought was like a default
and uh again when you ask when you just
ask the follow-up question like well why
like where did you hear this number from
the answers are going to be like either
our favorite Spotify paper or uh there's
some there's a there's a little bit of
wisdom right that we've all heard before
about two pizza box teams right from
from like Amazon and uh and then some
some you know sources had a little bit
more gravitas uh there's this book
called high output management which is
very widely recommended uh in our
industry um I've read that book I'm sure
a lot of you have as well it has a lot
of great insights um and it's considered
a classic for a reason but it was also
written in 1983 when intel was really
ascending and it was like the hottest
chip company in the world um and as a
result it will also assume the
constraints of 1983 Andy Andy Grove the
author he uh advocated for you know uh
very strongly for managers to manage
primarily through one-on-one meetings uh
and if you're going to do that you can't
really have a ton of direct reports so
you know he really recommended 5 to n
direct reports as the as the range and
uh and sometimes we will read books like
this and we're going to follow those
those specific points you know almost
religiously but Andy lived in a very
different communication environment when
he wrote this book right he didn't have
slack or Zoom he had to go to a meeting
it had to be in person or maybe on a
landline or something um there certainly
wasn't like shared documents like Google
Docs or figma or
linear
and what would high output management
look like if was written today right in
2024 and know the hottest ship company
was Nvidia and uh you know the Nvidia
CEO Jensen hang has been talking a lot
about his management style right he's
he's said stuff like uh I have no direct
reports sorry I have no one-on-one
meetings I have 40 direct reports right
different sources will say different
things like 40 or 60 or whatever um this
isn't to say that 40 is the right number
or that eight is the wrong one but
Eight's probably not the ceiling right
all of these numbers they come from uh
like a context and you have to think
about what the context was when people
you know created these ideas what was
the reasoning behind them and then
really try to critically apply them to
your own right you can't just take a
little nugget of wisdom that's a million
miles removed from its original source
and just assume that it's going to work
for you if you're a startup your context
is probably this right there's a very
specific thing that differentiates your
product there are only a few things that
really need to be great and you should
really consider over provisioning these
things you have to have enough people
not just to build the first version but
to also deal with all of the inevitable
user feedback and maintenance and Bug
reports and polish and all this
iterative stuff that we do we're not
shipping CDs anymore so when you do that
you're also going to accumulate a lot of
Technical and product debt and that's
how it happens so over-provisioning your
main thing can also help you pay that
debt back and as a side note like
something that uh people ask us all the
time at linear is like how do we
maintain such a high quality bar um you
know often we get asked by
candidates or or users or something and
a big part of it is this we will
sometimes crank our main teams almost
all the way to full debt payback mode
and we can do this and we can be very
comfortable in the uh in the tradeoff
here because we have enough people where
we can still leave uh you know a few
folks to to carry the change lock
forward right we don't have to like
totally kill our momentum and being
comfortable in this trade-off is
probably one of the biggest uh benefits
of over-provisioning teams is that you
don't have to pre-commit to Really
really narrow Scopes and uh and that's
also one of the effects that you see
when you have this very symmetrical
small team kind of system is that every
team has to really pre-commit to a bunch
of narrow Scopes and these can be
appropriate sometimes or very powerful
when when used correctly but uh if
you're do if you do it like this you're
going to force the teams to just pick
that without really uh knowing if it's
needed or not and what ends up happening
is Naros Scopes create a lot of uh a lot
of Kingdom building right like it has
this like potential because if you take
ambitious people like PMs and designers
and engineers and you put put them in a
little box we're just going to overbuild
it right we're going to we're going to
figure out all the nooks and crannies
and fill every single corner of that box
and then like when you're not looking
secretly make the Box bigger and that
we've all experienced this right like
I'm a PM like we are we are the most
guilty of this uh we'll you know hey
here's our product surface let's find
some little use case that we heard from
One customer let's over optimize the
heck out of it and uh and we do that
only because our scope is so constraint
right we have no other Outlet to to sort
of Feed the
ambition this is a consequence of law
because if the or chart says that hey
your identity and your purpose at this
company is going to be really tied into
this one thing U and your your
performance review is going to know
about it you're probably going to ship
the heck out of the
thing and you can avoid all these
problems in the first place by starting
from the shape of the product that you
want to have and then trying to scope
your teams that way this is very hard to
unwind after it's already happened so
it's really best if you can try to avoid
the problem in the first
place and there's a few ways to do that
the the simplest way
uh is something I'm sure we all do which
is hey let's find some technical or uh
skill set boundary that makes sense and
we can just slice off a team for that
we're all very comfortable with like
separate iOS or Android teams and stuff
um another thing that you can do right
if you have a Naros scope is to set very
very clear limits and conditions for
maybe even disbanding the team sometimes
they they might just be done right it is
perfectly fine to say like hey team
you've fulfilled your purpose you can
just you know you don't need to exist
anymore that's fine um and if you're
going to you know let a team be
relatively unbounded and you know decide
that hey overbuilding is okay this is
probably most applicable in more sort of
like creative areas uh go into it
knowing that right just assume that it's
going to happen and if you can leverage
that and make that into a benefit for
your uh for your product and for your
business like that's fine too um but the
question I would really start with
before any of
this is what is the largest scope that
you can give to a team and have them
make reasonable tradeoffs right it might
start by covering all or most of the
products Al together and uh once you
start there you can start slicing off
narrow Scopes as you really demonstrate
a need for them right you don't have to
you can do it one at a time over a long
period of time you don't have to just
say like hey today we're one giant team
and tomorrow we're going to split it all
up right because doing that will
pre-commit you to a whole bunch of stuff
that you don't even know if you need yet
and causes really weird effects and one
of the weird effects I'm sure you've all
seen is you have like a team that's uh
dedicated to stuff you'd rather not do
right whatever you want to call them you
give a euphemistic name like the the
platform team or something like that
like whatever it is that you call it and
um and what ends up happening is uh one
it's not really great for morale like
everyone knows that this is the stuff we
don't want to do it's like table Stakes
it's not differentiating it's not really
important to our product um but also
we're just really tempted to just shove
all the junior developers onto that team
and just say like oh yeah go go go play
here you're not going to do it do much
damage and uh and that's it's not great
for their development they don't get to
work on anything important
um instead right really consider that
the default number of people that works
on that'sit not important should be zero
and then when other teams need to make a
tradeoff to say like hey we absolutely
need to do this we have to kind of put
down our main thing and do this okay
great like that's that's a good forcing
function to really understand what you
the minimum that you need to do uh this
is an area where you definitely do not
want to be
overbuilding so uh the purpose
ultimately right of scoping teams is to
really let the let the team members make
good tradeoffs on the ground giving them
an adequate size lets you deliver on the
quality promise that your customers want
and uh the overall shape of your team
hopefully results in something that is
actually shaped like how you want your
product to
look everything else right everything
else all these other considerations of
making good-looking or charts or having
equally sized teams or picking a single
Dimension that every team has to be
split on all of this stuff is in service
of symmetry and it's basically a false
constraint you don't need to do it and
uh I'm going to show you an example
right so for us at linear this is what
our this is what our or chart looks like
and the main organizing function is
actually by region it's not even by
product surface um but there is a core
product function that slices across both
regions and it accounts for over 50% of
our staff we have narrow teams sliced
out for uh for the mobile apps for uh
the website and for infra um and if you
add our managers and the reporting lines
into here it starts to look like a
really densely woven blob um this is
never going to look good on the
two-dimensional chart it's not a
two-dimensional problem it's not a two
dimensional solution it's not a two
dimensional outcome uh this is just what
our product looks like right and it's
it's great for our customers what they
experience is a network of very
intricately uh related features and a
very rapidly developing mobile app on
the side this may or may not be the
right configuration for your team at
your company but almost certainly
neither is this all of our products they
look very different from each other
we're going to require very different
looking organizations to support them
and I'll conclude with this and I want
to bring it really back to the original
motivation for this right because the
companies that I met with during my time
Consulting they started off not knowing
what they were supposed to do or
supposed to look like all they could do
is decide what the main thing was focus
on shipping it and just do it
aggressively because that's the only
choice they had and that got them to a
pretty good place right they found
traction they raised money they hired
people and then they got really nervous
cuz all of a sudden they have a whole
bunch of resources they didn't have
before so they like asked Google what
should we
do and what I hope that we you know the
stuff that we talked about today I hope
that it gives them a little point of
light and really the the confidence to
follow the same intuition that got them
there in the first place which is to
start from your product really
understand what makes you different lean
into that and then everything else
including your orc chart can follow from
there thank you very much
[Music]
Browse More Related Video
![](https://i.ytimg.com/vi/_Iv7TrhqvWM/hq720.jpg)
29 Minutes of the BEST Alex Hormozi Sales Tips
![](https://i.ytimg.com/vi/0LNQxT9LvM0/hq720.jpg)
David Rusenko - How To Find Product Market Fit
![](https://i.ytimg.com/vi/xYW2CEnMnwo/hq720.jpg)
Communication asynchrone en tΓ©lΓ©travail avec Christophe Pasquier
![](https://i.ytimg.com/vi/w0sjtlTHgc4/hq720.jpg)
My Product Strategy Model - An Introduction
![](https://i.ytimg.com/vi/a_W5Rn0bJWE/hq720.jpg)
The happiness and pain of product management | Noam Lovinsky (Grammarly, FB, Thumbtack, YT)
![](https://i.ytimg.com/vi/Qdplq4cj76I/hqdefault.jpg?sqp=-oaymwEXCJADEOABSFryq4qpAwkIARUAAIhCGAE=&rs=AOn4CLBuSR9NgP4lOD-ru9OC833kJdmHtw)
Steve Jobs : Great idea doesn't always translates into great product
5.0 / 5 (0 votes)