Product research always becomes too big for me.
One question becomes calls, screenshots, metrics, competitor screens, stakeholder opinions, and suddenly I am lost.
That happens when research starts as a topic.
Do not start with "research subscription users." Start with the decision you need to make.
What does that mean in real work?
For Pocket FM Premium, the useful question was not whether users like subscription.
Many users like paying once and getting more access.
The harder question was: can subscription feel valuable without breaking the coin economy?
Now research has tension. User value on one side. Business model on the other.
So before research, write the decision?
Yes.
Write: we need to decide X. The risk is Y. Research should help us choose between A and B.
Bad: "research the paywall." Better: "find out if users understand daily access, not unlimited catalogue access."
What do I do before talking to users?
Write what can go wrong.
For subscription, maybe users think Premium unlocks everything, do not understand why coins still exist, feel tricked at renewal, or do not see savings.
Failure cases make your research sharper.
Where do metrics fit?
Metrics tell you where something is breaking. User words help you understand why.
If listening is weak after a Premium trial starts, the number tells you there is a problem.
The user may have missed the benefit, picked the wrong show, misunderstood the unlock, or expected unlimited access.
Should I wait for a polished flow before testing?
No. Test the smallest risky part.
If the problem is explaining "60 minutes daily unlock," test that line, one locked episode state, or one rough paywall.
If people do not understand the promise, polishing the full flow will not save it.
How do I share findings without making a big deck?
Use examples.
Instead of writing "users are confused about Premium benefits," show the current copy, what the user thinks it means, where it breaks, and the new copy or state.
Research should turn into design choices quickly.
Which users should I inspect?
Look at broken moments.
Users who start a trial but do not listen. Users who see the paywall but still buy coins. Users who cancel after renewal. Creators who open a writing tool but do not publish.
Successful users show what works. Dropped users show what is leaking.
And business risk?
Sometimes user needs and revenue fight each other.
Make that tradeoff visible.
Giving too much access can hurt coins. Giving too little can hurt conversion. Both are product risks.
Good research does not only say what users want. It helps the business choose what it can safely do.
So the loop is simple?
Start with the decision. Write what can go wrong. Check behavior and words together. Test the smallest version. Turn findings into examples. Share the rough version early.
Research should make the next product decision easier.
How to practice product research without getting lost
A practical loop for product design research, using examples from subscription, paywall, player, and creator flows. This is about starting with the decision, finding the risk, and turning messy signals into design choices.
By Devendra SinghNotes between me and myself