This message was deleted.

I suppose you can start with what hurdles you are facing.

As an example @Kashmira Patel I had someone help backchannel and said they feel the infra PM should know the difficulties of migrating between one NoSQL backend and another.

I would say the infra PM - if they’re a technical PM should know the high level difficulties, the big rocks for sure. Then they work with engineering managers to figure out the detail and plan the migration

I would totally agree. Concepts down to why a compute, why a particular database or what in the market are competing alternatives to use. I guess I don’t know how to define the depth expected. Do you have a sense of what that gauge is? For example, to see if I am off I am taking the DevOps course for AWS. All of it is familiar. Thoughts on third party content that represents a minimum bar?

With the db migration example - I would start with what the current infra looks like, what are the must haves, what are things you will lose due to the core concepts being different, what are the trade offs, what does the migration process look like, how it would impact operations, how you would guide the teams using these databases to transition over. Not sure if this answers your question, but in general the basic PM concepts of understanding the user’s needs, pain points, finding the best solution apply.

@Kashmira Patel I guess the example he posed was if they are choosing a KV store what would it be? To me, I think I primarily need to know what the end customer wants to do and ask based on this what engineering thinks they need. I don’t know if I should know the depths except the highest level (eg consistency, read write performance ) and even then all that can be researched. He implied that I should have a priori knowledge of how to make this decisions and I pushed back saying I think engineering teams define the spec. But he said if I am not familiar across the market then it’s just a TPM job. To me this did not seem like making the choice of which db to do was the right role. It would be in scope to me of framing of different teams all had different requirements workloads and we needed to understand costs of one over the other. But he felt being able to actually have familiarity with the available products was necessary even if not making the final decision. Thoughts?

I’m on your side here. You can’t know everything in-depth. Sure once you narrow down on one or two to evaluate, do a POC then you may dig in deeper and play around (if you like doing that kind of thing), but from the get go, the PM should do the following • understand the user needs • write up a PRD • do the research to find tech that potentially meets these needs • socialize the PRD with engineering • partner with engineering to evaluate the candidate tech solutions. • partnering is needed so that whatever findings eng comes up with, PM looks at it, ensures the recommendation from eng is still meeting all customer needs (and sometimes ensuring it is only addressing customer needs, we do tend to get carried away at times), and presenting this to the customer • you may dig into the tech yourself if you are so inclined, but I would not say that is the requirement from the get go. No one, not even engineering is expected to know all the finer details of all available tech

Super thanks @Kashmira Patel I am glad to hear your thoughts on this. This is giving confidence to go back and reframe with managers on the value and deliverables. Love your well thought out bullet points!

You bet! Let us know how it goes