The 7 Most Common Product Design Interview Questions

Today, Rodhmir Labadie, a Product Manager at 40 Launch, shows us how to answer the 7 most common design questions that are asked in a Product Manager Interview.

Click the links below to jump to Rodhmir’s answers!

  1. What is your definition of Product Management?
  2. What tools and/or processes do you use for Product Management?
  3. How do you create, maintain and share specifications?
  4. What is your strategy for customer engagement?
  5. What is your biggest product mistake?
  6. Can you define what a SCRUM meeting is and its importance?
  7. What do you think about SCRUM meetings?

About Rodhmir Labadie:

Before 40 Launch, Rodhmir was a former Product Manager at KPMG US. He also 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 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. 

1. What is your definition of Product Management?

Rodhmir:  It is always about contextualizing the problem. A Product Manager 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.

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.

2. What tools and/or processes do you use for Product Management?

Rodhmir: It goes pretty broad, so let’s start with the processes.

The Process

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 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.

The Tools

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.


3. How do you create, maintain and share specifications?

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:

  • Who are we trying to create a solution for?
  • What are we trying to accomplish with this effort?

Next, we bring everyone to the table and share that information with them. We do this for two reasons:

  1. Get early insights into what path we are going to go down.
  2. 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 towards 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 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 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.

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.

4. What is your strategy for customer engagement?

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 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. 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.

5. What was your biggest product mistake?

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.

6. What is a SCRUM meeting and why is it important?

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.

7. What do think about SCRUM meetings?

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 use strict SCRUM exactly because people have different experiences and so forth.

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email

Contact Us

If you are interested in our services, schedule a call with us. For all other inquires, feel free to reach out to us directly via the contact form or email.