The concept of “Product Management” in Software Product Company involves a high volume of interaction with the technical teams. When I say that, the first thing that comes to our minds is “Duh! That’s common sense!”, but quite often we don’t do the “interaction” part in the right way.Product Managers are the CEOs of their own products, they are responsible for the technology, operations, sales, and accounts - basically the success of their products. Hence building the correct product and getting the development effort in the right direction is imperative, and by doing that, we ensure our contribution towards creating a strong and inspiring technical team in the long run. Some key attributes which makes your role as a “Product Manager” a big hit with the technical folks can be -
Stay Calm - Be a good listener. Don’t rush your developers into making something without understanding the technical challenges in the current scenario and the long term impact. Over a period of time, it leads to the concept of “Technical Debt” - a phenomenon from which a lot of startups couldn’t come out when they had to scale. There are conclusions to a problem that save up development time drastically and give a more scalable solution for the same feature.
Always have a plan- Always keep backup plans & alternatives in case the developer is facing too many issues or surprises. Be the black magician representing the technical team.
Make an Impact! - Present your “concept” with confidence. Inspire. Make the upcoming stuff look beautiful to everyone, especially the developers. They should be proud of what they're making. Be actively involved with the design team to conceptualize your ideas in the best way possible.
Be Prepared - Be clear with what you need in your module or product.. Plan iteratively and have healthy timelines. Never hold back a developer in contributing his ideas to make the product better. Try not to leave much scope for unknown items. The developer should clearly know what is needed from the product and what all he is free to improvise on.
Have a clear vision - Discarding any amount of work which the developer has done is quite painful for him or her. A developer’s time is gold, for both management and the developers who've made the product. Know what's going on in the team at any point of time. Be sure of what is expected out of them and convey that clearly. Also make sure that the module or deliverable is there to stay by doing a good amount of market research, competition study and proactive discussions with the internal stakeholders including the CXOs, sales & operations teams and probably the board members as well.
Create a good environment - Keep your product teams happy and motivated. The workplace and personal relationships within the team should always be healthy and to some extent casual. Incentivise them for working hard and taking initiatives. Occasional outings, pretty desks, geeky gadgets, good food, public hackathons, Beer Fridays etc. play an important role in retaining and inspiring developers to spend time at work.
When interacting with the developers, think like them! - understand the problems in their perspective and contribute to alternative suggestions in solving the problems as well. If you’ve been interested in reading this article - get rid of the cliché thinking that Product Managers are not coders, they might not code on production environments but there’s no harm in getting your hands dirty to know what your company does better. Believe it or not, I’ve seen product managers with impressive profiles wasting precious development time on conducting unnecessary meetings, struggling to understand the impact of architectural changes because they are technically unaware. The more you know, the more confidence your technical teams have on you. Quoting Naval Ravikant (from one of his talks) - (Founder of several startups including Angelist, Venturehacks and one of the early investors in Twitter, Foursquare, StackOverflow to name a few) –
“Programming in the current generation is the skill of the elite - like reading and writing was in the past”