How technical a product manager should be

From the early days of Microsoft, where you couldn’t be a PM unless you coded, to Amazon, which puts MBAs above Computer Science majors, there’s no standard background for product people.

But for thousands of sprints, the question has haunted (or at least intrigued) people working in product: How technical do you really need to be?

After our AMA event with Damien Peters, product manager at Facebook, we followed up with him to ask all the questions we couldn’t address during our live event. 

In this rapid fire Q&A, Damien talks about how to navigate a career in product management, no matter where you fall on the technical to non-technical spectrum.  

The Signal: What are the early signs that a product is on the right track to succeed?

Damien: Simply, people using the product. Adoption and retention are the only things I trust early on. It doesn’t guarantee adoption at scale, success, or real product market fit, but if your target customer is unwilling to adopt, something probably needs to change.

The Signal: Do you think being an engineer too long before entering a product role creates ‘tunnel vision’? Often working in engineering prevents people from being able to view the business sides of a product. 

Damien: Yes. However, it’s not being an engineer for “too long” that causes issues. When I was in engineering, I focused too much on how difficult something was to build, compared to thinking now where I ask what does my product do and who uses it. It’s a big distinction that many miss when coming from engineering.

The Signal: How do you prioritize user feedback when considering what to build next? 

Damien: This is a fine art. There is a balance between what users are telling, what they are asking for, and what will actually meet their needs. While I was in gaming, the number one requested feature was “more free coins”. And in other products, I’ve had vocal minorities who may ask for power features or deeper control. These product updates would be expensive, costly, and would only impact a small portion of our users. But, ignoring user feedback isn’t an option. They are the people you are working for and who determines success.

I’m a big proponent of customer service and community management as a way to filter and highlight important pieces of user feedback. I use this as one of many inputs in prioritizing and planning.

The Signal: For someone who has worked on the commercial side of the business (sales and acquisitions) what would you recommend to someone who is trying to leap into product management?

Damien: Sales into PM, in my experience, can be one of the harder transitions. I believe this because the skills in sales can be much different and at conflict with PM (e.g. not over-indexing on your vocal clients). Those I’ve seen succeed have either worked directly with PMs or as close to the product as possible. Also, never forget the value of building something outside your current job to build the prerequisites. In addition, you always want to articulate clearly why you are making the switch and why you have a strong product sense that transcends from typical sales roles. 

(Note from the editor: Making the switch from Sales to Product Management? Check out what Vox Media’s Heather Savatta says about her transition.)

The Signal: What advice would you give to someone who went from managing enterprise projects to being a partner in a startup and fulfilling the role of “product” manager?

Damien: The same advice I give all new product managers. Here are five major insights:

The Signal: How do you feel about the divide that the product manager controls the what and the engineering side owns the how? Do your product teams have this separation of duties?

Damien: Every team is different. I try not to apply one working model for all PMs and all products. Some cases my past experience means I know a lot about “the how” and spend a lot of time in the details, even on very technical aspects of implementation. Other times, strong leadership in engineering or project (not product) management allows me to focus solely on “the what.” At the end of the day, it’s all your responsibility so I’m hesitant to tell anyone to ignore large areas that are needed for success.

The Signal: You mentioned about picking what language a mobile app would be written in, and why a PM should be involved in that decision. Can you speak to that more?  

Damien: It’s a core decision that impacts the long-term success of the product. You should care and have a say in the decision.

For example, using a new framework to write once and launch both platforms at the same time sounds great for getting started and keeping costs down. But, lack of support or performance may give you long term costs not worth it. Understand the trade-offs and help make the decision. You are ultimately responsible.

The Signal: Can you talk about how your PM teams structure your product roadmap? How far ahead do you look, and how do you balance short term needs with long term vision?

Damien: As always, it varies by product. I’ll use one example from a previous team. There were 3 main components, front-end, backend systems, and machine learning.

Front-end required more coordination across different teams (design, marketing, community, back-end, etc) and would have shorter sprints with more communication to handle the dependencies. This roadmap was more detailed, had more steps, and a lot of definition.

Backend was a smaller team, and could work on larger products with fewer intermediate milestones. This roadmap had fewer larger products and the engineering team had more freedom because of less dependencies.

Machine learning could be one month versus one year to get the results we needed, along with a lot of coordination across the company because of a reliance on larger platforms. This roadmap was the most loose, with a lot of variance in time, and the project was defined by performance, which could be a moving target.

I haven’t found a one size fits all approach, but generally we use sprints between two to four weeks and plan on a three to six month basis. I aim for seventy percent of work to focus on the core goals, twenty percent to be near-future thinking, and ten percent on crazy big bets that usually fail.

The Signal: As a product manager how much of a product’s data analytics or strategy are you involved in?

Damien: All of it. It’s one of the areas I spend the most time on. How much time depends on where the product is. A new product may need a lot of strategic thinking, where something in growth mode needs a lot of analytical focus.

The Signal: How much UX design should a PM be doing?

Damien: As much as is needed to have a great product. When I didn’t have a designer, I did the mocks myself and spent time getting a designer. When I did have a UX designer, I worked to ensure cohesion and purpose across our designs.

The Signal: Can you share your greatest PM lesson from your specific work at Facebook?

Damien: I learned the discipline of flawless execution. If you have sloppy execution, and you fail at hitting your marks, you won’t know if the strategy was wrong or if it was execution. Great execution removed one big variable when determining what went wrong. That’s the key to optimize for success.  

The Signal: How do you manage user stories/work for Front End and Back End developers as a PM?

Damien: When I have strong engineering leadership, so I trust my engineering manager or the project manager to lead it. When I don’t, I manage it personally.

The Signal: In your career what was your greatest source of growth? A mentor? A manager? A side project? Reading?

Damien: The answer for me is definitely colleagues. Product management is a relatively new field and is extremely nuanced. Learning from doing, and others who have also done so before, has been the most effective from me personally.

Want to learn more from Damien? Check out his personal blog along with his latest project, Wealth Noir, a financial literacy community for black millennials.