GetBuddyGo: Trust-First Small Social Experiences for Bengaluru
A PM case study for a trust-first platform concept that helps young working professionals in Bengaluru meet like-minded people through small curated experiences. Slow dinners, board game nights, music circles, and city walks. The MVP is a manual concierge pilot, not a full marketplace.
Case Study Snapshot and Evidence Maturity
GetBuddyGo is being built as a manual concierge pilot, not a self-serve marketplace. The case study documents discovery, user understanding, market context, product strategy, feasibility, and MVP scope. Step 7 is in active design. Steps 8 to 10 are planned, not completed.
Trust-First Pilot
A curated small-group format for Bengaluru professionals, not an open meet-people app.
4 Experience Types
Slow dinners, board game nights, music circles, and city walks.
3 to 6 People
Small enough to talk, large enough to feel social. Cohorts assembled by hand.
Concierge-Bound
Capacity ceiling is human. Growth is slow on purpose, trust before scale.
My Role and Working Approach
My role was to structure the product thinking behind GetBuddyGo: problem discovery, user understanding, market context, strategy, MVP scoping, prioritization, feature breakdown, documentation, and delivery readiness inputs. This case study uses SAFe-compatible artifacts for planning discipline. It does not claim real ART execution, live System Demo, Business Owner scoring, or measured outcomes.
Product Thinking
Problem framing, user research synthesis, market context, product strategy, and metrics direction.
Documentation
Feature Hypothesis, Candidate PI Objectives, MVP scope, ART Backlog Features, and story-level planning.
Delivery Readiness
NFR notes, Definition of Done draft, dependency map, and release readiness inputs for the concierge pilot.
Role Honesty
SAFe artifacts are used for discipline. No real ART, System Demo, or measured outcomes are claimed.
Problem Discovery
Many young working professionals in Bengaluru struggle to form meaningful new connections outside their immediate work circle. Existing options feel transactional, hit-or-miss, or require initiative that is hard to sustain after long workdays.
Problem Statement
Jobs to Be Done
Social: Be seen as someone who shows up for new experiences and conversations.
Emotional: Feel less isolated, more curious, and more present after work hours.
Why Now
Outcome Link
User and Segment Understanding
The primary user is a young working professional in Bengaluru, often 24 to 32, post-college, post-first-job, frequently new to the city or new to a stage of life. They are open and curious but socially time-starved.
- Moved to Bengaluru 18 months ago. Friendly, but most of her social life has shrunk to work and one or two old friends.
- Meet a small group of like-minded people in a low-effort, trustworthy setting.
- Be the kind of person who explores Bengaluru and meets new people without overcommitting.
- Feel less isolated and more present, without the awkwardness of large event halls or swipe-based apps.
- Trust-driven, time-conscious, slightly skeptical of "networking" framings.
Context and Market Research
GetBuddyGo is not competing only with social apps. It is competing with fragmented alternatives: open meetups, hobby clubs, friends-of-friends, work-themed coffee chats, solo travel groups, and the default of doing nothing.
| Alternative | Limitation | GetBuddyGo Opportunity |
|---|---|---|
| Open meetups and event apps | Hit-or-miss crowds, no curation, low social safety. | Small, curated cohorts with a clear host. |
| Hobby clubs and running groups | Niche-locked. Hard to attend without commitment. | Rotating formats that match different evenings. |
| Friends-of-friends introductions | Slow, dependent on someone else's network. | A trusted curator outside personal networks. |
| Co-working and coffee chats | Work-themed, transactional, not friendship-shaped. | Off-work formats with low networking pressure. |
| Doing nothing | Quiet erosion of social life. Most common default. | A short, low-friction first experience to break the pattern. |
Product Strategy and Opportunity Hypothesis
The product bet is to convert "I don't really know people here" into "I have a small group I want to see again," through small curated experiences, manual cohort assembly, and trust by design.
GetBuddyGo helps young working professionals in Bengaluru meet like-minded people through small curated experiences such as slow dinners, board game nights, music circles, and city walks. Trust is built through manual curation and a hosted setting, not through algorithms.
If we offer 3 to 6 person curated experiences with a clear application process and a small participation fee, working professionals who feel "socially stuck" will participate and return for a second format.
Repeat application rate within 6 weeks of a first experience.
Working professionals trust a new, small, curated platform enough to apply with real identity for an in-person setting.
- Run 4 concierge-pilot experiences across the 4 formats within 8 weeks.
- Achieve a 70% post-experience satisfaction rate across pilot cohorts.
- Convert 30% of first-time attendees into a second-format application.
- Establish a baseline trust and safety workflow before any external launch.
Feasibility, Data, and Risk Check
A trust-first social product carries operational, safety, and data risks that are bigger than a typical app MVP. The feasibility view names these risks early and frames Built-in Quality inputs and NFRs accordingly.
Manual concierge has a hard human capacity ceiling. Mitigation: grow cohorts slowly, cap pilots per week, and keep the curator workload public so trade-offs are visible.
ID verification by upload only. Clear code of conduct, host script, and report channel. No public ratings of individuals in the MVP.
Collect only what is needed for matching and safety. India DPDP-aware data handling. Retention capped post-event.
No algorithmic matching in MVP. No AI scoring of people. Human curation is the product.
MVP Scoping and Prioritization
The MVP is a manual concierge pilot. The goal is to validate trust, curation quality, and repeat intent before any self-serve or marketplace features are considered.
Features In
- Application and intake form with identity check
- 4 curated formats: slow dinners, board game nights, music circles, city walks
- Manual cohort assembly for 3 to 6 attendees
- Closed-channel pre-event coordination by curator
- Small participation fee with simple payment link
- Lightweight host playbook per format
- Private post-event reflection prompt
- Simple landing page with waitlist
- Trust and safety baseline: conduct code, report path
Features Out
- Open marketplace or public browsing
- Self-serve cohort selection
- AI matching or recommendation engine
- Public profiles or peer ratings
- Mobile app
- Multi-city expansion
- In-app chat at scale
- Sponsorships and brand events
- F1. Application and intake with identity-aware fields
- F2. Concierge cohort assembly tooling for the curator
- F3. Host playbook and event format library
- F4. Reflection capture and repeat-intent signal
- F5. Trust and safety baseline: conduct code, report path, incident review
Experience and Solution Design
Step 7 is in active design. The flow below is the working direction. Edge cases, copy, and the curator-side workflow are being shaped alongside Step 5 NFRs and Step 6 ART Backlog features.
Product Documentation
Step 8 begins once Step 7 closes. The intent is to produce execution-ready documents a small team can ship from. A first-draft PRD outline exists. The full execution-ready set is planned.
PRD, Lightweight Solution Intent for the curator workflow, Stories, Acceptance Criteria, NFR notes, and Definition of Done at the cohort-event level.
Host playbook per format, conduct code, reflection prompt library, and incident review template.
Execution, Launch, and Monitoring
Step 9 begins once documentation is execution-ready. The plan uses SAFe-compatible artifacts for discipline, not as scenery. No live System Demo, ART event, or Business Owner scoring is claimed yet.
PI Planning input document, ART Planning Board sketch, dependency map for curator availability, venue partners, and payment handling.
Release Readiness Checklist for the concierge pilot, Definition of Done at the event level, and a clear pause condition if trust signals drop.
Internal pilot debrief plays the role of an early System Demo. Real System Demo and Inspect & Adapt cadence are only added when the team scales beyond solo curation.
Track cohort fill rate, satisfaction, repeat intent, time-to-cohort, no-show rate, and curator hours per cohort.
Learning Review and Next Decision
Step 10 is reserved for after the first set of pilot events. The decision is binary at this stage: continue the pilot only if trust and repeat signals hold.
Pilot debrief notes, host feedback, attendee reflections, no-show analysis, and curator capacity review.
Seeded by recurring friction points from pilots: application clarity, cohort balance, format pacing, reflection prompt quality.
Continue the pilot only if the first 4 events reach 70% satisfaction and 30% repeat-intent. Otherwise pause and rework Step 6 scope.
Continue, iterate format mix, pause to redesign trust flows, or sunset and document learnings.
Final Artifact Coverage Checklist
A single view of every artifact the case study touches, mapped to its step and current status.
| Artifact | Step | Status |
|---|---|---|
| Problem Statement | Step 1 | |
| JTBD Note | Step 1 | |
| Why-Now Rationale | Step 1 | |
| Assumption List | Step 1 | |
| Persona | Step 2 | |
| Segment Memo | Step 2 | |
| Pain & Gain Table | Step 2 | |
| Five C's Note | Step 3 | |
| Competitive Analysis | Step 3 | |
| Value Proposition Canvas | Step 3 | |
| Product Vision | Step 4 | |
| Feature Hypothesis | Step 4 | |
| Candidate PI Objectives | Step 4 | |
| Feasibility Note | Step 5 | |
| Risk Log | Step 5 | |
| Initial NFR Notes | Step 5 | |
| MVP Scope | Step 6 | |
| ART Backlog Features | Step 6 | |
| Capacity Allocation Note | Step 6 | |
| User Flow Draft | Step 7 | |
| Curator Workflow Sketch | Step 7 | |
| Fallback Spec Draft | Step 7 | |
| PRD | Step 8 | |
| Lightweight Solution Intent | Step 8 | |
| User Stories & Acceptance Criteria | Step 8 | |
| Definition of Done | Step 8 | |
| PI Planning Input | Step 9 | |
| Dependency Map | Step 9 | |
| Release Readiness Checklist | Step 9 | |
| System Demo Plan | Step 9 | |
| Monitoring Plan | Step 9 | |
| Inspect & Adapt Notes | Step 10 | |
| Improvement Backlog Seed | Step 10 |
Final Positioning Summary
GetBuddyGo is a trust-first platform concept for small, hosted social experiences in Bengaluru. It helps young working professionals meet like-minded people through curated formats: slow dinners, board game nights, music circles, and city walks. The MVP is a manual concierge pilot, not a full marketplace.
This case study documents the product thinking behind the pilot. Steps 1 to 6 are complete: problem framing, user understanding, market context, strategy, feasibility, and MVP scoping. Step 7 is in active design as the experience and curator workflow are shaped. Steps 8 to 10 are planned, not claimed.
SAFe-compatible artifacts are used for planning discipline. There is no real ART, no live System Demo, no Business Owner scoring, and no measured outcomes yet. The case study's value is in the visibility of the decisions, the artifact coverage, the honest evidence labels, and the clear next bet, which is to run the first four pilot events and let the trust and repeat signals decide what happens next.
Explore More Product Work
This case study is one application of the Problem to Product Workflow. Read the workflow page for the full system, or get in touch about PM roles, portfolio reviews, and product collaborations.