The Top 5 Skills Of A Great Tech Product Manager

There is no standard day in the life of a tech product manager.

Your day-to-day tasks depend on where you are in the product lifecycle. One second, you might be researching the market, while another, you are meeting with engineers to discuss a technical problem or user testing.

While exact tasks may vary, there are some skills that apply at almost every stage of the product lifecycle.

Here are the top 5 skills of great technology product managers:

1) User Focus & Empathy

This skill is number 1 and that’s not an accident.

As product manager, you need to be the champion for your end users — keeping users in the back of your mind at all times. Do whatever it takes to get this done. Work with the marketing, sales, or customer experience departments in your organization or, even better, directly interact with users to understand high priority pain points.

Nominally, you are a product manager, but, since your users are so important, you are actually a process manager when it comes to them.

Build a process to learn what product features your users need. Validate your theories when it comes to end users. Set-up the right communication channels to get user feedback regularly. Pay more attention to users’ behaviors than users’ words, though take both into account.

Conduct effective market research. Know when a specific user problem is indicative of a larger market trend. Get good at conducting surveys and at interviewing users. If you are not a product user yourself, it is even more imperative that you listen to your end users. If necessary, ask users if they are willing to pay for your product or, if the product already exists, pay more for additional features.

The number 1 reason why software engineers fail to make an effective transition to product management is because they build products and features that are impressive (to other engineers) but that don’t solve highly prioritized end users’ problems. Don’t be that engineer!

One of my former clients used to say the following about products:

“Build me a Chevy that gets me to my destination and not a flashy Lamborghini with no engine.”

The car analogy is silly, but the message is clear: prioritize solving real user needs instead of building fancy products that do not. He meant it too.

2) Strong Technical Knowledge

If item 1 is a potential pitfall for software engineers transitioning to product, then item 2 is a strength for them. If you do not have a technical background, spend time developing your technical knowledge.

Technical knowledge is important to bond with your engineering team. And empathize with them. If your engineers feel that you don’t understand them, it becomes harder to plan and execute product features. You will proclaim your big picture ideas to the team and then wonder why features are not getting finished on-time.

Then, you will have to explain to both your internal leadership and your end users why features are not ready as promised. The worst part is that you can’t articulate WHY the features are not done because you don’t understand yourself, and then you will lose credibility.

The best way to learn tech is to code yourself — learn by doing. But, at a minimum, you need to talk tech. Be able to answer questions like: What is our architecture diagram? What is O(n)? What are some ways to improve application performance? Why use Docker? What is the difference between orchestration and provisioning servers? What is machine learning? How is data being processed and stored? Why did we chose this database and not another? What are our security needs? What is the difference between authentication and authorization? What is our version control process? Do we have a CI/CD pipeline? Do we have production server monitoring and logging? What is a load balancer? How is our server load? What is an API? How efficiently is our backend sending data to the frontend?

These are questions that your engineers can answer. As PM, you are more visionary and less hands-on in the technical realm — technical decisions should be left to engineering. And while your primary focus should be on your users and market, the more you know technically, the easier you make your job.

3) Organization & Planning

Good organization & planning skills are critical.

Set goals and targets for each sprint. Be ambitious, but build in a margin for error. Remember to include time for designers to design features and for feature testing and not just for engineers to code features. Consider the entire product lifecycle during planning.

Anticipate blockers that your team will experience during sprints. If an engineer can’t proceed without getting approval from a designer, or an engineer needs specialized training to build a feature, that’s on you to make happen. Otherwise, the project will come to a grinding halt and you will have to deal with these issues in real-time, and when no progress is being made. No bueno.

Leverage management tools like Kanban/Jira/Trello. These tools can help with product roadmaps, so you can assign a timeframe for feature completion. You can also aggregate your user stories into themes and epics which also helps with planning, prioritization, and managing backlog. Use these tools to get on the same page with your team and keep these processes fluid.

Speaking of getting on the same page with your team, set up the necessary reoccurring meetings ahead of time. Certain meetings are inherent in the agile process - planning meetings, daily touchpoints, and retrospective meetings. However for some others, you may need to be more proactive. If you always need buy-in from someone in your organization at the same time in the product lifecycle, get that meeting on the person’s calendar way ahead of schedule.

In my experience, one of the most important planning skills is managing expectations. If internal leadership and/or clients expect a feature to be done, and something unexpected disrupts deadlines, the best thing to do is let key stakeholders know as early as possible. People don’t like bad surprises. Good surprises…now that depends on the person.

4) Data & Hypothesis Validation

If you are a product manager, use your data and validate your hypotheses.

Even visionaries need to validate their hypotheses! You can (and should) have grand ideas for how to build features to solve user problems, but, at the end of the day, it is your users’ opinions, and not your own, that matter. More specifically, it is your users’ behaviors that matter.

Monitor and track your important metrics actively, using tools like Google Analytics and SQL. Some important metrics to track include customer acquisition, customer acquisition cost (CAC), customer lifetime value (CLV), customer activation, usage metrics, retention, revenue, and referrals. Set goals for key metrics, and determine which one(s) are the priority at any given time.

Before adding features to the task management board, validate that they solve a high priority problem with your users. Before coding features, validate designs and mock-ups with end users. Before deploying features to production, test that they work. Use A/B testing and metric monitoring to validate that new features have actually improved the product.

Be agile. Learn… then iterate!

5) Stakeholder Engagement

Be proactive to engage key external and internal stakeholders. Be outgoing!

Get buy-in from all relevant stakeholders. Essentially, you need to be able to represent the perspective for all stakeholders, and especially if stakeholders are unable to attend key meetings.

Involve designers and engineers early in the product cycle. Learn the preferences of your internal leadership, so you can anticipate when they expect to hear updates and weigh-in. If you don’t directly engage users, collaborate with stakeholders in your organization who do, e.g. sales, marketing, customer experience, etc. Engage all other necessary parties, e.g. ops, PR, legal, etc.

As product manager, it is your job to get everyone excited about the product. You are the product champion, but you are only as strong as your team. The best ways to create excitement are by good story telling and showing appreciation. Remind your coworkers how they are contributing to the bigger picture with each release. The WHY. And show that you value their efforts.

Thanks for reading :P