I teach product management at a public German engineering school, where I am a professor of computer science. Product management is my nod towards “business informatics”, otherwise I only teach engineering courses (and one general how-to-perform-research class).
There is an old debate as to who makes better product managers: M.B.A.s or engineers? Having worked on both sides of the fence and having gotten both degrees, I can confirm that as so often, the question is wrong: A hiring manager for a product management position needs to focus on skills and attitude, not on degree credentials. The degree may be an indicator of such skills, but it is not a sufficient indicator.
The core skill set, in my opinion, is clarity of thinking and precision of verbal and written communication. Without it, you can’t be a good product manager (and admittedly will probably be bad at most other intellectual jobs as well). Let’s pick the most basic aspect of technical product management, specifying a single simple feature (requirement) of a software system to be developed.
The system needs to be future-proof.
I received this “requirement” from a student as part of their homework, even after I had taught some basic quality criteria for requirements (the INVEST criteria). This is only one example of the many brain-dead requirements I often get. Students (like professionals) often think that because requirements are cast as prose and don’t screem SYNTAX ERROR at you (or simply don’t behave as expected), writing requirements is easy. It is not.
Requirements need precision much like program code. Without such precision, your developers will not be able to use your requirements as a reference and they’ll not be implementing what you want from them. Because of the similarity to programming, people with an engineering degree may have a leg up on M.B.A.s when it comes to being a technical product manager: Some of their training is beneficial for a product management job, even if they didn’t take classes on the subject matter.
There is no implication that M.B.A.s can’t acquire this precision of thinking and communicating. However, the classes I took during my M.B.A. days did contain very little that strengthened this capability. Too much was hasted high-pressure winging of cases with little depth. About the only benefit of M.B.A.s over engineers that I can see is that their education prepares them better for strategic product management, as they should have acquired a better understanding of industry dynamimcs. I don’t think, however, that this advantage will last longer than a few years after graduate school, because smart engineers will quickly catch up, and to be frank, there is little content in product management education that cannot be picked up on the job.
Sometimes people argue that the process will fix poor product management. I’m a fan of agile methods like everyone else and have been teaching them for years. I acknowledge and welcome the iterative nature of software development, but it is not an excuse for shoddy requirements. It is only an explanation of why requirements keep changing over time. In no way do agile methods imply that you can do poor requirements work.
This blog post was triggered by a short but fun exchange on silly requirements on twitter.
Just read this: "All user interfaces should be intuitive"
Yup, people still write this kind of thing as a guideline or a requirement :-/
— Kevlin Henney (@KevlinHenney) March 14, 2015
Leave a Reply