In my 20s:
I was sure other people knew the answer.

In my 30s:
I was sure I knew the answer.

In my 40s:
I try not to be so sure about such things.
If you enjoyed this tweet, you might also enjoy these threads👇🏾
What I learned in my 30s about living a peaceful life, through setbacks, reading, and introspection
My personal heuristic for success

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Shreyas Doshi

Shreyas Doshi Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @shreyas

17 Oct
PM feedback framework:

Skills—to build/enhance (level-specific)

Mindset—for ⬆️effectiveness (agency, even keel..)

Activities—to improve product/team (better process, horizontals..)

Results—expected Outputs+Outcomes

Training—resources to achieve all this

Review plan monthly.
Product Manager feedback tends to be unstructured & is often not easily actionable.

This had bugged me for years, until I starting applying this framework a few years ago.
Structuring feedback in these 5 categories forces more specificity & action-orientation.

It's a joint plan in which the manager is equally accountable.

How to start?

Managers: write up to 3 prioritized points per category

All others: share this framework with your manager🙂
Read 5 tweets
15 Oct
Most Execution problems are really
1) Strategy problems, or
2) Interpersonal problems, or
3) Culture problems

Good leaders execute well because they understand this. They fix the root problem.

Bad leaders struggle because they are always applying band-aids.
Of course, at times it is a real Execution problem.

Real Execution problems include:
A) Funding constraints
B) Team skill gaps
C) Tool issues
D) Org structure
E) Process problems
F) External dependencies
G) Technical complexity
H) Coordination complexity
In the majority of cases though, what is initially expressed as an Execution problem isn't an Execution problem at all.

It's more convenient to point a finger at these Execution problems when the root cause is actually a Strategy / Interpersonal / Culture problem.
Read 17 tweets
12 Oct
The day you became a clearer thinker, you:

-started by identifying the real goal
-decomposed vague concepts
-framed the right questions
-sought more data or experience
-listened to multiple perspectives
-assessed upsides & downsides
-examined your own biases
-acted like an owner
Related resources👇🏾
Read 24 tweets
11 Oct
2 approaches for professional growth:

A) Goal-driven: What do I need to learn to immediately solve this concrete problem?

B) Interest-driven: What can I learn about this domain that I don’t already know?

To excel in the long haul:
Make B your default & use A when necessary

An observation:
Majority of people tend solely toward Goal-driven growth.

They don't seek to learn things without a clear & immediate problem.

They don't make this choice explicitly.

It's just how they are pre-wired.

The trick then is to:
1) recognize this
2) re-wire oneself

Growth isn’t a straight line.

It isn’t fully Cause & Effect

The brain makes connections in ways you can’t predict upfront.

You can’t plan proficiency.

So get comfortable with learning without an immediate problem or purpose.

And grow in ways you never thought possible.
Read 5 tweets
10 Oct
I’m late to the party, but this recent Founders Field Guide episode with @rahulvohra is a masterclass for product folks

Most folks can learn more from this one episode than several years of building products, reading 10+ books, etc.

I’ve listened to it twice & will listen again
The frameworks & examples shared by @rahulvohra are superb

But perhaps even more important is the product philosophy: deeply understanding user motivations & psychology, and conceiving creative product solutions rather than the “safe” ones

I cannot stress how important this is.
Apple podcasts link:…

Spotify link:…

If you want to check out the content right away,
@chrishlad has created a nice thread summarizing this episode (but don't forget to also listen to the episode):
Read 4 tweets
9 Oct
All else being equal, it’s often more prudent to prefer teams that tend to Over-Promise & Under-Deliver (OPUD) rather than teams that consistently Under-Promise & Over-Deliver (UPOD)

What I’ve observed in practice, within talented organizations:

OPUD teams tend to be ambitious for the user & the company. They aim high & might miss at times as a result.

UPOD teams tend to be ambitious for self first. They care more about survival & perception management.
"Over-Promise & Under-Deliver" teams might miss some of their promises, but they still usually end up with greater net productivity & impact than "Under-Promise & Over-Deliver" teams.
Read 7 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!