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

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.