As a product manager, you sometimes need to demo a feature that is not live in production yet. In development or staging, the data can be messy, inconsistent, or not very informative (E.g. TestUser1), so you may want more meaningful data that better shows how a feature works.

My manager told me about Requestly, a browser add-on that lets you turn test data into meaningful demo data right in your browser. I tried it, and in this post I share the steps I followed and why I recommend this approach when you need to present features that are still in development.

Why I Tried This

• Test environments showed random values that didn’t help the story.
• I needed clean screenshots and short videos for reviews.
• I wanted a method I could control myself, without asking for a new build.

What I Wanted to Achieve

• A simple and believable story for the demo
• Safe and anonymized content
• The option to switch between two “versions” of the story quickly
• Less dependency on engineering for every presentation

The process I Followed

1) Write the demo story

I drafted a short plan: which pages I would open, and what I wanted the viewer to notice on each page.

2) List the screens and target areas

I opened the staging app and made a checklist for each page: which labels or values should read better for a demo audience.

3) Create a tiny “demo pack”

I prepared one small JSON object with the demo values I wanted to show. Later, I made a second pack so I could switch context fast (for different audiences).

4) Configure the script settings

5) Ask AI for a starter script

I asked AI to draft a short Requestly script that:

• runs only on my demo pages,
• replaces the text I listed,
• keeps the same font size and spacing as the app.

It gave me a first version in seconds.

6) Test → describe issues → get AI fixes

I tested the script and told AI exactly what I saw:

• “This part changed, but the font looks different.”
• “After I click a tab, the old text comes back.”
• “These items should be on separate lines.”

AI replied with small code edits to fix style, add clean line breaks, and re-apply the changes after tab or route changes. I pasted the edits, tested again, and repeated until it looked native.

7) Add a second demo pack

Once the structure worked, I duplicated the data pack. Now I can pick the right story for each meeting by switching one block at the top of the script.

When Would I use Requestly Instead of Creating my Own Test Data?

• You need a demo fast. No time for a new build or a data-seeding task.
• It’s about presentation only. You’re replacing names, emails, labels, or numbers so the story is clear.
• You need anonymized info. Replace real people/companies with safe placeholders on the fly.
• The backend isn’t ready yet. APIs return partial data, but you still want to walk through the flow.
• The environment keeps resetting. Your seeded records disappear; Requestly lets you keep the demo steady.
• Different audiences, different stories. Keep two JSON packs (e.g., “prospect” and “internal”) and switch in seconds.
• You don’t have access to edit data. No DB permissions, no problem.
• You’re polishing visuals. Clean line breaks, consistent formats, and readable values for screenshots and short videos.

Final note

I think this can be very useful for my demos from now on. I can show meaningful data without asking developers for a rebuild or new flags. As a PM, I can choose the story I want to tell and create the demo data to match it, while the app behavior stays the same. If I need to change the story or present it to a different stakeholder, I can switch the data myself in seconds.