Being a Product Manager can be very different from being a project manager, from the responsibilities held to the processes being used. In this blog article, we discuss the possible questions about product design that might pop up in a Product Manager interview. We also talk about certain topics with Rodhmir Labadie, a Product Manager at 40 Launch, ranging from how one uses story points to organize different tasks to the importance of thoroughly understanding the problem at hand as a team.
Product Gym: What is your definition of Product Management?
Rodhmir Labadie: It is always about contextualizing the problem. A Product Manager really helps the team to effectively execute against a shared vision.
It is identifying the problems and the pain-points, then seeing where you need to take the appropriate steps towards putting out a testable MVP and testing out some risky assumptions or solving a perceived need that you think your product can begin to move into.
A Product Manager coalesces all those efforts into solving problems with the help of different team members. There is a high level of communication to manage expectations and ensure that the team is insulated from heavy distractions. This also includes any type of risks that the team might be taking to help support the efforts of the organization, key stakeholders, or the fidelity of the test itself.
Product Management, in short, is the ability to coalesce a team around a shared understanding based on as much information as possible, while keeping everyone aware of what you are accomplishing in an effort to drive meaningful value either to the specific product itself or the organization as a whole.
Product Gym: What tools and/or processes do you use for Product Management?
Rodhmir Labadie: It goes pretty broad, so let’s start with the processes.
The process that I take depends on the problem at hand. Product Management really can be physical products, digital products, or even a service. Depending on what you are actually trying to solve, these different spaces of Product Management strategy can vary.
In terms of digital products, the process I have used in the past has been based on Scrum and Agile. You have these built-in structures and traditions that are part of the process itself to ensure that there is repetition, cadence, etc. Agile applies certain approaches through that Scrum methodology to keep you in line. For example, you would think, “Okay, this is what the definition of what a Sprint is. These are how we structure our stories within the context of this Sprint.”
A high-level pro process would be creating a cadence that the team can follow and provide key measurable insights around how the team is executing against these different problem sets. Those two programs are what I am used to, but there are other methodologies out there as well.
In the past, I have had a company where their protocol was not as formal. There was no 2-week sprint or a retrospective. It was an informal process, but it worked well with a very lean approach to apply Product Management methodologies through our execution.
As far as tools, I have pretty much used all of them under the sun, whether it is Trello, Jira or Asana. I have used Monday as a project management tool. I have used Sketch for wireframing and even used the basic pens, pencils, and notepads. All of those are great tool sets you can use in getting a Product Management strategy together, presentable, and communicable. We will use whatever tools are available. The goal is to communicate clearly where you are within a time frame to the rest of the organization.
Product Gym: How do you create, maintain and share specifications?
Rodhmir Labadie: I create specs based on research done ahead of time. Before we are creating, maintaining or sharing these, there is a shared understanding of what we are trying to accomplish. There are some upfront legwork and forensics done by myself and other team members. We need to think:
Who are we trying to create a solution for? What are we trying to accomplish with this effort?
Once we create a clear understanding of what we are trying to accomplish, we bring everyone to the table and share that information with them. We do this for two reasons:
- Early insights into what path we are going to go down
- Giving them the ability to provide an opinion into how we are going to solve this particular problem
I like to take a collaborative approach towards Product Management. No matter what area you are working in, it is all collaborative. No one is working in a bubble by themselves. It really has to be an open-door policy between communicating our needs, goals, and strategies to the organization within ourselves in order to keep a high fidelity.
From there, you would create this high level, low fidelity example. It may be a roadmap, wireframe or even bullet points that outline exactly what we are trying to do. Maintaining it begins with taking these efforts and overlaying the feedback from stakeholders, users, and team members onto this gambit of data that will allow us to begin making these hardened solutions. With the team, you create these manageable pieces, which begins to create what the stories will be. It is basically highlighting what the acceptance criteria are around these particular goals which are aligned with our persona types that the research has flowed in to provide context into why we are doing what we are doing. The process would be bringing that into this timeframe in terms of complexity, two-week sprints, and how we are executing.
We need to ask ourselves:
What are the pain points that are occurring? Where are we not able to meet these goals? Do we need additional information in order to provide insights? Do we need to color this in a way that is more meaningful towards solving this problem?
I share all this information through different applications based on which team I’m working with. Jira is great with engineers, but Trello is sometimes better with the design. If I have team members that are overseas, I might contact them using Slack and bring some of the Trello assets into a shared communication hub. It is basically an ecosystem that allows me to create, maintain and share these specs.
Product Gym: Do you mind telling us about your strategy for customer engagement?
Rodhmir Labadie: It really depends on what space I am going into, as it could be defined, undefined, or defined but needs to be reinvigorated. I would say that customer engagement is an art as much as it is a science, depending on who your customers are. The first step in this process would be going out there and figuring out who your customers are. The questions you would ask yourself would be:
What are their segmentations? What do they look like? What is their high-level demographic information?
The goal is to communicate to your customers in a way that is most meaningful in them whether it is through language, or trying to identify different pain points. You would not speak to a 16-year-old the same way you would to a 65-year-old. A person who needs an emergency good may not have the same paying points as someone seeking a luxury item. Even that “need versus want” relationship applies a bit of artistry to the science. Ultimately it is about getting a clear understanding of who the customers are, where they are, and what their motivating factors are. After gathering all this information can you then create a customer journey based on those answers?
There is a top-of-funnel strategy, which lets people know that a solution is provided that will support their key needs in a way that is safe, inexpensive, and easy to use. Then there is the middle-of-funnel strategy, where the customer is now exposed to your product and you are thinking about how to give them the value proposition. How do we begin to engage with them? How do we get them to become advocates for our product so they can get the key decision-makers within our organization to pay for our solution? How do we incentivize them? Do we use discounts, rewards programs, or some other perks as those incentives?
The customer engagement strategy around each of those is dependent on the touch point, their persona type, and what their needs are in that particular problem. It is positioning your product as the solution to these needs. What is their mind-map like? What points are they excited about? What points do they dread? I want the product to make them say, “This will make my life easier.”
This would be the high-level approach to customer strategy. It is understanding what buckets they are in and then applying a process that aligns their needs with our product solutions to help them meet their goals.
Product Gym: What was your biggest product mistake?
Rodhmir Labadie: I think everyone makes product mistakes all the time. However, I would say that my product decisions should always be learnings. In an effort to not sound fluffy, I would say that “mistakes” is not the term I would use. At times, I may have made a series of assumptions that led us down a path that was not where we needed to be at that particular time. If you are following the process, you should be adjusting all the time. Every adjustment is compensating for these learnings.
I learn all the time because the idea of a Product Management process is really convincing your team and organization that they are where they need to be. When you are talking about the future, it becomes hard to make predictions. There are so many things that influence your ability to get there that it is really about making sure that you are testing your assumptions with these small adjustments that will provide you the insights into where you should be.
The biggest product “mistake” I made was making the assumption that I knew where we would be at a particular point when I actually did not. You learn over time that what might be an assumption is not, and that comes with time and experience. Everyone is making mistakes all the time. If you are not making a mistake, then you are not doing Product Management.
Product Gym: Can you define what a SCRUM meeting is and its importance?
Rodhmir Labadie: A SCRUM meeting, or a standup meeting to most people, intends to identify where people are within the process. Typically you have a planning meeting, and then you enter into a sprint. A planning meeting is when you are defining the scope of the efforts you are bringing into this process.
Let’s say there is a 2-week sprint, and you have 5 team members who are bringing 50 story points. The story points take a Fibonacci approach, scoring story points by their level of difficulty. Once you establish how many points you want to bring into a particular time period, you are asking everyone to tell where their assumptions lie. Some tasks may take longer than expected due to many variables, so it is important to identify blockers within each team member. You need to think:
Are the specs clear? Is what we assumed to be true before still true? Do we need to change anything?
Then it is the Product Manager’s responsibility to jump in there and re-adjust priorities accordingly. The SCRUM meeting is giving everyone transparency around what they are working on, information on where their blockers may be, and providing clarity around whatever problems that are brought up. In the end, you discuss what the release process is going to look like and see how to overcome these blockers.
Product Gym: What do you find dislike or find inefficient about SCRUM meetings?
Rodhmir Labadie: I am quite partial to them, and I feel like it forces communication. However, it can be unnecessary during a really heads-down period, or if it is with a really experienced team. If everyone knows that something is a very complex issue and that time needs to be spent solving it, it becomes prudent for the SCRUM meeting to be short.
The sizing of the planning meetings can be dicey, so I have introduced, in my own process, the idea of pre-planning meetings. These are used to help give people early access to understanding what the problem is and everything around the objectives of these particular stories. Then I let them take it back and figure out how to mitigate around some of these potential risks. These provide insights for going into the next meeting.
The retrospectives can get personal sometimes. There are parts of it that require transparency, but it really requires an open-minded and safe space of communication for people to share their ideas without being too aggressively negative towards another individual. The beauty of SCRUM is that you always have to adapt SCRUM to your particular team. I would not use strict SCRUM exactly because people have different experiences and so forth.
About Rodhmir Labadie:
Rodhmir Labadie is a Product Manager at 40 Launch. Before 40 Launch, he was a former Product Manager at KPMG US. Prior to that, he worked for TheaterMania where he started as a Product Designer and then became a Product Manager. He got his Bachelor’s of Science at Sacred Heart University. He has a background in technology, development, marketing, and design, and has experience working in the energy, finance, logistics, and consumer branding industries. Rodhmir has successfully launched over 30 new products, websites, campaigns, and marketing strategies.