Back to resources

Don’t Go to a Vendor for a Solution

Product
Stakeholders

12 May, 2021

Murali Bhogavalli
Murali Bhogavalli

Group Product Manager at Wave Sports + Entertainment

Murali Bhogavalli, Group Product Manager, Data & Platforms at Tinder, explains why one should go to a vendor with a problem and not to seek a solution.

Problem

In the data management space, there are too many third-party vendors that are trying to solve multiple problems. In the early days of my career, I would go to a vendor, learn what they had to offer, and then go back to my team assessing if their solution would match our needs.

Soon I learned how mistaken I was. Instead of approaching vendors from a problem perspective, I was approaching them from a solution perspective. I would allow vendors to imprint their solution in my understanding of the problem. In a nutshell, I looked at how our needs would fit into their solution and not how their solutions would match our needs.

Actions taken

Early on, I would attend webinars and events where I would go into conversations with vendors. I would try to learn what they could solve and how I could make their solutions part of our ecosystem. However, I soon realized that no vendor was able to solve everything we needed. Working with Engineering helped me understand that I needed to identify our problems first. That was an Aha moment for me -- rather than approaching vendors from a solution perspective, I started to approach them from a problem perspective.

I started to collect problems encountered by different teams. Teams were eager to share their extensive list of problems, which I analyzed with great care. After studying the problems minutely, I focused on identifying cross-cutting commonalities. By digging deeper, I realized that those commonalities stemmed from the same root causes. If appropriately addressed, solving root causes could help solve problems internal stakeholders were complaining about. Sometimes we had to solve root causes internally, and contracting a vendor would be of no use. Making that decision alone -- should we solve it internally or externally -- spared us from having to spend time and pay for something we should do ourselves.

The whole process triggered a mindset shift that helped us better understand our needs and capacities to solve them. It also impacted our decision when and how to approach vendors and what to ask from them.

Lessons learned

  • Vendors tend to promise too much. Rather than being mesmerized by their solutions, be mindful of what problems their solution could address. Don’t go to a vendor to learn about their solutions and how you can incorporate them into your ecosystem. It should be the other way around.
  • Attending webinars and events and learning what vendors can offer is useful but don’t spend too much time on it. There are too many vendors out there with too many solutions. Without knowing what you need, it would be a waste of time.
  • Be the person who is open to collect all the information before embarking on the solution quest. Unless you understand the whole picture, trying to solve fragmented problems hardly yields results. Sometimes, applying a partial solution can add to the confusion and push you further from finding a solution that can address the root causes.
  • Being an early adopter with a third-party solution often becomes problematic. With no tried-and-tested team, you may end up being their guinea pig. Ensure your team is included whenever any decision with a third-party vendor is considered. .

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

The Art of Asking Why: Narrowing the Gap Between Customers and Users

24 May

Jord Sips, Senior Product Manager at Mews, shares his expertise on a common challenge for product managers – finding root causes and solutions.

Customers
Innovation / Experiment
Product
Personal Growth
Leadership
Stakeholders
Users
Jord Sips

Jord Sips

Senior Product Manager at Mews

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

Why You Should Take Technology Risks in Product Development

25 April

Matias Pizarro, CTO and VP of Residents at ComunidadFeliz, recalls a time in his early career when he took a technology risk that had wide-ranging benefits to his product's user experience.

Innovation / Experiment
Product
Scaling Team
Dev Processes
Matias Pizarro

Matias Pizarro

CTO and VP of Residents at ComunidadFeliz

Identifying Individuals for Career Growth Opportunities

22 April

Jay Dave, Sr Director Of Engineering at Synack, shares how he has learned to identify team members for promotion by observing their interactions with non-engineering leaders and how they handle stress.

Handling Promotion
Personal Growth
Sharing The Vision
Retention
Stakeholders
Jay Dave

Jay Dave

Sr Director Of Engineering at Synack

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.