An Ideal Technical Product Manager, Extract from an Engineer’s Diary
We as humans take the good for granted. If not for a clogged nose, we never appreciate a clean one. If not for a wounded thumb, we would never realize the beauty of its unique use. Not until reviewing someone else’s code does one realize the value of clean code.
Similarly, when it comes to referring to a badly written requirement doc or story with no head or tail, missing details, or one without a well-thought-through solution, or simply with a rehashing of one.
These aren’t mere inconveniences and in fact poorly reflect on a team’s accountability, efficiency, and productivity. All of which can be precluded by an ideal Technical Product Manager.
These are the superpowers and standout qualities that I believe such a technical manager of the product should possess:
Basic understanding of Computer Science.
There are quite some commonalities between a business product manager, marketing product manager, and technical product manager. But, there are very stark differences — this segregation is done for a reason.
The least, I as an engineer, would love to have in my technical product manager is the ability to process and contribute to technical discussions and solutions which adhere to the basic understanding of the domain they are managing.
Building a feature that is API heavy? Start from knowing REST, CRUD, HTTP status codes, basic API design principles. Knowing Swagger (API documentation and design tool) is a definite plus.
Similarly for UI, awareness, and usages of the various components of the UI library the team/company uses.
Eye For Details
As a product manager, you have to have as clear a vision of the product as possible. If not on day one, but every passing day should make it clearer and clearer. And this clarity can only be seen in the stories or the tasks you write as a technical product manager for your software developers to refer to as to embark on the journey of making your dream a reality.
Writing a UI user story? Put in the exact error messages. Note down almost every error use case you’d like to be handled especially the business validations.
Writing an API story? Spend time with the Swagger doc [API Specifications] prepared by the leads. Be aware of every data point collected or delivered.
All of this would only be possible if you tirelessly indulge with the actual software/website you are building the feature for.
Awareness of Product’s Software Architecture
Software Architects are known to not only have a far-sighted “tech” vision of the product but also a holistic view. Being able to have discussions with them, while following the paradigms and reasoning behind their vision will increase your chances of creating effective products as a product manager.
Especially, when the pace of technological advancement is inversely proportional to the best possible life of a software product one is building. There is at least one initiative around you to deal with legacy systems. Having a good grasp of the product architecture will help you build products and features that will have ease in adapting and transitioning to changing tides.
Prioritization
As an engineer, one would reach out to the lead and product manager to get the order priority, especially when one has multiple things on the plate — the case with most sprints. That’s when one expects cogent prioritization from the Product Manager.
Prioritization is the skill that is the difference between a good and very good product manager. It is what makes the team go “She / He is a natural at product management.” And one may ask why?
Prioritization as a skill encompasses sub-skills such as decision making, farsightedness, ownership, reasoning, communication and calmness. The qualities that are also largely a subset of what a successful CEO exhibits.
Extreme Documentation
“Your mind is for having ideas, not holding them.” — David Allen
There are so many key questions an engineer comes up with during the implementation phase that product managers are making decisions on the fly while juggling multiple things on the side. Few months down the line, when the feature is complete and is being demoed to a stakeholder, someone comes up with one off of a question as to why something was decided to be done in a certain way and the only way to answer would be referring to the document that you kept updating tirelessly with every decision and reasoning behind it.
As an engineer, one must be doing this as well after every query call with the lead / PM. One does not want to be in a position where the answer to a question is “because the PM asked me to do so.”
Staying on top of things
“I don’t need to know everything, I just need to know where to find it, when I need it” — Albert Einstein
One is not supposed to know everything. But what is expected is that one stays on top things to find the answers to all the questions team reaches out to you. Specially when you are in the position of a Product Manager, stakeholders will test your understanding, engineers will question your decisions and demand details, directors will question the timelines and managers will question the cost-value based prioritizations, and so on.
The ones who get back in time when they say “I’ll get back to you on that” and don’t need endless follow ups are very valuable to engineers and business the same.
Conclusion
A product manager is served well with a reverence for the task of building the product, and the qualities above largely stem from such an outlook. Likewise, no self-directed and self-sufficient engineer can do their best without a product manager at the helm. The result? A synergy ensures the best version of defined processes in software engineering. The qualities described above each have emergent byproducts: an agile team, accountable, fastidious, and error-free.
After all, an ideal product manager, given good engineers, is what makes an ideal team.
