Being Right is Not Enough

This article was originally published in Agile Insider on Medium on Feb 7, 2018.

“This isn’t what we asked for,” the director said, indignance in his voice. “They have to fix this. I want our team to make a list of all the changes we need.”

I was sitting in a conference room, discussing the state of a million dollar software project which had just been delivered for acceptance testing. The project had started with hundreds of pages of documentation, followed by nearly a year of “on track” status updates. Once we could finally test the software, the director was livid to see that it didn’t match his vision. And he wanted his team (a team of environmental engineers, not designers) to redesign it — after it had been built and the budget was nearly spent. Talk about scope creep!

I tried to tell the director, the assistant director, the contract manager — anyone really — that this was a bad idea. We should get it in front of real users first, I argued. But no one wanted to listen to me. Instead, the director put other associates on the task of building their own wireframes from scratch. They spent endless hours on learning to use wireframe software and creating new designs, which resulted in change agreements and more money spent. And did I mention that this was a government project? These were taxpayer dollars!

I started looking for a new job not long after that.

I also did a lot of soul-searching. I had learned through years of academic achievement that being correct was what mattered. This experience brought home for me something I now tell product managers regularly:

It’s not enough to be right. You also have to be persuasive.

But how? What if I told you that I’ve been testing and refining a step by step process for driving evidence-based product decisions that set products and product managers up for successful growth?

You might not believe me. So I’d like to tell you another story.

This one takes place years later. I’d just joined Shutterstock as the product manager for Skillfeed, an online education platform. As I asked more of my new colleagues for their perspectives, I discovered that before I was hired, some of them had argued, unsuccessfully, for shutting it down — and they may have been right to do so. But they hadn’t been persuasive.

If I approached this the same way, I would have failed this time too. So I had to do something different. I had to put energy towards not just the problem, but also the people around the problem.

It was a slow and gradual process. I started with empathy for the decision makers. I put myself in their shoes and learned as much as I could about why they supported this project, what they thought it could do for them and the company, and what objections they had when others had tried to change their mind. I went out and gathered evidence, shared new insights, and asked follow-ups. I didn’t deliver fully-baked thoughts to them from on high; I guided their thinking, let them develop their own thoughts, come to their own conclusions, and convince themselves.

By doing that, I ultimately did something no one else had. I persuaded the billionaire CEO of a public company to kill his pet project.

Since then I’ve found that while the specifics won’t transfer to every new situation, there is a core process to it that will — a process that has worked dozens of times to lead to product and career growth for my teams and clients.

I can’t claim that I’ve never failed to bring others along with my vision and strategy, because I have learned these skills the hard way. But what I can do is tell you what went wrong, what I tried differently the next time, and what challenges to expect along the way.

I want to share what I’ve learned with you so that you can set yourself up for career success. And the next time that you’re asked to execute a feature or product idea that you aren’t excited to add to your resume, you’ll know just what to do.