Technical Product Manager Tips

Are you a product manager with a technical background? Do you constantly find yourself getting dragged into tactical roles like giving demos or providing feedback on design approaches? Are you getting shut out of strategic conversations about value and objectives and “business drivers”? Or do you think on your feet and perform scintillating feats of business to developer translation (and vice versa)?

Read on for some tips about what to avoid and how to leverage your technical chops effectively.

A Real Concern

Back in February (2008), over the course of a few days, I had a great conversation with a reader (and commenter – thanks again!) that addressed some of the challenges of being a product manager with deep technical skills. In late March of this year, the Silicon Valley Product Group included a topic in their newsletter (and on their blog), Moving From Engineering to Product Management. The author of that article provided some great tips on communication dynamics for a geek-turned-PdM. Today, we’ll pull those ideas together, and add some more, in the form of tips to help product managers who happen to have technical acumen.

First, let me go on record as stating that you do not need to have a technical background to be a great product manager. One of the better ones I’ve worked with had a background in history. MBA-centric, business-savvy, non-technical product managers succeed all over the place. Also – a technical background, even for product managers in high-tech industries, is not a guarantor of success.

Technical Product Manager Salary Data

Last December, we analyzed the salary survey data from Pragmatic Marketing’s annual salary survey of product managers. In that analysis, we found the following:

[Click for larger version]

Conclusion

Technical product managers, at least the more senior ones, are paid less than non-technical product managers – when looking purely at titles. However, product managers with technical skills are generally paid better than product managers without them. One interpretation of the data might be that while technical skills help you earn more in any product management role, the technical product manager role generally earns less – perhaps due to perceived scope of responsibility or impact.

Note that there are two “technical product manager” variables. One is the self-reported level of technical expertise (from non-technical to very-technical), the other is job title (where the choices were product manager, product marketing manager, and technical product manager). The linked survey analysis includes more details, analysis, and perspective.

If we believe that success for product managers will correlate with compensation for those product managers, then we can conclude that a technical background can help you be a more successful product manager (ignore the PMM and TPM data), but only after 10 years of experience. Perhaps it takes time for technically-oriented product managers to absorb the important soft skills.

SVPG Tips

The SVPG article on moving from engineering to product management is a good one. Read it for more details. In short, the author suggests half a dozen tips, all of which are important, to an engineer in a product management role. Also note that the article author also believes that this is a potent combination:

In any case, many of the very best product managers I have ever known have come from engineering, and in this article I’d like to call out what I’ve found to be the main challenges for engineers as they make this move.

Realize that engineers have a big advantage in that they generally have a deep understanding of what’s just now possible. If they can now combine this with a deep knowledge of the user, and develop some new skills, you’ve got the makings of a great product manager and great products can result.

SVPG Tips (paraphrased and shortened here, and links are ours)

1. Realize that you and your users do not think the same way.
   

   “Cooper calls programmers homo-logicus, to distinguish them from actual human users. Because programmers understand how computers work, they have very different expectations than everyone else.”8 Stages of Corporate Usability Awareness

