I Didn't Start With the Feature. I Started With the Problem.
I Didn't Start With the Feature. I Started With the Problem.
A self-initiated Instagram product case study to practice product thinking
When we talk about building products we often start with the feature. We think about what could be added, what the interface could look like or what users might find interesting.. I have started to think that this is often the wrong starting point. A feature can sound impressive. Still fail to solve a problem that users genuinely care about.
So of starting with a feature I started with a simple question: What is one problem Instagram could solve better? That led me to event discovery.
Instagram is already one of the places where people discover things happening around them. College events, workshops, exhibitions, open mics, meetups, pop-ups and local communities are constantly creating content. The information is there. The problem is that discovering something often requires too much effort. You might search hashtags look through Stories check location tags find a creator who posted about something or simply wait for a friend to share it. So the problem isn't necessarily a lack of content. It is the fragmentation of discovery.
If I want to know “What can I actually do this weekend near me?” Instagram doesn't currently organize the experience around that question. That became the problem I wanted to explore.
I Started With the User, Not Instagram
To make the problem more specific I imagined a user I called the **Weekend Planner**. This is someone who already spends time on Instagram enjoys discovering experiences is open to attending local events but doesn't necessarily know where to find them. They might discover an event through a post or Story but by the time they see it the event may already be over.That made me think about the journey.
The user wants to do something → starts searching → finds scattered content → checks the date → checks the location → tries to understand whether the event is actually relevant → and eventually decides whether it is worth attending.
There are opportunities for the user to drop off.
Ø Maybe they don't find anything.
Ø Maybe they find something, cannot easily determine whether it is nearby.
Ø Maybe the information is buried in a caption.
Ø Maybe there are many irrelevant posts.
The opportunity therefore wasn't simply to show users* events*. It was to make events easier to discover.
Then I Considered Solutions
Once the problem was clear I deliberately avoided jumping into one solution. I considered three directions. The first was InstaMap, a map-based experience showing events happening nearby. It makes location the discovery mechanism, which is intuitive but it also creates a potential problem: a map could quickly become crowded with events and proximity alone doesn't tell the user whether an event is actually relevant to them.
The second was Explore Local, a discovery experience where users could see events based on their location and interests. Of asking users to search through ordinary Instagram content the product would organize local experiences around questions such as
* What’s happening this weekend? What's popular nearby? What might interest you?*
The third was a **Group Hangout Planner**, where users could discover events and then coordinate with friends. This was interesting because it built on one of Instagrams existing behaviours: sharing and social interaction. It also introduced more complexity because the experience depends on multiple people participating.
After comparing the three I chose Explore Local as the MVP.
Not because it was the exciting idea but because it was the simplest way to test the underlying hypothesis.
The Hypothesis Was Simple
The hypothesis I wanted to test was:
If Instagram makes relevant local events easier to discover users will engage more with content and show stronger intent to attend those events.
Notice that the hypothesis isn't “people will love the feature.” That isn't particularly useful. The useful question is whether changing the discovery experience actually changes behaviour. That is why the MVP doesn't need dozens of features. A user should be able to discover a local event open it save it and share it. The first version doesn't need to solve event management, group planning, ticketing, payments or every possible edge case. The objective is simply to determine whether the core behaviour exists.
Then I Had to Decide What Success Actually Means
This is where I think product thinking becomes different from designing a feature. If I launched Explore Local I wouldn't consider it successful just because people opened it. I would want to understand what happens after the interaction.
Ø Do users click on the events they see?
Ø Do they save them?
Ø Do they share them with friends?
Ø Do they actually express an intention to attend?
Most importantly do they come back and use the discovery experience again?
So I would think about the product as a funnel:
Event impression → Event view → Save/Share → RSVP or intent → Attendance → Repeat discovery
Each stage tells us something:
Ø If impressions are high but event views are low the problem may be relevance or presentation.
Ø If views are high but saves are low the events may not be compelling.
Ø If saves are high but attendance is low there may be friction after discovery.
The metric isn't there to report performance. It helps us understand **where the product is failing**.
But Every Product Creates New Problems
The idea also made me think about what could go wrong,
The first issue is privacy.
A local discovery product naturally creates pressure to use location data.. Asking users for precise continuous location access could make the experience feel intrusive. A better approach could involve location, manually selected areas or explicit location preferences.
The second issue is quality.
If every creator, business and organizer starts promoting their event Explore Local could quickly become another feed. Of solving discovery we would simply create another place filled with noise.
That means the ranking system becomes extremely important.
The product shouldn't just ask:
“What events are available?”
It should ask:
“Which events are actually relevant to this person?”
That could mean considering factors such as location, interests, freshness, engagement and quality. Otherwise the product risks replacing one discovery problem with another.
What I Actually Learned From Building the Case
The useful part of this exercise wasn't coming up with the Explore Local feature. It was realizing how quickly a product idea can sound good without being well defined.
“Instagram should have local events.” Sounds reasonable.
But it doesn't tell us who has the problem what the current friction is, why existing behaviour isn't enough what hypothesis we are. How we would know whether the solution worked. Once I forced myself to answer those questions the idea became more concrete. It also became smaller. That was probably the important part. I didn't need to build an entire events ecosystem.
I needed to test whether better local discovery could change user behaviour.
The Product Lesson
This case study changed the way I think about product ideas. Earlier it was easy to think:
Problem → Feature → Build
The more useful sequence is:
Problem → User → Friction → Hypothesis → Solution → Experiment → Measure
The feature comes somewhere in the middle.
That distinction matters because product managers aren't simply deciding what features should exist. They are making decisions under uncertainty about users, behaviour and business outcomes. A feature is an answer. Before building it you need to know what question you're actually trying to answer.
The Takeaway
I didn't build this case study because I thought Instagram needed another feature. I built it because I wanted to practice thinking like a product person.
Instead of asking:
“What can we build?”
I wanted to start with:
“What problem are we actually solving?”
Then ask:
“What would have to change in user behaviour for us to believe we've solved it?”
That shift sounds small. It changes the entire process, because good product thinking isn't about having the interesting feature idea.
It is about being able to connect a problem, to a specific user, a testable hypothesis and a measurable outcome.
That is ultimately what I wanted to practice with this case study.