Being a Non-technical Product Manager (PM) Is an Asset. Here’s Why…

There’s a common assumption in the tech industry that product managers need to have a technical background. Many product managers, after all, started in development.

Certain technical skills are great assets to product managers. But they aren’t the whole picture.

Product management is not a technical role. It’s a business management role that’s facilitated by certain kinds of technical knowledge. And most of the skills that make you an effective product manager are unique from the ones that make you an effective developer.

I know this from experience. I made the transition from a customer success role to product management, and my non-technical background turned out to be more of an asset than I was expecting. In this article, I am going to share with you a bit about my journey and why I feel my non-technical background was an asset when becoming a product manager.

Starting out as a non-technical PM: Getting thrown in the deep end

I wasn’t planning on a career in tech. But after completing my MBA and stumbling into a role in customer success at ZenHub, I found myself falling in love with the sector. I loved the fast pace, how we were always doing things for the first time, and that there was no set way of working – you had to figure things out on the fly. Working at a tech startup, I found out pretty quickly that small teams mean all-hands-on-deck. I picked up some product-related responsibilities, then I became a product manager and leapt in headfirst.

In the early days, my biggest challenge was my lack of confidence in my technical skills since, in short, I didn’t have any. I had trouble understanding where my role ended and where others began:

• What should I be delegating versus doing myself?
• How prescriptive should I be with the team?
• Is it enough to tell them what the features need to do, or am I also supposed to know how they should implement them?

Meetings with the team were sometimes a blur of jargon I couldn’t follow, and I wasn’t even sure how much I was supposed to be following.

Because the team doesn’t report to me, I needed their buy-in: I needed credibility.

How a non-technical PM can find expertise beyond the development process

To start, I had to ditch my ego. “Don’t be afraid to look stupid,” was my mantra. At one point I offered a lemon loaf to anyone who would sit down and explain what an API was to me. Pro tip: you probably don’t have to do that.

But I needed to build a relationship with the team. Without technical experience, that required a lot of brutal honesty about what I knew and didn’t know.

At first, every time I heard a technical term I didn’t understand, I wrote it down so I could Google it later. But after going down numerous rabbit holes of technical jargon, I realized a lot of it wasn’t useful. I didn’t need to know all this stuff to understand what the solution is and what its implications are.

Things like understanding the sprint cadence, the QA process, the release cycle, and the basics of Agile were super useful for me. But all that jargon and a deeper understanding of the ins and outs of the development process weren’t.

It would’ve been naïve and, frankly, a bit egotistical for me to think I’d have as much technical knowledge as the development team. So, I respect their expertise, and I found my expertise elsewhere. I’ve taken Agile courses and spent a lot of time learning about good communications, how to run projects effectively, and how to release betas: that’s what I can bring to the team and where I can contribute.

Non-technical product managers can find their strengths in past experiences

As it turned out, my experience and education taught me a lot of things I needed to know as a product manager.

I’d taken courses on conflict de-escalation and that sort of thing while I was working in customer success, and I put that knowledge to good use as a liaison for the team. If they were saying, ‘hey, there’s this huge technical issue we have to deal with,’ even if I didn’t understand what the issue was, understanding the extent of the challenge or their frustration made it much easier to handle.

As a product manager, I have to walk the line between a team that wants to build the best product possible and a business that wants something yesterday. My MBA taught me the importance of tradeoffs and iteration. My manager says, ‘we hire the best people who want to do their best work and build the best code, and we ask them to build an imperfect feature because of time and resource constraints.’ My job is to look at all these constraints and say, ‘what’s the good-enough feature we can put out there?’

Sometimes there’s a conflict between the technical and business sides of an organization. I work very closely with the technical side, and I love the team. But I can also empathize with the business side, and being a go-between is kind of my role in a nutshell.

Lessons for prospective product managers (technical and non-technical)

Whichever side of the coin you come from—business or technical—find out more about the other side. If you have a technical background, spend time learning and relationship-building with the business side. If you don’t have a technical background, you probably have relevant management skills, but might need to pick up a few things. Remember that you need to manage a development team, not be a developer yourself.

Find your product management niche and focus on it. If you have an excellent grasp of nitty-gritty tasks like writing specifications, then leverage that. I’ve taken quite an interest in metrics analysis.

ZenHub’s reporting tools were really helpful for this. I was able to get a better understanding of sprint velocity and why it’s important to be predictable and tackle the same number of story points every week. And the burndown chart shows me sprint progress in real-time. The ability to see how the team breaks down the work I give them helps me understand how they’re thinking about it and how the back end and front end work together. It also gives me great ideas for questions to further advance my understanding.

Finally, make sure to listen and ask questions. And know when to interrupt and ask for an explanation: chances are, if you’re hearing something over and over, whether it’s technical jargon, business jargon, or something else entirely, it’s probably important.

While I wouldn’t say my lack of technical skills was an asset for the role, it did help me focus on the outcomes and implications of the team’s work rather than getting lost in the weeds or stepping on their toes by trying to be a developer.

Learn more

My previous role in customer success also taught me many things I couldn’t get into here, but I wrote a blog about it. And if you’re looking for ways you can make a dev team even more effective, check out our blog on 5 key developer metrics.