If there is one essential skill that a Product Manager has to master in their lifetime, it is product design.
While product design might sound like the job of a UX Designer or a User Researcher, it is the Product Manager, who determines the customer pain points and what is missing in the market.
The key to success for a Product Manager lies in empathy, and product design questions assess your ability to empathize.
Rodhmir is very passionate about the values that a Product Manager should have. Make sure you read his articles on Medium to learn more about the principles he teaches to Product Gym members:
Before we jump into our questions, let’s learn a bit more about Rodhmir.
Rodhmir is currently working as a Product Manager at TuneCore. Before his role there, he was a Product Manager at KPMG US, while also holding Product Designer role at Theater Mania. He holds a Bachelor’s degree from Sacred Heart University and has a wide range of industry experience such as: energy, finance, logistics, and consumer branding. Rodhmir has successfully launched over 30 new products, websites, campaigns, and marketing strategies.
Click the links below to jump to Rodhmir’s answers!
- What is your definition of Product Management?
- What tools and/or processes do you use for Product Management?
- How do you create, maintain and share specifications?
- What is your strategy for customer engagement?
- What is your biggest product mistake?
- Can you define what a SCRUM meeting is and its importance?
- What do you think about SCRUM meetings?
Rodhmir: It is always about contextualizing the problem. A Product Manager helps the team to execute against a shared vision effectively.
It is about 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.
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 to drive meaningful value either to the specific product itself or the organization as a whole.
Rodhmir: It goes pretty broad, so let’s start with the processes.
The process that I take depends on the problem at hand. Product Management can be for physical products, digital products, or even a service. Depending on what you are trying to solve, these different spaces of Product Management strategy can vary.
For 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 specific 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.
Having a well-defined Product Management process is crucial when driving products. As a prospective Product Manager, you’ll be asked about your Product Management process in most, if not all, of your Product Manager interviews. Make sure you watch our instructional video to learn how to answer this question the Product Manager way:
As far as tools, I have 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 toolsets 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.
Rodhmir: 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:
Next, we bring everyone to the table and share that information with them. We do this for two reasons:
- Get early insights into what path we are going to go down
- Give them the ability to provide an opinion into how we are going to solve this particular problem
I like to take a collaborative approach to Product Management. No matter what area you are working in, it is all collaborative.
No one is working in a bubble by themselves. There has to be an open-door policy between communicating our needs, goals, and strategies to the organization within ourselves 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 precisely 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 start making these hardened solutions.
With the team, you create these manageable pieces, which begins to establish what the stories will be. It highlights what the acceptance criteria are around these particular goals, which align with our persona types that the research has flowed in to provide context on 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.
What are the pain points that are occurring? Where are we not able to meet these goals? Do we need additional information 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 excellent with engineers, but Trello is sometimes better with the design team.
If I have team members overseas, I might contact them using Slack and bring some of the Trello assets into a shared communication hub. It is an ecosystem that allows me to create, maintain, and share these specs.
Rodhmir: 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 is their segmentation?
- 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.
Ultimately, it is about getting a clear understanding of who the customers are, where they are, and their motivating factors. After gathering all this information, can you then create a customer journey based on those answers?
There is a top-of-funnel strategy that lets people know that a solution is provided to support their critical needs in a safe, inexpensive, and easy-to-use way.
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 critical 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 touchpoint, their persona type, and what their needs are in that particular problem.
It is positioning your product as a 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.”
Rodhmir: 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.
Rodhmir: 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.
Have questions about SCRUM? Don’t forget to read our Ultimate Guide to Scrum to have a quick review:
Rodhmir: 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 strictly use SCRUM because people have different experiences and so forth.
Want to join Product Gym to change the course of your career? Schedule a call with us today to find out how we can help you!