Featured Case Study · Concept

PlayNest

Intelligent Community Sports Platform (Concept)

A community sports platform concept: help people discover games near them, get matched with players at a similar level, actually play, and come back next week. Product strategy, UX and a set of proposed ML use cases — no deployed models and no claimed results.

Product StrategyPlayer MatchingPersonalizationMarketplace ThinkingML Product ThinkingUX

Illustration of a community sports platform: player matching, game discovery and a personalised recommendation graph

Project overview

Project: PlayNest — community sports platform (concept)
My Role: Product Manager — strategy, discovery, prioritisation, UX, metrics
Timeline: Self-directed product case study
Tools: Figma, survey tooling, spreadsheets, journey mapping
Product Area: Community · Marketplace · Personalization · ML product thinking
Status: Concept — ML capabilities are proposed, not deployed

The problem

What are we solving, who feels it, and why does it matter?

Recreational sport dies in coordination. Finding a game near you, at a time you are free, with players you can actually play against is a chain of manual steps — and it breaks at any link.

Who experiences it

Recreational and semi-serious players, casual groups looking for extra players, and organisers or venues trying to keep games full.

Why it matters

Every failed attempt to join a game reduces the chance a person plays at all. A platform that removes the coordination cost converts intent into participation, and participation is the only thing that compounds.

Discovery

Games are hard to find near you at the time you're free

Fit

Skill mismatch makes a game unenjoyable for both sides

Retention

One bad experience ends the habit before it forms

User research

Approach, target users, pain points and the insights that changed the direction.

Research approach

Conversations with recreational players about how they currently find and organise games
A short survey on frequency of play, blockers, and reasons for dropping out
Review of existing sports-community, booking and matchmaking products
Synthesis into personas, a pain-point map and prioritised insight statements

The Solo Player

Wants to play weekly but has no fixed group.

Goal: Join an existing game near home at a level that is neither humiliating nor boring.

The Group Organiser

Runs a recurring game and constantly chases replacements for dropouts.

Goal: Fill open slots quickly with players who will actually show up.

The Newcomer

New to the city or to the sport, no network to plug into.

Goal: Find a welcoming game and a reason to come back.

The Venue / Host

Has open slots at off-peak hours.

Goal: Convert unused capacity into booked, played games.

Pain points

No single place to see what games are happening nearby this week
Skill level is invisible until the game starts, so matches are often lopsided
Last-minute dropouts collapse games and waste a booked slot
No accountability — no-shows carry no cost
Nothing brings a player back; there is no sense of progression or belonging

Insight 1

Match quality drives return, not feature count

Players described a good game as one where they were competitive. A well-matched game is the retention mechanism; everything else is packaging.

Insight 2

Reliability is a trust problem

Organisers cared less about finding players than about finding players who show up. Reputation has to be part of the core product, not a later add-on.

Insight 3

The first game decides everything

If a newcomer's first game is well matched and welcoming, they return. Activation is one specific event: one completed, well-matched game.

Problem definition

Problem statement

People who want to play regularly cannot reliably find a nearby game with players at a similar level and a reasonable chance of actually happening — so intent to play rarely turns into playing.

User needs

See real games nearby that fit my time and my level
Trust that the game will happen and the players will show up
Be matched with players I can compete against
Have a reason and a reminder to come back next week

Skill-aware matching

Estimate a player's level from self-declaration plus play history, and use it to build balanced games.

Reliability as a product surface

Attendance history and reputation shown where the join decision is made.

A returning loop

Post-game feedback and recommendations that make next week's game the obvious next step.

Product strategy

Product goal

Increase the number of completed, well-matched games per active player per month.

Product vision

Open PlayNest and there is always a good game for you this week — nearby, at your level, and it will actually happen.

Business objective

Supply density in a neighbourhood is the moat. Once enough games and reliable players exist locally, matching quality improves on its own and acquisition cost drops — with venue bookings and premium organiser tooling as the eventual revenue layer.

User objective

Stop organising and start playing: one tap to a game that fits me.

