On Product Management

How to be a GREAT Product Manager (part 2)

Be technical, without becoming a technologist

Product Managers need to focus on the “what”, and not the “how”. The charter of the PM is to define what needs to be done to make the product better, faster, stronger, cheaper etc.

The “how” of doing those things is left to Engineering or Senior Management to figure out. OK, it’s not exactly that simple. Sometimes Product Managers have to worry about the how, but usually in the context of an implementation discussion with Engineering or resource allocations with Sr. Management.

But, thinking about the how during the requirements phase can be fatal for Product Managers. Don’t fall into the trap of putting yourself in engineering’s frame of reference until and unless it is absolutely necessary. I’ve seen this happen with technically savvy PMs who decide (prematurely) that a requirement won’t be presented because of a technical constraint in the current code base. Or that during a requirements review, an important requirement becomes less important because of the same reason.

My question is why would you, the Product Manager, even worry about that if the requirement is sufficiently important? The requirement should be clear and compelling. Challenge the engineering team to come up with a solution, or work with them if your guidance is needed, but don’t give in because of technical reasons.

Market and customer needs, not engineering constraints should be driving requirements. But given that many product managers are themselves former engineers, or come from highly technical backgrounds, it can be difficult to stop from crossing the border into “the Implementation Zone”. Once that happens, if you don’t catch yourself, you’re doomed, because it can be difficult to cross back.

I worked with a product manager, fairly young and much more technical than I, who would not only talk about the requirements, but then debate potential solutions in a requirements review meeting. Given that he had a technical background and didn’t spend much time talking to customers/partners/prospects etc., what else could he provide? Needless to say, his tenure was short-lived.

When it comes to implementation, if a requirement is important enough, but you face resource or technology constraints, most rational organizations will figure out how to do the right thing as long as you present the case sufficiently. I say “rational organizations” because not all organizations are rational; at least not from a business perspective, and will not necessarily do what’s right for the market. If that is the case in your company, then it may be time to find another employer, so can advance in your career and your energies and knowledge can be put to good use.

Saeed

Part 1 – Don’t just sound smart, act smart and be smart

Part 3 – “Spidey-sense” instincts are good, hard data is way better

Related posts:

1. How to be a GREAT Product Manager (part 6)
2. How to be a GREAT Product Manager (part 1)
3. How to be a GREAT Product Manager (part 5)
4. How to be a GREAT Product Manager (part 3)
5. How to be a GREAT Product Manager (part 4)