That’s Elementary, Aspiring Product Managers

Photo by Helena Lopes on Unsplash

This post addresses questions I ask aspiring Product Managers when I first talk to them, and delve into Mental Models of Analytics Product Management. By getting a deeper understanding of mental models at play, readers can quickly identify transferable skills from their current job role to Product Management.

I network with half a dozen folks every week. When new grads come to me seeking feedback (on being a PM) and express interest in becoming a PM, I ask the following questions to understand if they’re serious, sincere, and passionate about getting into Product Management (not having answers to these questions does not mean person I’m talking to cannot become a PM. Since time is precious it’d be better use of everybody’s time if the person can build context as to why they want to get into Product Management. I’m not a judge of whether a person can become a PM or not; I just want to prioritize who to talk to given the time crunch):

Tell me about yourself?

According to you, what is Product Management?

Why do you want to be a Product Manager?

If there’s one tagline that truly describes you, what’d that be?

What domain do you see yourself working in / interests you?

What do you look for in a company?

What are you truly passionate about?

Why do I ask these questions? To weed out the casual from the focused. Some I talk to are enamored of the idea of Product Management not really keen on the enduring the hardships of a PM.

These questions allows new grads to build a foundation for Product Management and master the art of story-telling, an essential tool to lead through influence rather than authority.

Mental Models in Product Management are relevant just like in any field. Today, I’ll dive into Analytics Product Management. This thought paradigm would be relevant for aspiring Analytics Product Managers.

• User Persona (RBAC) — Product managers need to consider both C-Suite users vs Analyst who likes to get into the weeds. Understanding these perspectives leads you to come up with appropriate access permissions, develop user persona metrics.
• Data Integrations — We live in a world where applications don’t exist in silos. It is important to think about retrieving data from 3rd party applications and feeding data into other applications via simple file export in csv, .xlsx, and / or exposing APIs
• Infrastructure Message Broker — As product manager, it is important to understand the different pieces of infrastructure used for ingesting / processing real time messages, its advantages and disadvantages. For example the use of AMQ vs Kafka. In addition, it is important to understand how this ties this into Cloud Infrastructure whether public or private for scalability and performance of your product.
• In-App Analytics — Helps with implicit and explicit feedback obtained from test and production instances that drive future product improvements
• Tech Debt — Early into design phase, engineering may have shorter and faster delivery alternative(s). You might choose to pursue a path to fastest delivery accruing tech debt which needs to be tackled in near future or a else it could performance, scalability, and / or security impact.
• UI/UX — Get to know the libraries used for displaying charts and graphs that constitute the analytics dashboard, and their pros and cons. UI/UX team should be consulted about components like Drop down, Lists, Tables and product meeting relevant accessibility standards.
• Success Metrics — Measure what matters! No Feature is baked into a product without defining success metrics. Define success for your feature / product and measure over time to determine if it is a success / failure, why, and what can be improved
• Authentication Standards — Depending upon whether SMB / Enterprises use the product the authentication standards supported on the product vary: Usually, Banking and Finance go for On-Prem solutions because of Cloud Security concerns and hence would like to use LDAP Auth method. SMB generally have a tendency to go with Cloud IDP solutions that support SAML / OIDC. If the app is used internally, it needs to be hooked into an existing authentication infrastructure.
• Product Rollout — Phased roll out or all-at-once? How’d you roll it out in phases and how would feature toggle(s) apply in your case before making it generally available? Who would be the first set of customers to get it?
• Licensing / Customer Experience — Is this something so valuable to end-users and decision makers that you can make money off of it? how easy would it be for end-users/ admins turn on this feature? Where do they get to enable this feature? How is the new feature communicated to customers vs prospects?
• Project Management — write a PRD and break it down into user stories to estimate, plan sprints, and easily track progress via tools like JIRA
• Internal vs External Customers — Things change depending upon who is the end-user:

If Internal

1. Easier to setup interviews to gather requirements
2. Easier to demo and gather feedback for future iterations
3. Sync with internal teams to ensure roadmap dependencies are taken into consideration and dashboard is released in cadence with what the internal teams are churning out sprint after sprint.
4. Easy to Pilot / Beta Release the features and get feedback
5. GTFO (Get the feature out) rather than UI/UX being immaculate since it is not really used by external customers.

If External

1. Identifying customers asking for this feature / product itself and their pain points is a challenge at some product companies. Sending out a survey to SE / Sales community or all existing customers could potentially help solve the problem.
2. Prioritize features relevant to retaining high paying customers vs vanilla customers, and that would help in acquiring new customers.
3. If there are existing NIST / Access standards that are table steaks to get federal customers on board, prioritize them!
4. Beta Testing might be slightly difficult since customers might be bureaucratic about signing NDA.
5. Digital Accessibility is a key aspect of some of the biggest tech firms, and if they’re your customers, ensure the feature / product is accessibility standard compliant.

No Product Management thought is picture perfect and neither is mine. Always looking forward to your thoughts, comments, concerns. Let me know what’s worked for you in the past. You can reach me on vathreya10@gmail.com if you’d like to take this conversation further.