Product Management: A 2-Minutes Read
On my first ever attempt at a PM interview, when asked what I understood about the role, it went something like this:
“Err… You think of what to make… Then ask for design to UI/UX… Then bring the design to developers…?”
I’m pretty sure my interviewer was not expecting to hire a mailman for his team, but he understood how I came up with such a naive answer. Product Management is a hard role to explain. Not only due to its only recent rise in tech, but also because the role is, by its nature of work, ambiguous.
Everyone will have their own interpretations of a PM. There is no universally agreed definition for now, but here is a simple formula to visualize what a PM is:
As gucci as the role sounds, you might want to say sorry to your aunt who thinks that you’re a manager fresh off of college. A PM is not a manager of anybody.
What you are is a communications hub, a prioritizer, a researcher, a presenter, but most importantly, you are responsible for the ultimate success of a product.
A product can be anything. When you are working in a social media company, you might not always be in charge of the entire application; just certain parts of it. For example: Twitter’s timeline has a number of PMs working on different parts of it.
A day in the life of a PM
Things are always dynamic at the field, but below is a rough representation of what I did during my PM internship.
10:00 AM — Check messages on Slack and emails. Even after you were done the day before, your team might have been not. So there will always be updates.
11:AM — Team standup meeting. You will gather with designers and developers to discuss on their progresses, as well as helping with any difficulties they might have. Standup is also used to move tasks on our project management software to see which ones are in progress, which ones are done, and which ones are blocked.
11:30 AM — Meet with designers. Discuss about problems and ask for their feedback of what can be done better. In the case for making new improvements, this is where you brief them of how the mockup should be.
12:00 PM — Write Product Requirement Documents (PRD) and create new tasks for developers. Making a product happen is not only about tossing mockups for devs to code. PMs should help in defining the product’s behaviors by creating a document detailing what the product is supposed to do, which will also be useful for the Testing Engineers later on. Once your requirement is sufficient, create tasks details for the backlog.
03:00 PM — Discuss with Testing Engineers (QA) of what have gone right, or wrong. This is why product requirements are so important, otherwise QAs wouldn’t know if the outcome is as expected. If there are bugs that need solving, you will discuss with devs and QA on how to solve them.
04:00PM — Sprint planning. Remember backlog? The tasks there are not supposed to stay in our bucket list for long. Sprint plannings are usually done bi-weekly in an interative manner to plan what the team will do during the period, and what are the expected outcomes at the end of it (ANAP, anyone?).
06:00PM — Self-Reflect. It’s just a me-thing, you know. There were a lot I had to do in 1 day, and to make things easier for me the next day, I would note down what I couldn’t accomplish today and what I should accomplish tomorrow. The work of a PM needs a lot of self-discipline. Afterall, PM is the guardian of entropy.
All in all…
In reality, software development projects are very messy. Different people want different things, and even when the data science team would slap them with statistical analyses of what’s happening at the time, there would still be stakeholders who would get very defensive. Devs think designers are whiny, designers think devs are pushy, business development just wants happy clients, but clients change what they want once every hour. So this is where your role will come in handy: An enabler for a feasible product to happen — by bringing together cross-functional teams, ensuring alignment between the diverse needs of each stakeholder.
_________
This has been a very brief introductory article on Product Management, so if you wish to deep-dive on the role, I recommend you to sign-up toProduct School.
