Here’s a basic (but overlooked) aspect of how product teams work ... and that is how they scope missions.
Say you scope your work in missions of 1-3 months ... (1/n)
That gives you enough time, as a team, to truly “start together” ... do research together, everyone get involved, etc ... and still have plenty of time to “do work”.
But ... (2/n)
Say teams typically scope/shape work in the 1-3w range.
Well of course that is going to require upfront research, handoffs, and “landing” the work on a team. 1-3d is simply too short for a meaningful “start together” type approach.
So...(3/n)
If you want outcome-focused work that inspires teams, and leaves room for actually discovering things together — instead of leaving the team out of the activities — you’ll need to think in the 1-3 month or 1-3 quarter range.
(4/end)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Way back I worked in a PPT factory at an investment bank. Our job was to assemble “decks” for investment bankers. The operation ran 24hrs a day with dozens of “operators”.
Young bankers would work CRAZY hours.
Reflecting (1/n)
...though it involved tons of specialized work, (the bankers) work was primarily research, models, content, etc. Their job was to deliver the M&A doc, the roadshow, etc. Our/my job was to assemble.
Some slides too up to an hour (2pt font, 200 logos, 20 footnotes, charts) ..(2/n)
...other slides took 5 minutes. And with some experience you could — as an operator or a manager, which I did both of — estimate how long a deck would take. 120 slides? 60hrs.
Why? How? Repetition. Repetition. Repetition. And low complexity.
You have to build a sense for when you are juggling too many dependencies, too much coupling, too many drivers, not enough floats. A self-inflicted wicked problem.
The trouble is that this is hard to teach/learn....
(2/n)
...when you haven’t seen enough things go wrong.
It is natural to be over confident that you can somehow thread the needle, and brute force the optimization problem. If you adjust the levers just right, things will work!
Do this enough times, and fail, and you...
(3/n)
...build the ability to sense the warning signs. The instinct.
But you need to be in the thick of it. Observing — from a distance — a team in the throes, and you are liable to believe that the levers could have been moved just so.
...and I realized what was making me uncomfortable.
Most teams -- even with the best intentions -- don't create an environment where...
1/6: people with diverse perspectives are actually in the room
2/6: people have time to actually process the decision, the data, the context, the implications, etc.
3/6: safety exists to challenge the fundamental underpinnings of the decision and/or "problem" and or question
4/6: multiple promising options are explored. The "decision" is basically "should we do X", which is a decision, yes, but it isn't a choice between options.
5/n: the actual commitment is understood! Which ties in to some of the items above.
"How do I get the developers on my team to take more of an interest in outcomes and our customers?" PdM
This is an interesting one. When developers seem disinterested, it is often for a couple reasons.
1/n: They are overwhelmed with an output-based incentive structure...
...so even if they do care, there is a lot of pressure from their department to "just write code" and "finish projects".
2/n: When there is a ton of debt, getting *anything* done can be a challenge, and this occupies 95% of their emotional/mental energy
Sometimes...
3/n: They used to care -- maybe at a prior job -- but got told to stay in their lane. They asked a question, got shot down. Their product manager didn't share context and/or engage them in the problem. So they mentally shut down on getting involved. Too many hassles.
1/10: Coworkers may be very concerned and supportive in private, but that doesn't mean they can (or will) take risks publicly. And you need to be OK with this.
Take strength from their private support, but realize they may not be able to help.
2/10: People like to solve their own problems! We all do. So when someone (you) comes around and says "oh that's easy, do this!" that may be welcome...or may be unwelcome.
Try not to steal their joy of figuring it out. Harness that!
(PS: maybe you'll learn from them)
3/10: Change is always happening. It just might not be change you like (or how it to happen). This is important because by observing how change does actually happen, we can fine-tune our approach (and it tells us what the system values)