Hello everyone. I’m Rob (Chinese name 一凡, pronounced Yifan), originally from Costa Rica in Latin America, and I’m a Product Manager currently based in Singapore.
I’ve worked as a Product Manager for companies such as Kicksta , StudyMe (Edtech) and MagicMemories (Retail).
What do I do as a Product Manager?
Usually, I first gather requirements for the features that we want to add to a software product. This list of ideas could come from the CEO of the company, other team members, investors or users. Then I try to understand their needs and the specifics of those features, like how they expect it to work, what they imagine it should be doing when the feature is already deployed. As I mentioned, these stakeholders could be the current users of the platform as well. So I try to get as much information as possible on what they’re looking for, the issues they’re having, and possible paths of solving those.
After gathering all this information and comparing it to data from the platform usage, and understanding the business value of it and if it will improve customer experience, I set up a list of priorities based on amount of effort that it’ll take to accomplish these ideas and then balance it with the value that it will bring to the company.
How do I make decisions?
There are multiple ways to make decisions about these ideas. One is to create a quick prototype or mockup with tools like Figma or Miro, and showing it to stakeholders. I could even show it to the development team and storypoint the effort. Then, depending on what we want to achieve with the feature (more signups, more purchases, etc.), we take some stakeholders higher in the percentage of decision-making involved. I’ll expand on that on a later video and article in robyifan.com.
After selecting which features we definitely want to add into our roadmap, I create a project definition. This is basically a written document, usually in Atlassian’s Confluence or Notion, where I layout groups of similar tasks into their own batch with a common goal or topic. This is helpful later on when developing a roadmap, because the project would turn into an EPIC. An Epic could be defined as a group of features with a common goal. With this document created, it’s easier to understand the scope of the whole list of features and to divide them into timed releases.
How do I lay out tasks?
So let’s say we have a feature we want to develop, like creating a plugin so people can use our platform through a CMS. We lay out the required tasks to do that and the expected deliverables in the acceptance criteria of each one. These criteria are a set list of what is expected when the QA team or myself need to see to say if a task is done or not. This is pretty important because every member of the team may understand different conclusions if the task is not completely clear. So it’s very difficult to have a task that includes every possible scenario ever. So at least mapping these expectations in the beginning will allow even you to prioritize what you need.
If there are some things missing at the end of the task, I would normally still close the task and define new expectations in a different ticket. Just so that we don’t keep on dragging tasks across sprints. There needs to be a sense of accomplishing tasks constantly and rapidly. This is not only for the developers to feel that they’re part of a company or product that is accomplishing goals. The executive team also needs to have charts and analytics of the tasks and the storypoints that get fulfilled in a timeframe. This allows us to measure speed and plan for the future.
It is easy to plan to go at 100 miles per hour if you know you can already achieve 90 miles per hour. With clearer tasks, we can carry out storypointing with the dev team. Then, we start allocating each task in sprints according to what each dev and each sprint has proven that we are able to do.
How do I measure the efficiency of teams?
Let’s do some quick math. If after 2-3 sprints, we find that we’re averaging 100 storypoints per sprint, allocating the storypoints on other sprints is easier now that you know that if you have 200, the odds of being able to get all those done in one sprint is low, and you need to separate them into two. Plus, you can get the average of how much each developer manages to do each sprin. So if from those 100 storypoints you find out that each developer gets to do around 20, then on the following sprints, you know you can’t expect much more from them.
I always try to add a bit more just to keep everyone active and constantly increasing the amount they manage to do each sprint but there’s usually a limit.
That last explanation is one of the main issues I’ve seen in software companies where you’re missing a Product Manager. A lot of ideas come to mind and everything gets assigned immediately. There’s no telling of WHEN is the best time to add a feature into the roadmap, or calculating if you add a feature now, it will replace the other one that was in the current sprint. It’s like allocating water on a vase. If you want to add tea on the vase now, you need to take out some water. And if you want to have both, then you need another vase (more capacity, more people).
All this is commonly known as Agile Development. I usually set up the Scrum process within Jira because it allows you to have sprints with dates. There may be other tools where you can create these but it’s not really made for this. So that’s why I choose it for software products and startups that need to push constantly and iterate.
What’s next in the product manager process?
To finalize this article, the rest of the process is not that complicated. There is a lot of testing, trying out if the features work as they should, try them out in a lot of different scenarios. As a Product Manager, I usually try them out myself and give feedback. The QA team also does unit test. Then, if the feature is good to go, we create release notes. These may include notes for the internal team in the company. There could be articles and emails to users or even notifications within the system that reach our users. Together with the marketing team, we may also create video materials to showcase these to users.
I really like the case of Medal.TV, a video/gaming platform with which I worked in the past. They have a really well-done product and a community on Discord. They publish their platform’s updates on discord and attach a video that explains these new releases. I think you should check them out.
Thanks for reading!
