What happened
The first one. Dinesh Kumar Prabakaran, then a product manager for reports and analytics at Kissflow, explained near the top why the evening was happening at all. Metro cities have tech communities and conferences; second and third tier cities do not, and he was clear that this is not particular to Coimbatore or to India. So he and Siddarth decided to start something in Coimbatore that was about product rather than about technology, open to product managers, designers, technical writers, anyone working on a product. That is the whole founding argument, stated on the first night, before there was any evidence it would work.
The topic was chosen by elimination. They had considered product strategy, roadmaps and analytics, and settled instead on simply describing what the job looks like on an ordinary day. He then went and asked product managers at other companies what their days looked like, so the answer would not just be his.
The shape he described was fifty per cent research and fifty per cent execution, run across three or four features at once, each at a different stage. One is being built, and once engineering starts he largely steps away from it. One is being specified. One is still being researched. The calendar fills with the standup, the leads sync, design reviews, roadmap checks with the product owner, and a conversation with the engineering lead every couple of months about whether the team can actually resource what has been promised. Some product managers block an entire meeting-free day to write specifications. He does not, and works in the gaps.
The most useful thing he said was about where feature requests come from. Sales, customer success, and the chief executive all arrive with a solution rather than a problem. His example was a chief executive asking for a forward button because WhatsApp has one. You cannot win that by pointing at the agreed roadmap, and you cannot dismiss it because of who is asking. His phrasing was that a product manager needs the empathy to listen without being convinced merely because the other person is talking a lot, and then has to ask the questions that get back to the actual need.
He was equally clear that the right answer is often to build nothing. Before committing, work out whether it is really a problem that requires a feature, or whether a customer can reasonably work around it, because a feature spends the product manager's time, a designer's, one or more developers', and whoever writes the help documentation. That is the cost, and it is worth naming before anyone starts.