Read the companion post “Steps to a better programmer“
This is a guide written for aspiring civil engineers who want to excel in the job of Software Product Manager. But it also applies to software product managers in general.
Software product manager? What is it?
Titles like “Project Manager” are common; so everyone understands what it is. Basically it’s a position that ensures that the project goes on smoothly, within budget and meets the client’s needs.
But software development is a relatively new field, with a lot more variability, which the managers have a lot less control over ( the ones who have more controls are whom we call programmers). So how can someone with almost no control of the speed of software development be called “manager”?
Instead of giving it a formal definition, maybe it’s more instructive to just list out the traits of it. Hopefully by the end of this article, you have a fairly good idea what makes a good software product manager, though you may not be able to still formally define it.
Listen to the users
First, You, the software product manager, are someone who listens to the users.
A product manager has the unique opportunity to support the users during their course of using the software, this is actually his blessing– not his curse. A lot of people might think that doing technical support is a mundane job, reserved for those in the lowest rung of the hierarchy. But nothing can be further from the truth.
Listening is a skill, for you don’t just listen to what people say, you also listen to what they don’t say, or why they said what they said. Don’t just reply to them blandly like “this is how the software behaves”. As if the user doesn’t already know. Ask yourself instead why are they asking this question at all? Is it because this is the polite way the user is telling you that there is a bug? Can you suggest how to improve on the software so that they won’t ask this question? You really should get the project files and investigate and convince yourself that there is nothing wrong with the software ( or find out the root cause), and that the user is getting the proper help.
A lot of the time the users are just venting out their frustration, and their excessive rants can be traced out to (just) a single root cause. So ignore the rant and find out the root cause ( you need some interpersonal skills to withstand ranting, but this is a given in any job). Or a lot of times the users just tell you far less than what you need to know. Then it’s your responsibility to fill in the gaps, by asking followup questions, or probe the users differently.
To listen well, you will need to have the knowledge background– you know where the users are coming from. Since we are serving the civil engineering niche, you will need to have enough knowledge about the technical and daily aspects of civil design engineers in order to connect the dots. A lot of us may not have the luxury of working in a civil engineering design firm, but it doesn’t really matter. Because this is something that you can get better as you have more experience.
The bottom line is that you need to have an inquisitive nature, to always read and improve yourself.
Communicate with programmers
Second, you are able to interface with programmers
As a programmer I’ll tell you that a programmer is a very rational being– at least when it comes to the job. If possible he would want you to list down with all the permutations of a feature.
But if you really follow this route… then you are screwed, because the programmer is not exercising his discretion and instead behaving just like a glorified typist, and you are doing the job of the programmer. Which you will fail invariably, because you are not one.
The programmer has the only source of truth– the source code, so they should understand the whole picture better than you do. But you have the insight from the users that he may not necessarily have. So you can illuminate him with this piece of insight, and he should be able to – upon meditating on his source code– to come up with the best way to handle your requests.
It takes two to tango, so you have to do your job by writing and communicating well, more on this later.
Write, write, write!
Third, you explain well. Both in terms of writing and verbal communications.
Especially verbal communications. When you are explaining the features of the software to others, whether they are new users or programmers, it’s important to size them up– your audience– first. Use the language that is appropriate to them. You must explain what they want to know, and not what you know. Don’t bore them with the platitudes they already know.
It’s easy, during verbal communications, to get carried away because you get animated in the topic and words just automatically come out of your mouth. But you need to resist this temptation: think before you speak.
It also applies to writing too, whether you are writing documentation for the users or writing a spec/ bug description for the programmers. There is a rule of thumb when doing this kind of technical writing: can an educated but uninformed reader follow your steps and reproduce what you want to see? Or as per Feynman rule, can you explain the feature/situation so simply that even a child can understand? We have more, documented in our internal wiki. Do yourself a favor and read it.
If the answer is no, then perhaps there is a deeper cause; you may want to check whether your understanding of the material is thorough enough. Remember the Feynman rule!
Synthesize
Fourth, you can think of how everything fits into the grand scheme of the software. And chart a direction for the software to follow.
Everytime you finish talking to the users, you should think “how can we not have this conversation from now onwards“ ? The answer is obviously not “just shut down the communication channels” ( like what Autodesk is doing), but rather “What features the software can have so that the users can discover for themselves the solution”? The software product manager will be thinking on behalf of users how to best solve the problems by fixing the problem twice: once fixing the immediate problems for the users ASAP, another fixing the problems from the root– either by enhancing the software to eliminate the confusion, or improving the documentation– yes, people do read documentation. I have internal website statistics to prove it.
Ask yourself whenever you are writing a spec for a feature: what do I expect to see in the software? What problem does it solve for the user? The user asks for this, but obviously the software can’t directly do this, so how can I split it into multiple features, and design a workflow for the users to follow?
Not only that, you will care about the performance. Does the new version seem slower than the old ones? Use more memory? One doesn’t have to time for every new version, but one does have to be mindful from time to time. And if you are living and breathing the software, you will know it viscerally.
A good product manager is constantly thinking about the software, on how to improve it. And the ideas will often come when… you think hard enough about it and then stop thinking about it.
Curiosity
Finally, you are insatiably curious. You read a lot. You want to get to the bottom of everything. Actually this applies to everyone who works in the intellectually demanding fields but also especially to you, because you are at the intersection of technology, engineering and even current trends.
Our world– the world of software, civil engineering field not so much– is evolving fast. People’s taste in software do change, and we are always looking for ways to revolutionize our UI. If you don’t keep up with the trend then you will miss the boat.
And our competitors– I mean the likes of Autodesk products like Civil 3D– do improve or change from time to time. Especially Autodesk, though their products are lackluster ( and I say this not solely because they are our competitors), they do set THE trend of the AEC fields with “innovation” like Revit, BIM, Cloud As a Service ( God help us if they do succeed with the last; I can predict that it will come with even steeper yearly license fee increment and with even less product innovation).
It’s good that you keep tabs with them, so that we can learn from them and we– all of us, the company and you— will also grow.