Interview Q&A on Product Management
Everything I learned during my first 8 months as a Product manager at a fast-paced EdTech startup
Questions provided by Khongorzul Davaajav; she invited me for this interview for her thesis research on Product Management practices in Mongolia.
First of all, I have to disclose a few things:
- I have been officially in a PM role for 8 months at TomYo EdTech;
- Now I am not associated with TomYo;
- I don’t have any professional education in product management, however I have been developing my side projects since 2016/2017;
- Especially since 2020, I have been focusing on our latest project Green Dot, a health-oriented concept startup which I co-founded with my sister Irene.
- I will try to be as specific as possible, but when I don’t know about certain mind models, methods or techniques, I will use my own words and sometimes my made-up names to explain them. Please mind that there could be possible inaccuracies regarding terminologies.
- Excluded one question that needed clarification.
Here are some of the questions that I’m interested in regarding your product management:
1. Product strategy: What are the concerns when you develop your product strategy?
In a company, unless you are one of the initial team members to do everything from scratch, there are already lots of resources and practices that the people before you have already tried out. In this regard, I would first seek out these resources as soon as possible:
- Company vision — Not only vision, if clearly defined mission and value proposals exist, that would also be very helpful.
- Business strategy — I have yet to come across clearly defined business strategy docs yet, but I ask about it anyway.
- Product vision — I personally asked around and found out what the founders and the core team have been working to achieve, what kind of relationship they already have with their users/market and what are their moonshot dreams for the product first to get a clear idea of the product vision. If they have set big overall metrics such as the North star, it’s even better.
Now as for the actual product strategy, these are the main concerns and main steps I tried to take for each and every product I was involved in:
- Defining internal and external stakeholders — with a few weeks worth of data collection and observation, I was able to map out internal and external stakeholders of the product I am working in, for example: End users, Content suppliers, Engineering team etc. Whether the product I am working on already has existing users or not, this step can be regarded as defining market and user personas and can be followed by market research if necessary.
- Defining entities — an entity can be anything, from what any single stakeholder might interact with to whole inter-connected product pieces.
- Mapping stakeholders and entities — Mapping them within their groups and with each other to get the whole picture of past, current and future product development.
- Empathy mapping centered on stakeholders — this is to detect any possible pain points where you can propose solutions on and also detect any possible gain points where you can amplify the experiences of the stakeholders involved. I think this step results in value propositions for stakeholders. Here, communicating with both random and focus-group users, learning about their experiences with the product in general, doing customer support, reading and analyzing public reviews really helped. My biggest regret is that I could not make this process a part of my daily work cycle as a product manager yet at TomYo.
- Scoring detected pain and gain points — against defined market research and internal resources to get overall priorities for your product. In my opinion, this step informs us about the product positioning from the internal side, adding an external analysis such as competitor research will give us the actual product positioning in the market. This step combined with existing company-wide business goals also results in stand-out features for your product differentiation.
- Defining agreed-upon product metrics — locating the North Star
2. Product roadmap: How do you prioritize your tasks/ideas when building a product roadmap?
While getting the fullest possible picture of the product ecosystem we are building in the given time limit (usually 2–3 weeks), I try to understand the necessary constraints such as human and technical capacity, management and market expectations and big deadlines (usually tied to marketing and sales efforts). I call these the restraints.
Given the restraints and early defined product strategy, I would try to put everything together on timescale, maybe on a monthly or a quarterly calendar. Here I try to use something called the 3D Eisenhower matrix to get everything in order. Restraints inform us the urgency of a certain effort and the product strategy informs us the importance of it.
On top of the normal Eisenhower Matrix urgency and importance coordinates, I added a frequency coordinate and used it with the following logic.
One-time tasks are dealt the same:
- Urgent and not important => Do;
- Not urgent and important => Schedule;
- Urgent and not important => Delegate;
- Not urgent and not important => Eliminate.
Frequent tasks are handled a bit different:
- Do => Do once and automate the solution;
- Schedule => Plan as the main focus of the teams;
- Delegate => Delegate once, deep dive into the cause of the task and automate future delegation;
- Eliminate => Eliminate once, deep dive into the cause of the task and automate future elimination.
These steps will result in near-future product backlog, long-term product roadmap as well as general logic for prioritizing a stream of tasks.
3. Product management/development role differentiating from project management: In companies, it is difficult to differentiate the role between project and product manager. How do you differentiate and what criterion do you use to distinguish them?
I have mainly worked in companies where either projects are run or products are developed, so I don’t have much idea on the differentiation of those two roles.
It’s true that at TomYo, product and project managers worked alongside on big products, but we had totally different deliverables and our resources did not intersect much. For example, technology deliverables were regarded as products while content, marketing and sales deliverables were regarded as projects.
If I am to differentiate the roles, I would consider the general scope of the responsibilities of the roles and day-to-day deliverables for comparison. If delivering mainly to end-users and managing product deliverables end-to-end, I think they might be product managers. If delivering mainly to internal stakeholders and managing well-defined parts of product deliverables, I think they might be project managers.
4. PM methodology: There are several product management/development methodologies such as waterfall, agile, and lean etc. What methodology do you preferably choose to apply on your product and why, how do you install it into your product cycle?
I have tried Lean for my side projects and Scrum methodologies to develop products as a team as TomYo. Recently I have become a fan of Product Manifesto principles and if I am to become a product manager with a big team again, I would like to try putting these principles into action.
5. Idea to launch: Please take me through how your company manages a feature or product idea from conception to launch
I believe I explained every step of the way in the above steps, so it will be straightforward.
- Strategy (a few years) — An idea or a feature is analyzed against the fundamentals of what we are trying to do and if it matches within the strategy, it advances down another level.
- Roadmap (less than a year) — It is analyzed against the roadmap and given a priority in the roadmap. It is then advanced down to the backlog.
- Backlog (1–3 months) — If it is not to be planned yet, then it goes to the outstanding part of the backlog. If it is to be scheduled for the current planning timeframe, the backlog will be refined with the addition of the idea or the feature. It is then advanced down to the appropriate sprint. At this stage, a Product Design Doc will be drafted, continually refined and ideally finalized before its initial iteration begins with a sprint. This doc aims to clarify user-side, business-side and tech-side requirements of the chosen idea or a feature.
- Sprint (1–2 weeks) — One iteration/execution of an idea or a feature would generally be fit for one sprint. Tasks within the iteration will make up the sprint backlog and the tasks will be estimated with scores by the team that will deliver the task results at the end of the sprint kick-off meeting. It’s worth mentioning here that a sprint team may consist of cross-functional members from different overall teams. After coming to mutual agreements on team deliverables, we start on the tasks.
- Daily stand-up (every day) — Team members meet every morning to let each other know what they worked on the day before, if there are any blocks for their tasks and what they will be working on that day. The goals of this meeting are very quick sync and block-elimination.
- Retrospective (preferably at the end of every sprint) — Things rarely go the way they were planned and there are always rooms for growth, opportunities, optimizations and learnings. Retrospective meetings are where the team members ask themselves what is working, what is not working and what could be improved and how.
- Constant data collection and analysis, metrics tracking and refining, communicating with users, putting out fires, backlog/plan/priority refining, communicating with stakeholders, caring for the team members, reporting to management and trying to stay sane (these are from the POV of product managers)
6. Tools: What tools and approaches do you use for your product management? /e.g for roadmapping, flowcharting, user survey and analysis, project management, collaboration and team managing/
- IRL whiteboarding / drafting on paper for almost everything;
- Lucidpark, Miro for flowcharting, roadmapping and visualizing ideas in general;
- Figma for prototyping;
- Google Forms, Customer.io for user survey and analysis;
- Google Workspace, Slack, Trello, GitHub for team collaboration;
- Google Sheets, Amplitude, Metabase for all things data.
7. Opportunity cost: How do you manage the opportunity cost when there is a loss and waste during the product development processes.
Opportunity costs come up at the stage where an idea or a feature is analyzed against the existing product strategy in the process I defined above.
I recently learned that it’s important for product managers to take return of investment and time to make decisions along with opportunity cost when comparing options.
It means choosing to make a series of decisions that will result in the most return of investment and the least opportunity cost overall in a given time instead of choosing a single option with the most ROI at a single time point or one with the least opportunity cost for that specific regard again and again.