Back to resources

Resolving a Start-Up’s Dysfunctional Past as Their New Product Manager

Product Team
Conflict Solving
Internal Communication
Collaboration
Changing Company

1 June, 2021

Shubhada Hebbar
Shubhada Hebbar

Director of Product Management at Roku

Shubhada Hebbar, Director of Product Management at Roku, was faced with the daunting task of knitting a dysfunctional start-up back together after poor communication left every single team in shambles.

Problem

I had just joined a new company and was tasked with doubling our product’s engagement within a year’s time. I took a look at the data and knew that the goal was well within our capability. It would require a revamp of the entire product, including new features. This company was a start-up and the founders and the Engineers were very invested personally in what we were doing.

I entered the picture trying to change everything immediately, and emotions, naturally, began to run high. There was a lot of pushback in response to my proposed changes. The existing relationship between Product and Engineering was also very heated; they wanted to build their own tech debts, and there was a lot of actual screaming when the subject was breached, which was shocking to me. Sales was also worried that changing our app would have us losing out on ad revenue. Many of these concerns made sense, but the way that people were handling the situation was not functional.

Before I was hired, the Product team was not as data-focused as they should have been. They just tried to tell Engineering what they thought that they should be doing. There was so much work to be done, and the technical debt was not being addressed in a way that was able to scale.

Actions taken

I was lucky to have my manager on my side throughout this ordeal. They were the one who pulled me in initially and was very sympathetic with me in light of the situation.

I tried going into it with the assumption that all people are reasonable and that some baggage from the past was what was responsible for the issues in communication. I made it my mission to resolve these conflicts. I started talking to everybody in order to understand where all of this resistance was coming from.

One of the things that I found was that Product was not drawing upon user feedback for any of the decisions that they were making. One of the very first things that I did with the UX team was to encourage them to reach out to the many customers already using our app. We tested out some prototypes and ran some studies. Many of our hypotheses turned out to be true. My proposed solutions would, according to our findings, help us to reach our goals.

I then took this data and presented it to the entire company. I showed them how much we were actually missing out on by not introducing these new features. In order to give the users what they were asking for, however, there was a lot of work that needed to be done — the revamp would require many architectural changes.

The founders slowly warmed up to my propositions, but I was still feeling friction in some areas. They needed more data to convince them. How would I be able to show them that all of these changes would make a difference? I showed them a detailed plan charting the execution of the revamp. I pledged to present a demo to them every two weeks, as well as any change in engagement that each iteration was seeing in the preceding four weeks. This gave them a clear sense of every incremental change that we were making and how much of an impact that these changes were having. They were very open to it; data changes peoples’ minds. This was what ultimately earned me their buy-in.

Engineering was a different story. I had set OKRs for pretty much everything that my team and I were doing. Earning the other side of the coin’s trust involved showing Engineering that everybody on the Product end of things was also being held responsible for the work at hand, not just them. As a team, we were all held accountable. We upheld this process through beta, as well.

During our product reviews with users, I made sure to pull everybody on Engineering in. I wanted them to be able to empathize with our customers directly. I wanted them to understand why I was requiring certain tasks in regard to what they were expected to produce. There was always a reason that I was able to share with them. We prioritized everything based on our data. All of the previous rebellion had dissipated. Our efforts became far more constructive and productive.

The Sales team was sold when I was able to show them how our new design would benefit the types of partnerships that would be drawn to the platform, and, finally, I had buy-in across every part of the organization. I was able to shift the company’s cultural paradigm in under two months in this way. In nine months, we had met our goal of doubling our rates of engagement.

Lessons learned

  • The key thing in a situation like this is to stay calm at all times. For the first two weeks or so, I was so worried. People were very upset in a way that I had never seen before in my life. I sat down with many people in the company in order to really understand what was going on. I learned a lot about staying patient and not escalating the situation. I am naturally very restless, but I realized that acting impulsively was not the right way to tackle this one.
  • Understanding why people are behaving the way that they are is also extremely important. Everybody has something that they want. You need to take the time to understand what somebody is asking for and their motivation for asking for it. People will begin to resonate with a leader when they sense that the leader actually cares. When that care is perceived, that’s when the trust comes in. With that trust comes compliance and delivery.
  • Relying on the data helped a lot here. If I had not been as data-oriented in this case, my suggestions would have been questioned. When people are able to watch our numbers improve, they feel good about the direction that the endeavor is taking. Morale goes up and people are much happier to do the work.

Discover Plato

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


Related stories

How to Maintain Happiness: The Underrated Aspect of Creating Team Dynamic

2 August

Jonathan Ducharme, Engineering Manager at AlleyCorp Nord, encourages the importance of a workplace environment that cultivates mental wellness.

Personal Growth
Company Culture
Leadership
Internal Communication
Psychological Safety
Jonathan Ducharme

Jonathan Ducharme

Engineering Manager at AlleyCorp Nord

How to Organize, Manage, and Grow Your Team

12 July

Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.

Managing Expectations
Delegate
Collaboration
Roadmap
Strategy
Vineet Puranik

Vineet Puranik

Senior Engineering Manager at DocuSign

(Re)Organizing Your Teams Using Domain-Driven Design

12 July

A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Alignment
Architecture
Scaling Team
Building A Team
Internal Communication
Reorganization
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

How to Navigate Your Manager Role at a New Company

1 July

Saikrishna Desaraju, Engineering Manager at Marks & Spencer, draws from his personal experience to advise new managers on thriving in their roles.

Managing Up
Managing Expectations
Leadership
Collaboration
New Manager Of Manager
Changing Company
Saikrishna Desaraju

Saikrishna Desaraju

Engineering Manager at Marks and Spencer

How Product Marketing Can (and Should) Help Product Development

20 June

Pavel Safarik, Head of Product at ROI Hunter, discusses the frequently overlooked role of product marketing in getting high user adoption rates for your product.

Goal Setting
Product Team
Product
Different Skillsets
Cross-Functional Collaboration
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter