Use TikTok to investigate the problem your app might solve, the alternatives people mention, and the questions that stop them trying a product. Then choose a test that matches the uncertainty. A viewer asking for an app’s name gives you a different lead from a user describing a failed workout log or a subscription they cancelled.
This guide follows a push-up app example from public comments into a product research plan. The comment findings come from a saved retrieval. A second retrieval supplies three app-related video leads. The interviews and prototype tests below are proposed next steps; we have not run them or measured demand for a new app.
Choose the decision before searching
Write down the decision you need to make this week. “Should I build a fitness app?” leaves too much room for cherry-picking. “Do beginners need help counting repetitions, or help keeping a routine?” gives you two problems to investigate. You can compare how people describe each problem and the workarounds they use.
Define a provisional user and situation: someone starting home workouts who loses track of progress after a few sessions. Treat that description as a recruiting hypothesis. A video’s popularity cannot establish that its viewers match your intended customer.
| Decision | Evidence to seek | Next test |
|---|---|---|
| Which problem deserves a prototype? | Specific accounts of repeated difficulty and existing workarounds | Interviews about the last time it happened |
| Which feature belongs in the first version? | A task people cannot complete with their current approach | Observe that task using a narrow prototype |
| Does the offer make sense? | Confusion about the product, access, or first action | Comprehension test with your intended users |
| Will people pay or return? | Actual purchase and repeat-use behavior | An honest paid offer or a usable pilot |
Keep one primary decision in the research brief. You can save other questions without adding them to the current sprint.
Search the problem, alternatives, and product category
Build three query groups. Category phrases such as “push up app” help you discover demonstrations. Problem phrases such as “how to count push ups” help you investigate the job without assuming an app is the answer. Alternative phrases such as “workout notebook” help you see how someone could solve it without installing anything.
These are proposed search seeds, not measured high-volume keywords. Start with the language your intended users use. If a search returns exercise demonstrations rather than app discussions, keep that result in the exercise group and refine the software query.
Research an app for beginners doing push-ups at home.
Compare three questions: counting repetitions, following a routine,
and seeing progress. Search each question and relevant existing apps.
For selected videos, return the URL, caption, creator and public counts.
Explain why each result fits. Separate app users' reported experience
from viewer questions, jokes and creator claims.
You can do this by searching in TikTok and reviewing the results yourself. TokConnect lets your agent retrieve video metadata and comments into a comparison. For search-topic discovery, TikTok also documents Creator Search Insights. Use topic estimates to choose a research direction; verify the underlying user problem through conversations and observation.
Compare several sources before counting themes
For an initial pass, choose a small explicit sample, such as two relevant videos from each query group. This is a practical research budget, not a statistically representative sample. Include different creators and product alternatives so one successful promotion does not dominate your view.
Record why you included each video. A creator demonstration can explain the offer. A first-person account may reveal how someone used it. A reaction post can contain a different audience with little product experience. Keep those contexts separate when you read their comments.
| Comparison field | What to record | Decision it helps |
|---|---|---|
| Alternative | Named app, notebook, coach, or other method | Who or what you compete with |
| Claimed benefit | The caption’s specific promise, quoted or paraphrased | Which claims need product verification |
| Reported friction | A commenter’s description of an actual experience | Which interview question to ask |
| Access questions | Price, installation, platform, or account questions | What the demonstration leaves unclear |
| Evidence boundary | Video ID, selected comment page, date and selection reason | Whether two findings come from independent sources |
Count both the comments and the number of distinct source videos supporting a theme. Ten complaints under one post deserve a different interpretation from ten complaints spread across several independent demonstrations. Neither count reveals the proportion of the whole market with that problem.
The same search can reveal different product jobs
We ran two additional relevance searches on 18 September 2026, requesting five results each. “Push up app” returned one record; “push up counter app” returned three. One video appeared in both, leaving three distinct videos across the saved responses.
| Source lead | What its caption says | Research implication |
|---|---|---|
| Friction App mention by @itsjustinrr | Replace doomscrolling with push-ups | Investigate reducing phone use as a separate job from tracking exercise |
| PushOff post | Compete with friends in real time | Investigate motivation through competition and the need for a partner |
| Ignite App post | Names the app but gives little product detail | Inspect the product before assigning a benefit or feature category |
The search phrase included “counter,” yet the captions offered distraction reduction and competition. Treat those as different positioning leads. A person trying to stop scrolling may judge success by less phone use; a competitive user may care about finding a friend to play. Interview both groups before assuming one feature set serves them.
We read the returned captions, not the footage or app listings. Verify the product behavior before including a capability in your comparison. Deduplicate by video ID before counting themes: the repeated Friction record is one source, even though two searches returned it.
What the saved push-up example supports
Our saved retrieval requested 50 comments from video 7668908400243133726 and returned 49 records. The response reported 215 total comments and another page. AI-assisted coding assigned 20 records to explicit app-identification requests, four to ambiguous name requests, two to price or access, and one to account-setup friction. The comment-analysis guide contains the full codebook and row-level download.
One commenter wrote, “why are there so many push up games that are the same”. That question suggests investigating how viewers distinguish the products. It supplies no evidence that a particular new feature would win customers. Another comment asks “App name?” That supports making product identification clearer in a demonstration.
These findings favor an inexpensive communication test before a feature expansion. Show the app’s name, explain its first task, and make access terms easy to find. We still need research on exercise habits, problems with current products, and the reason someone would switch.
| Observed in the saved sample | Useful hypothesis | Evidence still needed |
|---|---|---|
| 20 explicit identification requests | Some viewers need a clearer path from video to product | Can intended users identify and find our app? |
| Two price or access requests | Explain access before asking someone to start | Do people understand the actual offer, and will they accept it? |
| One account-setup complaint | Inspect the first-session flow | Can recruited users complete it on their own devices? |
| A comment about similar games | Investigate meaningful differentiation | Which existing alternative fails a task users care about? |
Prioritize problems without inventing demand scores
Make a shortlist based on recurrence, the consequence of the problem, and how people handle it today. Favor a specific recurring task you can observe over a broad feature wish. “I lose my workout history when I change phones” is a sharper interview lead than “add more features.” Those sentences are illustrative examples, not comments from the saved sample.
Keep a separate column for confidence. A clear firsthand account may justify a follow-up interview even if it appears once. Many vague requests may need clarification before you invest. Avoid a weighted numerical score unless your team can explain its inputs and how it changes the decision.
For the current push-up evidence, product clarity has enough support for a low-cost test. Automatic counting, social competitions, and paid training plans remain untested ideas. Adding them to a roadmap now would turn gaps in our research into assumptions about demand.
Ask about the last workout, then observe a task
Recruit people who fit your provisional user description through an appropriate opt-in channel. Public comments provide research leads; they do not grant permission to contact or enroll their authors. During an interview, ask about the most recent workout and the method the person used to track it.
Useful questions include: “Show me how you recorded the last session”; “Where did you stop or lose track?”; and “What did you try before this?” Ask what happened and what they did next. Avoid leading with your proposed feature or asking whether they like your idea.
After discussing the existing task, give the participant one action in your prototype, such as starting a session and finding their previous result. Observe where they need help. Record completion and confusion separately from their opinion of the design. A participant can enjoy the concept and still fail the first task.
Keep comprehension, payment, and repeat use separate
A five-person moderated session can help you find obvious comprehension problems. It cannot estimate market conversion. Decide in advance what a participant should be able to explain: the app’s purpose, the first step, and the real access terms. If several need your explanation, revise the screen and test it again.
To investigate payment, present a real, clearly described offer at a price you are prepared to honor. A waitlist signup measures interest in hearing more; it is a weaker commitment than a purchase. Keep the route, price, and audience fixed when comparing versions, and retain the denominator: ten purchases out of how many eligible visitors, reached through which channel?
To investigate repeat use, give participants a usable product for the routine you want to support. Define a meaningful return action, such as recording a later workout, and choose an observation window that fits the routine. An app open alone may tell you little. A user who returns to complete a second workout provides a different signal from one who opens a notification and leaves.
Set your decision threshold before collecting results. Use your development cost, acquisition plan, and intended use frequency to choose it. There is no defensible universal TikTok-comment threshold that makes an app viable.
A completed next-step plan for this app
Download the research plan to keep current evidence and proposed tests separate while you work.
- Current finding: the selected comment page contains repeated requests to identify the app. Preserve the coding sheet and source ID.
- Immediate test: revise the first screen or demonstration to show the product name, purpose, and actual access terms. Observe whether intended users understand it unaided.
- Open product question: investigate whether beginners struggle most with counting, following a routine, or reviewing progress. Compare independent sources, then interview users about recent behavior.
- Prototype scope: choose one task after those interviews. Keep speculative social or game features outside the first test.
- Commercial check: test an honest offer and meaningful repeat use after people can complete the task. Keep these results separate from the messaging test.
Your output should name the next decision, the evidence behind it, the unresolved assumption, and the cheapest credible test. If the expanded research reveals little pain or workable existing alternatives, pause the feature work. You will have answered a useful product question before spending weeks building around a video’s popularity.