Damien Peters on how technical a product manager should be

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.

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.

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.

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. 

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

Every team is different. I try not to apply one working model for all PMs and all products. In 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.

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.

As always, it varies by product. I’ll use one example from a previous team. There were three 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.

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.

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.

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 optimizing for success.  

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 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 for me personally.

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