myhq Product Manager Interview: Questions, Experience & Prep (2026)

MyHQ is a flexible workspace marketplace that connects professionals and companies to coworking spaces, hot desks, and meeting rooms across Indian cities. The platform runs as a two-sided marketplace, balancing supply from workspace partners and demand from individual users and corporate clients. This marketplace structure shapes almost every product decision, and interviewers probe for this thinking directly.

MyHQ currently has 30 open roles. The PM interview process typically runs 3-4 rounds. Candidates report a mix of product case studies, analytical exercises, and structured conversations about past experience. Expect at least one round focused on a live product case tied to marketplace or workspace products. Confirm the exact format with your recruiter, as processes at growth-stage startups can shift quickly.

Salary ranges for PM roles, based on publicly reported industry data:

These reflect broad India PM market ranges. Actual offers depend on company stage, your experience, and your negotiation.

These questions come up frequently in MyHQ PM interviews, based on candidate reports and the nature of the product. Practice each one out loud before your round.

1. How would you improve the workspace discovery experience on MyHQ for someone booking their first space?
2. MyHQ serves both individual professionals and corporate teams. How do you prioritize features when these two segments have conflicting needs?
3. Walk me through how you would design a dynamic pricing feature for workspace listings on MyHQ.
4. Workspace booking completion rates dropped significantly last week. How do you diagnose what went wrong?
5. How would you increase the number of quality workspace partners listing on MyHQ?
6. What are the key metrics you would use to measure the health of MyHQ as a marketplace?
7. Design a subscription or loyalty product for frequent MyHQ users. What does it look like and how do you validate it before building?
8. A large corporate client wants a dedicated dashboard to track their team's workspace spending. How do you scope and prioritize this request?
9. How would you use data to decide which city MyHQ should expand into next?
10. Tell me about a marketplace product you admire and what MyHQ could learn from it.
11. How do you balance maximizing utilization for workspace partners against delivering the smoothest experience for end users?
12. What would your first 90 days look like as a PM at MyHQ?

Use these as templates. Replace the details with your own real experience.

Q: Tell me about a time you identified a drop in a key metric and led the fix.

*Situation:* At my previous company, which ran a B2B services marketplace, I noticed that workspace booking conversion had declined over two consecutive weeks. The drop was visible in the data but the cause was not obvious.

*Task:* My responsibility was to find the root cause, align the team on a fix, and restore conversion without disrupting the partner experience.

*Action:* I broke the booking funnel into stages and used session recordings alongside our analytics dashboard to isolate where users were dropping off. I found that a recent release had pushed pricing information below the fold on mobile. I ran a quick A/B test with the original layout, coordinated with engineering for a fast fix, and tracked recovery daily.

*Result:* Conversion returned to baseline within two weeks. The incident led us to add a 'pricing visibility' check to our release checklist, preventing the same class of regression from shipping again.

---

Q: Describe a time you had to balance the conflicting needs of two user segments.

*Situation:* I worked on a platform serving both enterprise clients and individual users. Enterprise clients wanted bulk booking controls and detailed spend reporting. Individual users wanted a fast, low-friction booking experience.

*Task:* I had to decide how to serve both groups without building two entirely separate products, as we had limited engineering capacity.

*Action:* I ran discovery sessions with both segments and mapped where their needs actually conflicted versus where they only seemed to. Enterprise-specific needs mostly surfaced post-booking (reporting, invoices, team management), not in the core search and booking flow. This let me keep the main flow clean for everyone and layer enterprise controls into a separate dashboard.

*Result:* Enterprise client satisfaction, tracked internally, improved meaningfully in the quarter after launch. The individual user booking experience was not degraded. The architecture also made it straightforward to add new enterprise features later without touching the consumer flow.

---

Q: Walk me through a time you made a product decision under data uncertainty.

*Situation:* My team was debating whether to build a 'saved spaces' feature or improve search ranking. Both had strong internal advocates and neither had solid quantitative backing yet.

*Task:* I had to recommend one to prioritize for the next sprint, with limited data and strong opinions on both sides.

*Action:* I pulled the data we did have: repeat visit rates, time users spent on search versus browsing, and a small user survey. I flagged the small sample size clearly to the team. The survey pointed to users forgetting spaces they had liked and not being able to find them again. A proxy metric showed that users who returned to a space listing more than once had a higher booking rate. I wrote a one-pager with this evidence, stated my confidence level explicitly, and recommended 'saved spaces' as the lower-risk bet.

*Result:* The feature shipped and was adopted by a solid share of active users in its first month. Repeat bookings for users who saved spaces were higher than the baseline. The process also established a template for how the team approached prioritization under uncertainty going forward.