The solution

Proposed solution

A discovery-to-return loop: find games nearby, get matched by level, join with confidence, play, review, and get recommended the next one.

The home screen shows games near you this week, ranked by fit rather than recency, each with a level band, how many slots are open and how reliable the group is. After the game, a lightweight review updates skill and reliability signals, which improves the next recommendation.

Game discovery feed

Nearby games filtered by sport, time window and level band.

Why: Removes the first and largest coordination barrier.

Skill-based player matching

Builds balanced games from estimated skill rather than first-come-first-served.

Why: Match quality was the strongest driver of returning in research.

Reliability & reputation profile

Attendance history, punctuality and peer ratings shown before joining.

Why: Answers the organiser's real question: will these players show up?

Personalised recommendations

Suggests the next game based on level, location, time patterns and past games.

Why: Converts a one-off game into a weekly habit.

Venue & slot booking

Booking a court or pitch inside the same flow as forming the game.

Why: Marketplace layer: matches demand to unused venue capacity.

Post-game feedback loop

A two-tap rating of match quality and attendance.

Why: Supplies the data that every proposed model depends on.

Prioritization

Framework: Impact vs Effort

Reasoning

The MVP had to test one hypothesis: that a well-matched game makes people come back. Discovery, matching and the feedback loop are the hypothesis. Tournaments, commerce and advanced ML were deliberately deferred until there was play data to learn from.

Impact vs Effort

Game discovery feedSkill-based player matching (rules-based v1)Post-game feedback loopReliability & reputation profilePersonalised recommendationsVenue booking & commerceTournaments & leagues

Low effortHigh effort

Vertical axis: impact (low at the bottom, high at the top).

Now

Game discovery feed
Nothing works until players can see a game to join.
Skill-based player matching (rules-based v1)
The core hypothesis, testable first with declared level plus simple heuristics.
Post-game feedback loop
Cheap to build and it generates the data everything else needs.

Reliability & reputation profile
Needs attendance history before it means anything.
Personalised recommendations
Only useful once there is enough local supply to choose between.

Later

Venue booking & commerce
Revenue layer; requires reliable demand to be worth a venue's time.
Tournaments & leagues
Serves the most engaged users, not the activation problem.

User flow

Step 1
Discover
See nearby games this week filtered by sport, time and level.
Step 2
Match
Get matched to a game where the level band fits your estimated skill.
Step 3
Join
Confirm a slot with visible group reliability and venue details.
Step 4
Play
The game happens; attendance is recorded.
Step 5
Analyze
Two-tap post-game feedback on match quality and attendance.
Step 6
Improve
Skill and reliability signals update from the result.
Step 7
Return
The next best game is recommended for next week.

Wireframes & prototype

Key screens from the flow. Full-fidelity frames are in the project document.

Sport & location

Availability

Level self-assessment

Onboarding & level setup

Sport, location, availability and a self-declared level that later gets refined by play history.

Nearby games

Filters

Game detail

Discovery feed

Games near you ranked by fit, each showing level band, open slots and group reliability.

Match explanation

Player list

Confirm slot

Match & join

Why this game was suggested, who is playing, and a single confirm action.

Rate the game

Attendance check

Player profile

Post-game & profile

Two-tap feedback, then an updated player profile with level and reliability.

Analytics

Every metric is tied to the decision it would change.

North star metric

Completed, well-matched games per active player per month

It only increases when discovery, matching and reliability all work together — a game must be found, joined, actually played, and rated as a fair match.

Metrics, why each matters, and the product decision it informs
Metric	Why it matters	Product decision
Activation — first completed game within 14 days of signup	Research pointed at the first game as the moment a player is won or lost.	Weak activation shifts investment to discovery density and onboarding, not new features.
Join-to-play conversion	Measures how often a joined game actually happens.	Low conversion means reliability tooling (reminders, waitlists) moves ahead of recommendations.
Match-quality rating	The direct read on whether matching is doing its job.	Consistently lopsided games trigger a change to the skill banding.
No-show rate	The main destroyer of trust for organisers.	Rising no-shows justify reputation consequences in the join flow.
Month-2 player retention	Tests whether one good game becomes a habit.	Flat retention with good match quality points at the recommendation loop, not matching.

