Yes. Pros: The ability to influence the roadmap to move the needle faster, ability to explain costs before people commit to anything. Cons: Everyone thinks their ideas are magical and they rarely are. People optimize for their own points of pain. Coming up with a framework of how to judge/pick features is the hard part.

I was speaking with a PM at Amazon last night. His hypothesis was that often engineers don’t get involved in doing discovery and making these type of decisions because of cost reasons. Companies decide that their time is better spent developing. But, apparently for a few full funded initiatives, this isn’t a concern.

Wow great response to my sarcasm. I think the answer is people want to feel like they could be included in the discussion for what to build next, and want to have a say on what they work on. But not every engineer wants to think about the business or user context, some want to be able to just focus on and choose to work on the technical problems.

So I think people want to be invited to participate, and some will want to participate but others won’t be interested.

I love brainstorming as much as I love doing the actual work after that. Brainstorming helps me know the bigger picture, where it's coming from, who are my end customers, what's the goal, soft and hard timelines, challenges etc.

While all these do not assist in the actual work, they certainly assist in replicating work from one project to the other, preparing and presenting final results, and assessing overall impact.

Downside is if those meetings are frequent, it blocks my calendar. Also, sometimes those discussions are very random more like shooting in the dark. I like then to be crisp and quick.

Good questions there. I bet you are a good PM who is working on better collaboration with the team. Not many people do this do kudos to you.

1. I personally like PMs to be somewhat technical. The PM I work with is super good from both a business and technical perspective, and i can vouch that makes things so much smoother. Example, usually business people don't understand data nuances, how much time a piece of code takes to write, etc. Being technical helps estimate timelines better and also rule out ideas that are feasible from a business standpoint but not from a technical standpoint.

2. When I mentioned about the vague point, I meant things far too off from the technical aspect when there are technical people in the meeting. Just like PMs don't need to invited to every code review meeting, similarly engineers don't need to be invited to every PM meeting. Just the ones where both can benefit. It's about valuing each other's time. Example - if there are product budget or legal approval discussions, for example, that's too vague for me. But if it's a product feature discussion, it's closer to my work.

3. Yes, agendas help. Nothing too fancy, just quick 4-5 pointers in the calendar invite. They align everyone during the meeting and prevent from spending too much time on one pointer, thus avoiding unnecessary additional meetings.

There is a trade-off. Ultimately engineers build that next thing and take lots of assumptions in the process (related to future iterations of the product, integration story with other products, what telemetry is important, for which use cases perf is critical, etc). Understanding at least some of the vision makes it more likely that they build what you wanted them to build and it can be iterated on like you expected and wanted it to. No spec will be perfect, and it is impossible to ask for clarifications for every aspect of it. It is also impossible to design a product with perfect perf and flexibility in all aspects and it is better to make those tradeoffs consciously.

Personally I enjoy understanding the business side of things well and regularly challenge PMs and designers on what to do next or how to do it (since I understand the telemetry better than them in most cases)

The brainstorming process imo is the process to bring out possibly vague ideas, make them more concrete (and make their validation story concrete). There will be ambiguity and the goal is to reduce it as much as possible (or decide next steps to do that)

Just like any other meeting, such meetings don't feel like a waste of time if they are conducted well. Like having a good agenda, good moderator, specific next steps and follow-ups (most meetings are not conducted well imo)

That’s literally how we run @ Bloomberg .Engineers innovate , build , deploy and even support the product end to end , even though they are kind of looking to change that these days .PM are more in coordination and focus oriented role where they talk to customers and understand there needs and help engineers to the innovation and FOCUS on the MVPs .I stress on focus as we engineers always tend to make things perfect even though it might fall under the 20% of the 80/20 rule.

Always let the team decide on what’s needed , you can focus on gathering customer pain points and needs

Yeah, it is very hard sometimes to argue against making something perfect as an engineer (because then you can potentially get labelled as a person who thinks technical sloppiness is ok). But it is the truth that unnecessary code/ design keeps adding unnecessary complexity that actually important features have to pay the price for (possibly resulting in a net negative business impact)

Definitely sounds like you guys do this really well at Bloomberg! Appreciate you sharing.

If I may, one question for you: In your experience, do you want the PM to be involved in coming up with solutions with you once a customer need has been identified. I ask because solutions could be dramatically different from user experience and business value perspective

Indeed! What I am wondering is whether an engineer / several participate in the process of pulling in data from a variety of sources to help the team best set the direction of the product, in your experience?

Engineers like solving problems, even not necessarily problems that affect them directly. They are usually naturally curious, and experiment often to learn.

One of the most valuable things you could probably do is get prototypes from them or talk to them about their side projects.

I have built multi million dollar data sets/ pipelines for my company out of pure curiosity. But I don't know who would pay my Dept for them and they weren't requested... so they are just sitting on my hard drive.