Ever wondered what keeps the product managers so ‘busy’? So busy that every meeting with them leaves you exposed to constant whining about their compromised sleep schedules. Add to that, water cooler conversations with them are just no fun. Incredibly, they never seemed to have watched last night’s game and are definitely languishing far behind on their Netflix-bingeing.
I say that’s because they always need to be on top of things, need to constantly take important product decisions and break down customer problems while building products of great value. And also maybe because I am part of a product team myself.
Based on your organization, the responsibilities of product people vary. They are either building a product from scratch or working on a new feature/module. But there are some learnings which stay relevant irrespective of the kind of roles they are given in a product team.
I am penning down some learnings that I feel might be useful when you begin your journey as a Product Manager.
If you are looking at transitioning into a Product Manager role, here is a good read from Lenny Rachitsky.
Attention to detail and the power of writing
The product space is fast-paced and ever-evolving and it’s crucial to stay updated with the best practices and trends. Let us talk about something I encountered in UX Copywriting – the usage of parenthetical plurals.
The parenthetical plural – Product(s) is not used anymore.
But I wasn’t aware and used it throughout my document, only to realize that it is not the norm anymore. Indeed it’s a minute thing, but it was important to know, especially so, for a Product Manager.
Details matter, as a product person. And you can get better at details when you write. Personally, I would encourage you to write more frequently, whether it is product specs, research findings, about concepts or even marketing content. Writing helps put things into perspective.
In case you want to read more about Parenthetical plurals or UX copywriting, you can refer to these:
Parenthetical Plural Explanation by Grammarphobia
Invision’s UX writing tips
Assumptions everywhere, but no one questioning them!
As a PM, decision-making is part of the daily routine. These decisions can be as simple as defining the CTA or preparing the quarterly roadmap. As we climb up the ladder of growth, the decision-making process becomes complex. In the absence of time and details into the feature requests, decisions are made based on gut and hear-say (and AI-based X). At first, we may think there is no outright solution to an ambiguous problem and make decisions that are not better informed?
The last thing you should do is to assume things.
Our team decided on going down a path and then changed the course along the way. But we course-corrected and there was a good amount of questioning which made the switch possible.
We updated the product scope. We began with getting back to the whiteboard, had multiple discussions, got deeper into the nitty-gritty of the problem, and uncovered the reasoning behind the changes and their true benefits. This helped us in getting the confidence in driving towards a solid conclusion.
If the path we take is validated by informed decisions and backed by unbiased data points it will result in better outcomes, which in turn puts our customers in a great spot – a win-win situation for everybody.
Recommendations/ further reference-
Steve Blank’s Customer Development methodology
Alberto Savioa’s book – The Right It
Product Managers and Tech understanding
A lot of decisions that a product team makes are directly dependent on the understanding of the technology behind a product and the feasibility of its application in the said product. But do all Product managers have coding experience, probably not. So what is the amount of technical knowledge we need to have and how to acquire it if we don’t?
This has been a debate and even a key hiring criterion in some companies. There is no hard rule that requires a PM to have prior experience as a developer. In my experience, a PM can survive in a tech company without coding experience but understanding how tech works is a must, esp., during brainstorming, estimations, roadmapping, etc.
Why?
Learning the whats and hows of your system/app informs your core understanding of what’s beneath the hood.
With what I do at Freshflows, B2B SaaS Product engineering fundamentals are important, such as
- how APIs work,
- how Database works,
- how analytical and transactional databases are setup
- basics of front-end (PS: I’m now reading why node.js is better than plain javascript)
The relationship between the product and the tech team is very important. A product person with technical skills will be able to converse with the tech team fluently and build a fruitful relationship.
Interesting in reading further, I found these references useful –
APIs for Product Managers
Business of APIs
Retrospection and Team
If there is one thing that we all need to deal with, it’s change. Nobody is immune to change, not us, not even the best ideas or products. Change makes us alter our plans and rethink our strategies. Most of the time we aren’t sure about what needs to be done? Do we accept change or ignore it and move on?
This is very much applicable when working on the products we build. The first version of the product specs (read PRD) and the actual product might not be the same. During development, we may not have the actual solution or think of a better solution for the same problem. What do we do?
I am lucky to have a team I feel proud to be a part of. Perspectives from all members matters to us. We took time to step back, retrospect, and reflect on how things went.
Our team at Freshflows suggests what changes should be made, even if it means reworking a bunch of features. This helped us ultimately build a better product. The motive is not to just build a product, it is to build something which provides value, and no one person is responsible, the team is.
What’s next?
Product prioritisation is key to product development. I am trying to understand how features make it into the roadmap, and how difficult choices are made – the process of saying NO. User Experience (UX) is an area I would like to improve on and would then try to understand how designers make seemingly complex user journeys simple. Another area that I want to talk about is Product usage analytics.. I would like to learn about and analyse the metrics which can make the product valuable.
And probably a few more as I continue in this journey.
Will keep you posted!
