"The engineers on my team just want to code. They don't want to have anything to do with product. They just want specs. What do I do?"
1/n Are you asking them do to X *and* do their "day job" as defined by their managers (and frankly your roadmap) ?
If so, start there...
2/n Do they have a reason to believe that doing X will in any way improve the quality of the product and make their lives easier? Have they ever seen X "work" ?
Show don't tell.
3/n Is there average day/week a quagmire of unnecessary meetings, wading through tech debt, struggling to get *anything* to work ... and jumping through process hoops to prove their worth?
If so...no they will not have bandwidth.
4/n How do incentives work on the engineering team? Maybe they want to help, but their "grade" is determined by something altogether different.
"I'd love to, but I am on the hook to deliver [some project] this quarter to make a good impression..."
Talk to eng management.
5/n Have they had any time to practice?
Or did they get thrown into the deep end the first time they were given a shot ... expected to brainstorm on demand, be as vocal as practiced PdMs and designers, and "participate" !
Make it safe to practice. Reasonable expectations.
6/n In the past, did they experience an executive crapping on everyone's ideas, and treating them badly? You'd be amazed how often this happens. A non-team-member pulls the brakes 20m in and says "ok, so WTF are we doing here?!"
7/n Say they've tried, and quit. "No more discovery meetings! Just tell us what to build!"
This is likely because they attended, but didn't feel like they added value or were able to shape the direction.
8/n They feel overwhelmed.
This is were an experienced lead modeling how to participate can really help (cc @GergelyOrosz ). They may have no role models on how this can be healthy or go down well. Just performative kickoffs that are all slides and orders, no conversation.
9/n finally....don't expect and engineer to immediately open up about their hesitations. Like anyone, they probably don't want conflict. This is where building relationships as a co-team member and eliminating the awkward PM/team power dynamic really helps.
Have a conversation.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I think ppl look at [popular tech co] product management advice and think "oh goodness...the rigor!"
...when in fact it is really about the intentional reduction in process overhead and leaner governance/budgeting
... this is especially important for bigcos believing they "don't have the 'talent'" to operate like X
...when in fact they don't have an environment where talent can flourish like X. They have trouble letting go.
... part of this is pure $.
They might be a money printing machine, but highly highly risk averse.
They talk about "innovation" but it is in the context of a massive amount of inertia to shave off %pts in cost and a very shallow excel-drag-to-right revenue forecast
I'm going crazy trying to explain this seemingly basic concept, but striking out. Any ideas appreciated!
At the day job (@Amplitude_HQ) I meet teams who imagine the following...that there is a linear relationship between analytics instrumentation "work" and insights ... (1/n)
Meanwhile - the teams that are actually doing the work (and integrating it into day-to-day product work), see something that looks more like this...
A quick pass at instrumentation unlocks a lot of valuable insights. Integrating it into day-to-day work unlocks even more (2/n)
Can't put my finger on the why
With a self-service analytics product, it is 1) easy to add new events, props, etc. and 2) you have a whole variety of insight variations.
With just 2 events, 5 props each, and a handful of user properties you can answer LOTS of questions (3/n)
How should product managers and designers share certain responsibilities?
wrong answers only.
Pm: I pick the right things. You build them right ...
Pm: oh hey for that work we’ve been talking about that is five months out ... do you mind just whipping up some mocks? Nothing serious. Promise. Will not hold you to them.
I frequently encounter leaders who believe their team(s) aren’t “ready” for taking a more outcome focused approach. They talk of “baby steps” and “learning how to crawl before...”.
Here’s what they are missing
... to learn something, it is important to practice the thing (1/n)
You don’t learn this by running a (or working in a) feature factory, cranking out the stuff sprint by sprint.
You learn by doing a version — albeit probably more controlled/structured — of the thing ... (2/n)
What might that involve?
- direct contact w/customers
- some ability to “sense” outcomes qualitatively/quantitatively
- a feedback loop
I've meet execs who swear "we can't do X because we can't hire engineers like [big tech co]". Are they right?
and others who say ... "all you need is psychological safety and empowerment and ppl will figure it out"
hmm (1/n)
... I'm reminded of an environment that had an extremely strong foundation of quality (and safety, and empowerment). And exp. leaders.
In that env, a new grad would take 2-4y to really start figuring out the product thing. AND...would start contributing quickly.
and.. (2/n)
... another env with very talented/experienced folks all with 10+y experience, being mired in complete insanity. Things falling apart. Bureaucracy. Toxic company politics. It was terrible. Many people left. Some people stayed in a Sisyphean effort to fix the org.