Thought leadership / blogs

Product Management Lessons From Rick Rubin

Written by: Manchind Arora, Product Manager, TribalScale

Rick Rubin is an iconic Grammy-award winning American music producer who has been the genius behind the success of many records with Pharrel Williams, Metallica, Adele and many more. From rock to pop to hip hop he’s been able to bring out the best in musicians and create successful music projects.


Product Management Lessons From Rick RubinPhotograph from Robert Sebree


You might be wondering how this relates to product management. Throughout his career, he has consistently demonstrated his unique talent for understanding an artist's vision and translating it into a finished product that exceeds their expectations. His techniques for executing a music project are ones that I think all product managers can learn from.


In an interview with Lex Fridman, Rick Rubin discusses his advice for music projects. Below, I’ve pulled key insights from his interview and related them to how product managers can better execute their projects.


"The ruthless edit"

When Rick Reuben is creating a music project where he’s having difficulty choosing which songs to pick, he does what he calls a “Ruthless Edit”. For example, if he's got 25 songs to choose from for a 10 song project, he initially chooses the 5 songs that are “must haves”. Then, he starts selecting the next one and decides whether adding that one song improves or destroys the overall quality of the project. He continues this process until all 10 songs are selected.


Rick’s methodology of selecting the best combination of music pieces to accomplish the best overall music project is very similar to the MoSCoW prioritization method in product management for managing requirements. When scoping a project, product managers should be working with stakeholders to identify and categorize features that are “must haves”, “should haves” and “could haves”. Along with that discussion, you should also identify constraints such as budget and timeline. From there, you can begin to establish the project scope, starting with the “must haves” and adding “should haves” and “could haves” that further accomplish the purpose of the product instead of diluting it.


"The more you add, the smaller it gets"


Rick is describing when producers try to make a “bigger” sound - a sound that is very impressive, they try to add more instrumentals to the song. This results in the listener having too many sounds to focus on and the “wow” factor of the song being lost as the listener is overwhelmed instead of impressed.


It’s the same situation when planning out and executing parts of a project. In a sprint, the worst thing you can do is commit to completing a bunch of large features. Those features typically end up being poorly executed, leaving the client underwhelmed and dissatisfied.


Once you understand and have prioritized the project scope, good product managers are able to break it down into smaller parts with less complexity when planning sprints—the larger the project, the smaller you will need to break it down. This is a more effective way to execute higher quality features that better accomplish the project requirements.


When requirements of features are changed or new features are tacked on while the project is under-way, this is called scope creep and is very common. To mitigate this, you should communicate openly with the client, discussing the original scoping document to refocus priorities, and go through the formal scope change process if necessary.


“If any of us don't like what's happening, we say it”

When working on a music project, Rick isn’t focused on creating the best sound, but rather getting everyone focused on contributing to the best sound. This means he creates an environment where everyone is comfortable sharing their opinions on the music being created. From there, he makes necessary adjustments to the project to achieve the best end result—great music.


As a product manager, you are responsible for creating an environment where everyone is comfortable sharing their opinions and ideas on any part of the project such as cadences, priorities, design, etc. Input from project members like designers and developers is crucial in getting the information you need to make more informed decisions when it comes to your product.


“My goal is not to form an opinion, it’s to understand. How did you get to that [idea]”

When hearing out new ideas for the music projects he works on, Rick aims to understand what inspired those ideas to provide himself more context when executing decisions on the project. Sometimes when asking these questions, the musicians he works with get offended as they feel that he’s trying to challenge them. However, he aims to understand the inspiration and thinking process behind those ideas.


In a product management context, asking questions about how someone’s ideas came about helps you understand what issues other people see in the product or what their interpretation of the goals of a product are. After understanding their perspective and thinking process, you are better able to align everyone on project goals. Having this context allows you to make decisions holistically as you have more context behind the issues that other team members see.


Final Thoughts

Rick Rubin’s advice in successfully executing music projects across all genres is relevant also for product managers. Some main takeaways from his interview are:

  • When scoping the project—Choose a few core features (aka the “must haves”) and only include additional features (“should haves” and “could haves”) that improve the product instead of diluting the purpose of the product.
  • When planning sprints—Commit to completing fewer features that better fulfill project requirements and break down the project scope into smaller, less complex tasks
  • Create an environment where everyone on the team is comfortable sharing their opinion.
  • Understand where your team members’ perspectives come from, don’t be afraid to ask them questions about their thinking process.




Manchind Arora is a Product Manager at TribalScale. He is curious about functional design and enjoys problem solving on a project scale. In his free time he enjoys photography and music.

Let's work together

Have questions about your next digital project, startup or TribalScale? Let’s work through it together.