Hello everyone. I work as a PM for one of the larger tech companies in my area. PMs, in my opinion, are more concerned with business objectives, product strategy, and motivating developers and designers to achieve product objectives.
But ever since I started working, I’ve been highly involved in sketching out backend system ideas, and when I recently sought for comments, my boss actually said that I should sharpen my database design abilities and be more aware of how backend systems interact with one another. Is this typical for PMs in general? Or is this the typical behavior of a technical PM?
This is not typical for any PM, technical or not, in my opinion. I might join discussions if I believe that engineering has a strange design or something that might not support future use cases successfully, but engineering and your architect should be in charge of the database design to ensure that it fits well.
I may also create sequence diagrams to illustrate how I envision a process’s flow, but again, I’m not trying to design anything other than to demonstrate how it might work within the context of the design and the scenarios we need to handle.
Even in strictly backend PM work, the use cases you wish to address are everything. Define its intended use, not how its designed…
I see; I appreciate you, @RobMartin. Can I also ask a question concerning APIs? Do PMs also need to have a solid understanding of APIs? Like what fields are available or whether the system can currently support a certain functionality that comes to mind?
The organization is set up so that my team and other PMs are “Regional” PMs and “Business” PMs, respectively. We frequently receive feature requests from the business PM teams, and we frequently concentrate on how we might implement them. I’m pretty torn on this because I believed the developers should be taking care of this. It appears that we are merely an intermediary translation layer. Currently feeling really lost.
This also applies if you’re only “selling” APIs internally. If your customer consumes an API, you should be familiar with the features of it — just like you’d be familiar with a user flow if your customer consumed an app or website.
Hi - I have experience as a front and back end B2B PM, and I believe that you should understand WHAT the API does, including WHAT data it gives, rather than HOW it does it.
The best way to approach this is to consider the API to be a product that merely enables other products to service users. Therefore, if you consider every use case that could be resolved, you can abstract that into a specification for the data that offers adaptability, durability, and robustness to address the issue, and then provide a good product need for the data.
For e.g., we are currently developing a particularly crucial API that provides specific types of metrics. Instead of only providing the metric that is required right now, we could easily provide multiple views of the important metric over a range of typical time periods as well as some raw numbers that could be used to contextualize the statistic for a variety of use cases.
I believe it somewhat depends on the function. In my prior employment, I worked on our platform, which covered both B2B2C use cases and our websites/apps. I was fairly familiar with the majority of API designs in those circumstances, both in terms of the request and response as well as any functions that were used to gather the data for a response.
Engineers were my target market, therefore I needed to make sure our APIs met their needs while also being generalizable. Additionally, I had to check that our error codes were clear and that response times matched either internal site load timings or SLA.
With stakeholders, I had to decide what we would provide and what a user of our API would have to accomplish independently. This might apply to circumstances where they had to use their own cache or make multiple API calls rather than just one.
I am concentrating on ML and data in my present role. I know very little about our APIs and rely on engineering to let me know if we can piggyback or if a new service is necessary.
I’d say it helps to have that understanding- it’ll help you to create a bette r product knowing what data/info is available and what’s not. It’s definitely not mandatory, but it has helped me to be a lot more lethal.
This is not PM work. The team’s architect and EM are responsible for this. Your responsibility is to explain the product strategy and how you anticipate it will develop throughout the ensuing quarters. Then, you must discuss with tech leads how particular features will develop. These will have an impact on choices being made right now. Future requirements shouldn’t put an undue burden on the database, according to a smart architect.
Also keep in mind that updating the database causes the back-end staff the most trouble.
For example, if as per current requirement there is 1:1 relationship between two entities but you envision there could/will be 1:N relationships in the future, let them know. Making the database design change to reflect 1:N changes with live data is PITA.
Not usually, but it can vary. It can be simpler to communicate with developers and establish confidence if you are aware of the ramifications of specific database formats and APIs.
If I hadn’t been able to comprehend various components of the database and how they related with one another, I don’t believe I could have been effective at my previous employment. It became a bigger issue when there were certain organisational changes. I don’t know how to talk to some of these guys, the chief of the development team said at that moment. We can discuss the potential effects of modifications if I design some database structures for you to grasp while we are speaking. When I describe it to others, they don’t comprehend, and I have no idea how to execute it.
A situation quite similar to APIs existed. Being able to examine the current APIs, comprehend how to translate customer expectations into API requirements, and discuss the effects of various implementation possibilities for new ones were all very beneficial.
Schemas and API documentation were never presented to me at past employment until I actively asked to see them. When I asked to see them, the devs were astonished because they had left that information out. This appears to be the more typical circumstance.
As a PM, you should be focused on the user. Database decisions can impact your users but it is your job to partner with engineering to communicate user needs so that they can make the right database decisions to support those needs. You are not an engineer and you shouldn’t try to be one, but you should heavily advocate for your users and get a bit dangerous if possible on basic database knowledge so you can effectively advocate for your users.
I’m a little amazed by how many people declined. The platform-type product I work on has both engineers and non-technical users. Knowing database design and simply comprehending the technical tradeoffs that your engineers express are two different things, in my opinion. The best of our engineers and architects are devoted to creating the product, and since I work for a startup, we don’t actually have engineering managers (or even project managers and scrum masters). As a result, the PMs must know just enough to be dangerous.
I’ve always been told that developers concentrate on the “How” and PMs concentrate on the “What and Why.”
I won’t worry about database design unless the solution needs to scale in a particular way. For instance, I’m working on expanding one of our order management products to include payment processing. I have talked with the architect about designing it to be as product neutral as possible because I am aware that other products will adopt this later this year.
No, Product Managers should never design database.
What you should be able to do is work with your tech lead to provide requirements for scale, sometimes latency, and directional examples of possible future features so that they can make a database design that is able to support your users well into the future. Certain designs and database choices work great for some use cases, but make others borderline impossible without significant additional engineering work.
As a PM you don’t necessarily need to dig onto the implementation details of your product.
The reason why is that you are not the system architect nor a DB specialist, so whenever you mess with the implementation you risk breaking something or duplicating other functionality you may not know about.
In general, the DB design and other architectural components are owned by the Dev team or a System Architect who knows the whole picture. Some companies may even have a Software Design Authority that keeps tabs on DB design and other architectural components to ensure that multiple products don’t conflict with one another.
However, it helps if you have deep understanding of your system’s architecture, how the DB is structured and what the capabilities of the DB engine are, so you can leverage those when designing your features and make sure your product delivers what you intended. This is normal for most software products, especially cloud-based, with the understanding that you are not the owner of that design, and you should have no saying or responsibility on the implementation of this design.
If your product is technically based, a significant portion of your business will depend on persuading technical leaders within the target organization that what you offer is good, accurate, or better. Those are crucial metrics.
Although you can rely on your engineers and architects for advice, you should become at least technically proficient enough to ensure that what they’re doing aligns with what the consumer wants.
Others here may be saying, “Oh, you can rely on your engineers/architects,” but they are omitting the fact that those men are also fiercely opinionated and likely to be far too slow to show empathy for the demands or philosophy of the client. If you can’t quickly recognize “SCRAP,” you’ll let people down and lose business.
I know I’m biased, but in my opinion, what distinguishes a product manager from a business strategist or management consultant is the capacity to be empathetic to these practical technical aspects.