Confessions of a Non-Technical Product Manager
My friend Matt was helping a client adopt a more agile software product development process. His first question to me was “How do we test a product manager applicant’s computer science chops?” To which I replied, “Who says your PM has to code?”
As a “non-technical” product manager and entrepreneur who has overseen the development of many projects from mobile games to multi-platform marketing campaigns, I get variations on this question a lot. Some employers and clients fear that PMs who don’t code won’t be able to communicate properly with their dev team.
Of course every project is different, but the two roles require very different skill sets. Personally, my lack of formal computer science training has never held me back, and can often be an asset. Here’s six tips for current and aspiring PMs who don’t code:
1. The Product is the Boss
A good PM is a leader, but is not a boss. The product is the boss. Now here comes the corny business book truism: your top priority at work is to make your boss look good. Your job as a PM is not to bark orders at designers and developers, nor is it to be subservient to them. Rather, you are there to communicate effectively with the entire team including executives, marketers and sales people, to make sure the product is great. A truly great PM keeps the team focused on that common goal and helps determine the best path to get there.
2. Tell A Great Story
In user-focused design and development, we can think of each feature as a “story.” When a PM describes each development task, she is essentially writing a story that will lay out the scenarios and requirements that allow the developer to dive in and formulate a solution. It’s important to remember that although the PM must define success, she doesn’t need to know the exact path to get there. In fact, good story writing is not technical at all. It is a unique language that bridges user needs with desired outcome; developing this skill requires empathy, attention to detail and systematic thinking. Tell your team a great story and they will come back with the technical requirements and functions that bring it to life.
3. Be Available
Writing a good story is an important first step, but your job as a PM doesn’t end there. You are an integral member of the team and you must be available to facilitate, translate and communicate. Need a better feature description? Rewrite it and make sure everybody is on board. Having a communication problem with a team member? Fix it ASAP. Don’t hide behind Gannt charts or shift the blame when challenges arise. Tackle things head on, with your team and listen to them.
4. Ask Questions
I’ve never worked with a developer who wasn’t able to easily diagram a stack for me or describe how an important sub-system works. Most of the time, developers are excited to share their knowledge. You just have to ask. This understanding is an advantage that PMs with a CS background bring to the table, but it’s a skill that a non-technical PM can easily develop. The more of this knowledge you accumulate, the better you’ll be at predicting how long things will take and this will help you and your management team prioritize. In the meantime, you have options. Bring a developer into planning meetings to contribute or avoid committing to timelines without consulting the team.
If you walk away from a technical conversation a bit confused, jot down the bits you understood and the things you didn’t , then research it on your own later. It’s probably not imperative that you understand a complex dev system now, but a better understanding may help inform a conversation or decision in the future.
5. Speak Up!
You may not know the ins and outs of C++ or how to whip up a web app in a couple hours using Ruby on Rails. But don’t underestimate the value of your own experience and common sense. Even the best developers need help sometimes. And a good PM can be a trusted collaborator to bounce ideas off of.
When a developer asks me to help with a technical problem, I start by discussing the feature from the user’s perspective. Then I transition to the developers point of view. Is the basic logic sound or are there holes in it? Is there a more simple way to get the same results? Is it built on, pulling from, or sending out to other parts of the application? You’d be surprised how valuable your new perspective can be. Sometimes just identifying the trade-offs with technical decisions can help your developer choose a direction to best move forward. Code isn’t the only language developers know. Every feature is a series of rules that follow a system of logic that can be discussed in plain old English. (Or in diagrams, visuals and even emoticons if your coder doesn’t speak English! Which I’ve also experienced.)
6. Listen
Just as you may be able to inspire a coding solution for your developer, every team member can inspire product solutions. Encourage the entire team to volunteer feature ideas, share cool new capabilities, voice insights from data that may have been missed and find easy wins. Being a good listener and making sure everybody is comfortable sharing their ideas will ultimately be a huge benefit to the product. And you definitely don’t need technical training for this skill, which may be the most important one.