2. Develop empathy for your users (remember, they aren’t engineers.
3. Don’t focus on (your old job of) optimizing developer utilization – focus on optimizing user experience.
4. Develop humility – people won’t always react to your product ideas the way you would like.
5. Refine your argumentation style to deal with unclear situations – there is not always a right answer.
6. Don’t fall into old habits when it comes to working with your engineering team – let them do the engineering.

A Real World Example

Here’s an edited (to protect anonymity, and to focus on having technical skills and product management) version of the exchange I had with our reader.

Product Manager

I really enjoy product management work, and am very strong at building relationships with customers and across teams. But, because I have a strong technical background, and because of where our company is, my responsibilities are shifting much more to what Pragmatic calls a business analyst role — more emphasis on product specification than on product strategy.

I’m trying to build a personal brand. Initially, I resisted the idea of moving back to a more tactical role, but it appears that you cross the line between business analyst and product manager pretty freely. Maybe being known for having strong technical chops is not all bad. My current role is my first as a product manager on the software vendor side, so I could use some perspective.

Scott

Having technical chops has proven to be a huge asset for me, although it comes with some risks. Every software project requires a continuum of thought – from “what is the problem” and “why is it valuable” to “how do we do it.” As product managers, we have to focus on the value and our company strategy. It is the big picture decisions about choosing what problems are worth solving that is the “dog” and it is software design and implementation that is the “tail.”

Making the right strategic decisions requires us to understand both the value of the problem and the cost of the solution – it truly is ROI. It makes more sense to develop a $5m solution to a $10m problem than to spend $99m on a $100m problem. All product managers, have to be able to articulate the importance of the problem – and we can do that with a minimum of technical depth. Where technical depth helps here is in identifying that there are solutions that reduce the size of the problem (think of it as opportunity cost). We can validate effectively.

For example – if companies spend 10% of their revenue on order processing, that is a very large opportunity. And if our target market is companies in a vertical – say medical claim reimbursement, with an characteristic revenue of $100m, it is a $10m problem for each of them. However, with technical chops, we can appreciate quickly that there is likely to be a $100k solution out there already. By decomposing the problem, we can envision stitching together some open-source software to “essentially solve the problem.” This means that while there may be a $10m (per customer) need, there is really only a $100k sustainable solution. The same conclusion might be reached without technical chops by knowing that there’s a vendor who solves a similar problem in the computer industry (perhaps for rebate processing). Either way, we get to vet the size of the problem from the perspective of how easily someone could conceptually solve it. That prevents us from building a $5m solution which will be quickly displaced by someone else.

Technical depth is more easily leveraged when looking at costs and feasibility of solutions. We have to not only validate the importance of the problems we solve, but also validate the feasibility of solution approaches. We have to communicate both with our customers and with our implementation teams. My experience has been that I can leverage my chops both in gaining credibility with the delivery teams and in facilitating much more efficient conversations with those teams. And I can be more confident that they know what I’m asking, and I understand the responses. It has occasionally helped that I can “seed the cloud” in those conversations with “can this type of approach work?” questions.

I’m not saying that I specifically took on the role of design, just pointing out that the conversational ideas have occasionally helped the implementation teams have their own great ideas. And helped me form more effective relationships.

When playing the role of “demo boy” or otherwise on a customer visit, technical depth helps again. There are often “gate keepers” and “influencers” with technical backgrounds who are in the room during RFP/RFQ responses. They occasionally will challenge the technical approach of an application, or express why “their problem is too hard” or “doesn’t match.” When they are right, I can help us reach the same conclusion, and decide if it is time for more features, or different customers. And when they are wrong, I can help them understand too – and leverage them as people who pass along a “their product will work for us” message internally (to their employer).

I mentioned earlier that it is risky. The risk is that I over-emphasize the technical work, or even prioritize it above anything else. Strategic product management is what we have to do – and Pragmatic is right – if we don’t do it, who will? Because we can answer technical questions, there’s a risk that we are continuously asked them. What seems to work for me is to leverage my technical chops only in two ways:
1) to improve my understanding
2) to communicate with technical people

I actively avoid flexing my tech-chops in conversations with non-technical people. The risk is that they start to rely on me.

Technical Product Manager

A lot of your thoughts ring true to my experience, too:

• There have been several times when I have been able to use the technical skills to, as you say, “seed the cloud” with ideas about possible solutions. Sometimes the idea sticks; sometimes there are good reasons why it wouldn’t work. Whatever the outcome, the interchange is fun, and in the end, we all understand better why we’re choosing a particular path from a technical standpoint.
• Good point about the “risk” of showing the technical skills. In times that I have gotten too technical with non-technical people, I find it’s really easy to be pigeonholed as a purely tactical tech guy. Then, when you build a reliance on those technical skills, it’s hard to move beyond that with that person.
• Your examples about sizing problems and solutions are intriguing. You’re putting the emphasis on solutions that provide a sustainable advantage. Competitive barriers to entry are defined by the most cost-effective solution to the problem at hand. Our job as a PdM is to find not only a solution to the market problem, but the most cost-effective solution to the problem. Probably an obvious point, but I hadn’t thought of it quite that way in terms of barriers to entry and sustainable competitive advantage.

My role will be to focus more on execution — to make sure we understand the requirements well, all the way from understanding the market problems down to use cases and wireframes. Priority #1 for the company at this point is to get our platform stabilized, and a big part of that is to be very clear in our requirements. I’ll participate in the broad-strokes prioritization discussions, but my focus now will be more on executing on those priorities, than on prioritizing per se. I’ve heard the term “requirements analyst” applied to what I’m doing.

Once again, THANK YOU for your thoughtful response. We’ll keep up on your blog!

Scott

Thanks again for a great discussion, and for having your folks read Tyner Blain – that still blows me away.

And thanks to you for reading at Tyner Blain – it humbles and excites me every day. Seriously. Thank you.