Experimentation

Experiment 1

Showing why a game was matched to a player increases the join rate.

Experiment: A/B the game card with and without a one-line match explanation.
Primary metric: Game card → join conversion
Expected result: Higher join rate in the explained variant, driven by trust in the fit.
Decision rule: If flat, the barrier is supply density, not confidence — invest in local supply.

Experiment 2

Surfacing group reliability before joining reduces no-shows.

Experiment: Show attendance history on the join screen for one variant.
Primary metric: No-show rate
Expected result: Lower no-shows and higher join-to-play conversion.
Decision rule: If no-shows are unchanged, add commitment mechanics rather than more information.

Experiment 3

A post-game recommendation for next week increases return play.

Experiment: Trigger a next-game suggestion immediately after feedback for one variant.
Primary metric: Second game within 14 days
Expected result: More players book a second game inside two weeks.
Decision rule: If unchanged, timing is wrong — test a mid-week prompt instead.

Technical thinking

Enough depth to scope feasibility with engineers, without pretending to design the system.

Proposed ML use case — skill estimation

Estimate a player level from declared skill, match outcomes and peer ratings, starting as a simple rating system before anything learned. Proposed, not deployed.

Proposed ML use case — player matching

Optimise team and game composition for balance rather than filling slots in arrival order. Rules-based v1, learned ranking later. Proposed, not deployed.

Proposed ML use case — personalised recommendations

Rank nearby games by predicted fit using level, distance, time-of-day patterns and past behaviour. Proposed, not deployed.

Proposed ML use case — demand prediction

Forecast where and when demand for a sport will appear, to help organisers and venues open the right slots. Proposed, not deployed.

Proposed ML use case — churn / drop-off prediction

Identify players likely to stop playing after a poor match or a no-show, and intervene with a better-fitting game. Proposed, not deployed.

Proposed ML use case — fraud & fake activity detection

Detect fake profiles, inflated ratings and manipulated attendance that would corrupt the reputation system. Proposed, not deployed.

Cold start is a product problem, not a model problem

With no history, matching must run on declared level and simple heuristics. The feedback loop exists so the system has data to improve on at all.

Expected impact

This is a conceptual project. No real-world results are claimed — these are the targets the plan would be judged against.

Activation (first completed game)

Baseline: Not measured — concept stage
Target: Directional improvement vs manual coordination
Why: Discovery plus matching removes the steps where people currently give up.

Match-quality rating

Baseline: Not measured — concept stage
Target: Majority of games rated as a fair match
Why: Skill banding is applied before the game rather than discovered during it.

Month-2 retention

Baseline: Not measured — concept stage
Target: Directional improvement
Why: The post-game recommendation loop is designed to make the next game the default action.

Learnings

What I learned

The differentiator here is match quality, not feature breadth
Reputation and reliability belong in the MVP because trust gates every join decision
ML is only useful once a feedback loop is generating honest data

What I would improve

Run structured interviews with venues and organisers, not only players
Define the skill-estimation approach in more detail before proposing matching logic

Trade-offs I made

Deferred tournaments and commerce despite their appeal — they do not serve activation
Chose a rules-based matching v1 over a learned model to get testable data sooner

What I would test next

Pilot in a single neighbourhood and one sport to build supply density
Instrument the discovery → join → play → return funnel end to end
Validate the skill-banding logic against real match outcomes before automating it

Full project document

Product Management Case Study

PlayNest — Complete Product Management Case Study

Intelligent Community Sports Platform (Concept)

Product StrategyPlayer MatchingPersonalization

PDF document

Full project documentation

PlayNest — Complete Product Management Case Study

Explore the complete product case study including research, strategy, user flows, wireframes, analytics, and product recommendations.

Open PDF Download PDF

Opens in a new tab, or use Download to save a copy.