How to be a GREAT Product Manager (part 2)

Be technical, without becoming a technologist

technical-presentations.jpgProduct 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.


Part 1 – Don’t just sound smart, act smart and be smart
Part 2 – Be technical without becoming a technologist
Part 3 – “Spidey-sense” instincts are good, hard data is way better
Part 4 – The 4 Cs of Leadership
Part 5 – Be an integrator, translator and communicator
Part 6 – Own the product from conception to completion and beyond


5 responses to “How to be a GREAT Product Manager (part 2)

  1. Pingback: How to be a GREAT Product Manager (part 3) « On Product Management

  2. Pingback: How to be a GREAT Product Manager (part 1) « On Product Management

  3. Very good point about staying market-focused / strategic in a product management role. Since ROI (not value in isolation of cost) is important, implementation and execution constraints must inform the backlog. I agree that they shouldn’t drive the requirements, just inform them. Great point to call out the slippery slope – hard to not help on something you can (but shouldn’t) help with.

    When an org is broken (irrational), it’s worth trying to fix it before moving on.

  4. Hi Saeed,

    I agree with your points, thank you for your post – it helped me to get focused.

    You’re running a great blog – I just added it to my Google homepage. Hope you write regularly 🙂


  5. Pingback: How to be a GREAT Product Manager (Boxed Set with Bonus Features!) | On Product Management