@johncutlefish's Threads
10 added
So here's a little prod dev lesson ...
1/14 At any given time, you'll have all levels of work in this diagram (A-I) happening simultaneously. All connected. The connections may be implicit...or obstructed and/or opaque or flimsy...but they're there.
@Amplitude_HQ #prodmgmt
1/14 At any given time, you'll have all levels of work in this diagram (A-I) happening simultaneously. All connected. The connections may be implicit...or obstructed and/or opaque or flimsy...but they're there.
@Amplitude_HQ #prodmgmt
2. Who tackles what varies. Take this example from an organization. You can see it is a spectrum. The types of missions we tackle vary.
A team might start with "G" to figure stuff out, but once they've gotten their groove, focus much more on C and D.
Try mapping your work!
A team might start with "G" to figure stuff out, but once they've gotten their groove, focus much more on C and D.
Try mapping your work!
3. There's another way to think about this using time.
When we walk into work we engage in little 1-3hr tasks. Say I ask you to "walk the tree" between your 1-3hr task all the way up to a 1-3year or decade mission. How would that play out?
When we walk into work we engage in little 1-3hr tasks. Say I ask you to "walk the tree" between your 1-3hr task all the way up to a 1-3year or decade mission. How would that play out?
Please help me promote the inclusion program (free entry) for our product conference. This is very important to our team.
Oct 8th, SF-Amplify
amplify.amplitude.com/inclusion
I'll give away 10 tickets at random to ppl who RT. You can use the ticket yourself, or gift it to someone else
Oct 8th, SF-Amplify
amplify.amplitude.com/inclusion
I'll give away 10 tickets at random to ppl who RT. You can use the ticket yourself, or gift it to someone else
I'll pick folks at 150rts, or Saturday 12 noon pacific (US)...whichever comes first.
And obviously, no purchase is necessary to participate
1/8 When I unpack "the work" with teams, we invariably see *many* "shapes" of work. 15+ typically. There's absolutely no way a single process/workflow will work in all cases. You might get lucky to have four broad buckets, but still...
Excuse lame gifs.
Excuse lame gifs.
2/8 One of the central questions here is what "team" means in your context. To @cagan's post earlier this month, are you working on actual product team. Or is this "delivery team" or "feature team". The differences are very important and worthy of a discussion.
3/8 Without answering this question, you'll just go in circles. If indeed your organizations perceives engineers as "delivery" people, and designers as "make it ready for engineers to deliver" people, and product as "design this"...then you've already answered your questions
visualizing "the work" at the program/portfolio level is one the single most powerful things a team can do to collectively improve how they work
the fascinating thing is the resistance (1/9)
#kanban #agile #programmanagement #visualization
Board Credit: @keithadam @Optimizely
the fascinating thing is the resistance (1/9)
#kanban #agile #programmanagement #visualization
Board Credit: @keithadam @Optimizely
2/9 Power and ambiguity. For some...power is maintained through opacity and ambiguity. Making work visible and/or making ambiguity visible is a direct threat to that way of trying to control a situation.
3/9 With visibility, there is the constant threat of micro-management. Flying under the radar is sometimes the only way to "get stuff done without people meddling. If everyone saw our roadmap, they'd keep poking holes in it!"
keep seeing this emerging pattern of developers and designers forming coalitions of discontent re: product management. There's a message here. Trying to figure it out. Didn't feel like this 5-8 years ago.
it could be that as boundaries blur, there's simply more questioning? more visibility? more awareness?
the "problem" has shifted from collaborating together (developer/designer) to actual impact?
the "problem" has shifted from collaborating together (developer/designer) to actual impact?
maybe we increasing the burden/expectations on PdMs to such levels that there's no way anyway be that STRONG PRODUCT LEADER that everyone seems to want, but not want
Great coffee chat with designer friend.
“The most humbling moment of the last year was realizing that as a designer I currently only influence a small % of the decisions that actually impact our products & services”
He drew this out on a napkin.... (1/3)
“The most humbling moment of the last year was realizing that as a designer I currently only influence a small % of the decisions that actually impact our products & services”
He drew this out on a napkin.... (1/3)
...”My first instinct was to kind of retract and build a wall. I was seriously depressed though. Did I train so hard to only influence a tiny part of the overall outcome?. So I considered my options — try to control more and/or directly influence more.” (2/3)
”Controlling more could only go so far. I know. I tried. What am I going to do, camp out in legal all day. The traffic cop for all ethics decisions?
So I worked on influencing more. I saw this as my new mission, and that was hard because it wasn’t what I had trained for.” (3/3)
So I worked on influencing more. I saw this as my new mission, and that was hard because it wasn’t what I had trained for.” (3/3)
I've seen so many variations of functional/healthy/happy product teams, that I am very hesitant to make any sweeping statements about structure.
Somewhat related ... I get worried when I hear sweeping statements about “human nature” and teams/structures, etc. Even in single individuals at work you start to see many “sides” of people.
Take something like @swardley's "doctrine" ... consider how many structures/forms/roles/responsibilities/hats might fit within these general guidelines. Or styles of leadership/ownership. Or...dare one say..."cultures"
10 #PMTips
1) It is not about your ideas. Create a framework/model that elicits and prioritizes the most promising ideas
2) Bring customers/users to the team vs. being a proxy
3) Don’t slip into being a scrum master/project manager. It will hurt you and the team
1) It is not about your ideas. Create a framework/model that elicits and prioritizes the most promising ideas
2) Bring customers/users to the team vs. being a proxy
3) Don’t slip into being a scrum master/project manager. It will hurt you and the team
4) Ask how you can improve the teams decision velocity and decision quality (instead of falling into sole decision maker mode)
5) Make sure anyone on the team can trace their daily tasks through to the 1-3 year bets of the company (without glossing over uncertainty)
5) Make sure anyone on the team can trace their daily tasks through to the 1-3 year bets of the company (without glossing over uncertainty)
6) You do not manage the team (repeat 10x). The team is not your “resource” to optimize. You are a team member.
7) Become an expert at experiment design and understanding the impact of the team’s work. Real outcomes are the ultimate motivator
7) Become an expert at experiment design and understanding the impact of the team’s work. Real outcomes are the ultimate motivator
“Our process is broken!” “We need to FIX role definition!” “We need to figure out the role of product vs. design!”
Quick exercise...
1. Ask the team to blurt out “work” from the last six months. It can help to use a super simple X and Y axis (like Size and Complexity)
Quick exercise...
1. Ask the team to blurt out “work” from the last six months. It can help to use a super simple X and Y axis (like Size and Complexity)
2. You’ll quickly notice two things.
A) a lot of the work is related. Small things link to bigger things
B) there’s disagreement about some items.
Note these things.
A) a lot of the work is related. Small things link to bigger things
B) there’s disagreement about some items.
Note these things.
3. Group work that feels similar. Resist the temptation to overthink this. Have a conversation about why the work feels similar. Most teams end up with 15+ “shapes” or work.
E.g.
“Totally new product, new persona, unknown tech, dependencies across company”
“P0 Prod Issue”
E.g.
“Totally new product, new persona, unknown tech, dependencies across company”
“P0 Prod Issue”
Sorry to do this, but I have to figure this out once and for all, and the only way is to actually tweet it.
Tweet 1
... right before I use the (+) button which I expect will add an empty tweet.
Tweet 1
... right before I use the (+) button which I expect will add an empty tweet.
...ok, I have used the (+) button.
We are in tweet 2 -- I am pretty sure. Now I am going to click on "Tweet all" and see what happens. I am 99% confident this will work as a thread (making this tweet 1.2)
We are in tweet 2 -- I am pretty sure. Now I am going to click on "Tweet all" and see what happens. I am 99% confident this will work as a thread (making this tweet 1.2)
So now I am going to try this and see what happens. How did I get here? I clicked on "Add Another Tweet".
This is where things get dicey. Does this become a child tweet to 1.2 ? Or does it become a child tweet to 1.2's parent (Tweet 1)
We will see.
This is where things get dicey. Does this become a child tweet to 1.2 ? Or does it become a child tweet to 1.2's parent (Tweet 1)
We will see.
hurry hurry ... create small teams
(meanwhile, teams are highly dependent on each other, #design and #PdM, #testing, #ops shared and maxed out)
"why isn't this working?"
(meanwhile, teams are highly dependent on each other, #design and #PdM, #testing, #ops shared and maxed out)
"why isn't this working?"
...."I know why! We need project portfolio management. It is a planning problem. And another layer of human load balancers!"
(meanwhile, kingdoms grows, dependencies obscured, people 'deal')
"this is a low accountability environment!"
(meanwhile, kingdoms grows, dependencies obscured, people 'deal')
"this is a low accountability environment!"
..."We've got to fix this. OKRs! Fix the managers. Even BETTER quarter packing and tetris"
(meanwhile, passionate problems solvers are leaving, burnt out, sad, and hardened souls with the right incentives are digging in for the long haul)
"we have to figure out how to innovate"
(meanwhile, passionate problems solvers are leaving, burnt out, sad, and hardened souls with the right incentives are digging in for the long haul)
"we have to figure out how to innovate"
Are the product managers in your org generalists, experts, or T-shaped? I see this discussed frequently for developers, but not as much for PdM.
Image from @jchyip (medium.com/@jchyip/why-t-…)
Image from @jchyip (medium.com/@jchyip/why-t-…)
@jchyip One observation ... PdM's are often "forced generalists". They may be more T or | (or desire to be), but the role as defined involves *everything*
0/12- So... you feel devalued at work. That your work (craft, perspective) isn't appreciated. You feel diminished and pushed to the side. I've been there. It can be paralyzing.
What can help? #design #ux #prodmgmt #testing
What can help? #design #ux #prodmgmt #testing
1/12- Empathy... all of your coworkers probably feel, to some degree, that their work is not fully valued and understood. Only one of your coworkers actually has *lots* of power...the CEO, and even she reports to a board.
2/12- Realize that often efforts to "get a seat at the table" without closer collaboration actually makes the problem worse. We all imagine we will be *more responsible* once we get "power". And then realize we were solving the wrong problem.
(1/11) So you want to fix something in your company?
You're not happy, and want something to change? Here is a quick thread describing advice I was given once, and ignored. And paid the price. And now I give it to others.
You're not happy, and want something to change? Here is a quick thread describing advice I was given once, and ignored. And paid the price. And now I give it to others.
(2/11) Keep in mind the sad, sad fact that folks stuck in a system -- even when they know how to fix it, and have been preaching change for a long time -- are often too bitter and disillusioned to influence change. You have to avoid that. Don't let things fester that long.
(3/11) It is helpful to not get associated with a particular idea or method or solution. You'll be immediately put in a box. If you're going to advocate for something, advocate for building the continuous improvement muscle. Who doesn't want to make things a bit better each day?
Some virtual scribbles from an @Amplitude_HQ session today on OKRs, North Stars, etc.
First, we need to make a distinction between things that say relatively stable, and things that change more often...like every quarter. (1/8)
First, we need to make a distinction between things that say relatively stable, and things that change more often...like every quarter. (1/8)
A great product strategy creates the foundation for long-term success. It is customer lifetime value focused... not chasing short-term revenue, silver bullets, and success theater
A great product strategy hopefully stays more stable. It persists (2/8)
A great product strategy hopefully stays more stable. It persists (2/8)
Put another way ... in #1 below we chase short term revenue, but fail to build a sustainable, meaningful biz. In #2, we might focus on happy customers, which we believe will lead to long term success (3/8)
I was speaking with an executive with 20+ years of experience recently. And I asked them if they had ever seen a feature/effort “flop”. And they said No. And I found this very curious. So I dug... (1/6) #design #prodmgmt #agile #devops
The reality is that you need a high focus on technical craft (and viewing feedback mechanisms as a top priority) to be able to actually focus on impact over deliverables.
It’s not a switch. And it’s not (always) a philosophical / “mindset” thing. It’s really hard.
It’s not a switch. And it’s not (always) a philosophical / “mindset” thing. It’s really hard.
As someone who has rattled on about feature factories and outcomes over output, I’ve come to see it as much more nuanced over the years.
For many orgs, a “functional” feature factory is what their current limitations will enable. It’s the best they can do.
For many orgs, a “functional” feature factory is what their current limitations will enable. It’s the best they can do.
A feedback loop requires sense AND respond... inputs outputs outcomes and benefits.
It’s the coherence and connectivity that matters. And learning cadence.
It’s the coherence and connectivity that matters. And learning cadence.
Many orgs stressing about estimates are used to 1) no incremental value creation/learning, and 2) huge batches of work (3+ months)
compare that to teams that think in terms of days/weeks, and very rapid feedback loops.
Your approach will be different
compare that to teams that think in terms of days/weeks, and very rapid feedback loops.
Your approach will be different
this is also why I'm not sure the NE hashtag really moves the conversation forward, because it doesn't cut to the crux.
this actually has very little to do with estimation, and everything to do with feedback loops, batch size, learning, and opportunity vs. intervention
this actually has very little to do with estimation, and everything to do with feedback loops, batch size, learning, and opportunity vs. intervention
this is why there are times a team can get by with only two buckets:
Very valuable -- amenable to iteration/experimentation
Medium value+ -- and guaranteed very small
yes, that involves estimation. But again, it is playing a different game.
Very valuable -- amenable to iteration/experimentation
Medium value+ -- and guaranteed very small
yes, that involves estimation. But again, it is playing a different game.
Three factors are having a big impact on #prodmgmt
1- engineers and #ux working together as teammates
2- #ux doing much more than pixel pushing
3- teams having direct access to customers and users (and data about how users use the product)
Here’s why...(1/6)
1- engineers and #ux working together as teammates
2- #ux doing much more than pixel pushing
3- teams having direct access to customers and users (and data about how users use the product)
Here’s why...(1/6)
Many engineers never interact directly with customers/users. Never. Not for lack of interesting, but for lack of opportunities.
And they never see firsthand how #ux does qualitative research. Doing so creates newfound professional respect between eng and #ux (2/6)
And they never see firsthand how #ux does qualitative research. Doing so creates newfound professional respect between eng and #ux (2/6)
Many eng have never worked with #ux who is embedded on their team. Why is this important?
A lot of “tossing stuff to build over the fence” is just a byproduct of being spread too thin. Getting upstream is your only option.
When embedded, you can work in different ways (3/6)
A lot of “tossing stuff to build over the fence” is just a byproduct of being spread too thin. Getting upstream is your only option.
When embedded, you can work in different ways (3/6)
I'm still can't believe how much @joshuajames and I covered in this interview.
This is a treasure-trove of wisdom for folks involved in #proddev, #prodmgmt, #orgdesign, #agile etc. We covered so much, here's a summary:
0:00 Access to data. Features factories. Executing “to plan”
This is a treasure-trove of wisdom for folks involved in #proddev, #prodmgmt, #orgdesign, #agile etc. We covered so much, here's a summary:
0:00 Access to data. Features factories. Executing “to plan”
1:55 Different types of silos: run vs. change, opex vs. capex, service vs. sales. Optimizing the top of the funnel. Juicing TOFU. Quarter to quarter thinking vs. LTV. @joshuajames
4:54 Conway’s Law, portfolios, and placing bets. Increasing revenue vs. protecting revenue (until there's a financial crisis, which turns your focus to reducing costs). @joshuajames
What I find most interesting about this book ... is that it almost perfectly represents what a team designing (and naming) its way of working looks like.
It draws from many, many traditions. Very little is individually “new”, but it is uniquely @basecamp @jasonfried and team.
It draws from many, many traditions. Very little is individually “new”, but it is uniquely @basecamp @jasonfried and team.
I am guessing some people will read @jasonfried’s tweet and say “YEAH. Stickies suck. So does Agile. Yeah, no roadmaps!”
...but that is kind of missing the point. The point is the thoughtfulness, not copy-pasting, and having a point of view.
...but that is kind of missing the point. The point is the thoughtfulness, not copy-pasting, and having a point of view.
What is also fascinating, is how I have observed multiple teams — from very different contexts — evolve similar practices in high trust environments. Primarily because they are given the freedom to evolve their practices and experiment!
It can be helpful to think of prioritization at three levels
1. core beliefs, models, perspectives
2. where we focus, the leverage points
3. how we intervene
Obviously, these are all related. A mistake ... (1/6)
1. core beliefs, models, perspectives
2. where we focus, the leverage points
3. how we intervene
Obviously, these are all related. A mistake ... (1/6)
...is to only focus the prior discussion at #3, and obscure the other bets/beliefs underpinning #1 and #2. With...
#1 - we are betting on what we understand
#2 - betting on the leverage points we identify and target
#3 - betting on how we intervene
It all matters... (2/6)
#1 - we are betting on what we understand
#2 - betting on the leverage points we identify and target
#3 - betting on how we intervene
It all matters... (2/6)
Using something like North Star Framework (your standard OMTM and inputs), we can codify many of the beliefs underpinning #1 and #2.
Which does a great job of setting teams up to prioritize "Level 2 Bets" (3/6)
Which does a great job of setting teams up to prioritize "Level 2 Bets" (3/6)
Common pattern
1/8 - An organization has many "product teams", but the teams lack autonomy, the work is riddled with cross-team dependencies, and the teams share team members (e.g. product, design, data science, and ops).
1/8 - An organization has many "product teams", but the teams lack autonomy, the work is riddled with cross-team dependencies, and the teams share team members (e.g. product, design, data science, and ops).
2/8 - Rewind, and you often find a well-meaning attempt to support small teams...and a manager who was having difficulty reigning in the mess, and wanted to have a smaller # of ppl report to them. "We just can't have meetings this big!"
3/8 - The org optimizes around this new structure. Ppl are hired to support and manage it. Team members are hired to join X team. You start to see team-level roadmaps/backlogs.
Now, small teams ARE good, the are, but...
Now, small teams ARE good, the are, but...
My guess is that most novel / new / emergent ways of working will almost by definition have no “proof” to back them up. That comes later when the late majority needs justification.
A byproduct of this is a ton of trial and error and learning the edges and limits... where and how context matters
It’s for this reason that the rigor is really in your team’s approach to trying new things, not the things themselves.