For behavioral questions (tell me about a time...): STAR

Structure every behavioral answer as Situation, Task, Action, Result. Keep Situation and Task brief. Spend most of your time on Action (what you specifically did, not what 'the team' did) and Result (what changed and how you measured it).

For product design questions (design a feature, improve this product): A simplified design framework

Start with the user: who are they, what are they trying to do, what is getting in the way? Then move to problem prioritization (which user problem has the highest impact if solved?), solution options (at least two, with trade-offs noted), and finally how you would measure success. At MyHQ, always tie your solution back to the marketplace: does it help supply, demand, or both?

For metric drop questions (a metric fell, diagnose it): Funnel breakdown

State your hypothesis first, then walk through the funnel top to bottom. Check whether the drop is isolated to a segment, a platform, a geography, or a time window. Rule out external causes (outages, competitor moves, seasonality) before looking internally. Propose the first check you would run, not an exhaustive list.

For marketplace strategy questions: Supply, demand, and liquidity thinking

Frame your answer around whether you are solving a supply problem, a demand problem, or a matching and liquidity problem. MyHQ interviewers respond well to candidates who can articulate which side of the marketplace is the bottleneck and why.

Marketplace fluency. MyHQ is a two-sided marketplace. Interviewers want to see that you understand the difference between a supply problem and a demand problem, and that you think about how actions on one side affect the other. Candidates who treat the product as a simple consumer app without this lens tend to score lower on case questions.

Data-driven thinking, not data paralysis. You do not need to have all the numbers. You need to know which numbers matter, how to get them, and how to make a defensible decision when data is incomplete. Candidates report that interviewers explicitly probe for comfort with ambiguity.

User empathy grounded in real observation. 'Users want a good experience' is not an insight. Interviewers want to hear how you found out what users actually struggle with: research methods, specific observations, behavioral patterns. Be specific about how you know what you claim to know.

Clear communication of trade-offs. Every product decision has a cost. Interviewers want to see that you can name the trade-off clearly rather than pretending your proposed solution has no downside. This matters especially at a lean, growth-stage company where resource constraints are real.

Ownership and follow-through. MyHQ operates as a lean team. Interviewers look for candidates who take end-to-end ownership, from discovery to launch to post-launch monitoring. If your past examples stop at 'we shipped the feature,' add what happened next and how you tracked it.

Week 1: Understand the product and business

Use MyHQ as a real user. Book a hot desk or browse spaces in your city. Note where the experience is smooth and where it creates friction. Read publicly available coverage about the company (funding, new city launches, corporate partnerships). Understand how MyHQ makes money: transaction fees, subscriptions, corporate contracts. This context sharpens every case answer you give.

Week 2: Build your case and metrics muscle

Practice the funnel-breakdown approach using a metric drop scenario. Pick a metric relevant to a marketplace (booking conversion, partner supply growth, repeat booking rate) and walk through a hypothetical drop out loud. Time yourself. Aim to cover the key diagnostic branches in under five minutes before going deep on any one area.

Week 3: Sharpen your STAR stories

Prepare 5-6 STAR stories from your past experience, each covering a different theme: a metric improvement, a difficult prioritization call, a stakeholder conflict, a decision made under uncertainty, and a failed bet with lessons learned. Tailor at least two stories to marketplace or B2B product contexts if you have them.

The day before

Review the job description again and map each listed responsibility to one of your prepared stories. Know the names of your interviewers if shared in advance and look up their backgrounds briefly. Prepare two or three specific questions to ask them about the product roadmap or team structure.

Treating MyHQ like a consumer app. Candidates who design features only for the workspace booker, without considering the workspace partner side, get consistent pushback. Always think about both sides of the marketplace and how your proposal affects each.

Jumping to solutions before diagnosing the problem. In case questions, interviewers at product companies reward the quality of your problem framing. Spend the first part of your answer clarifying who the user is, what the context is, and what problem you are actually solving. Solutions that arrive without this foundation rarely impress.

Vague results in STAR answers. Saying 'the product improved significantly' or 'users were happier' is not a result. Even if you cannot share exact numbers, say what you measured, the direction of change, and the business impact. If sample sizes were small, say so explicitly.

Ignoring constraints. A solution that requires months of engineering time is not automatically wrong, but you need to acknowledge the trade-off. Candidates who never mention resource constraints come across as inexperienced with real product work.

Over-engineering the framework. Frameworks are a tool, not the answer. Interviewers notice when a candidate is reciting a structure rather than thinking. Use frameworks to organize your reasoning, then fill them with genuine insight specific to MyHQ's context and business model.