The Four-Touchpoint Stakeholder Intake System
Four standing rituals that turn chaotic user requests into a governed product intake pipeline
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 95%
Upasna Gautam replaced ad-hoc journalist requests at CNN with a deliberate system of four recurring events: weekly demo days, working sessions, breaking news dress rehearsals, and office hours. Each touchpoint serves a distinct purpose — evangelism, deep workflow co-design, stress testing, and open troubleshooting — so feedback arrives through a known channel instead of ambushing the roadmap. Because users have been along for the whole discovery ride, the product team earns the standing to say 'not viable' and be believed.
Origin
Designed by Upasna Gautam for CNN Digital's core content platform team after observing how editorial requests actually reached her; office hours were the most recent addition, started in 2022.
Core principles
- 01Intake is a system, not an inbox — design the channels before the requests arrive
- 02Each touchpoint has one job; do not collapse them into a single generic meeting
- 03Your users serve their own customers first — you are there to serve them, not the reverse
- 04Trust built during discovery is what buys you the right to reject a request later
- 05Smart repetition across multiple forums is how a new platform gets adopted
How to run it
- 1
Run weekly demo days as an open forum
Facilitate a weekly session with your product design lead and tech lead. Deep dive into existing features, preview upcoming ones, and recreate user workflows in a show-and-tell format. Open it to anyone in the business, not just your direct stakeholders.
Pro tip Treat demo day as evangelism, not status reporting — it is how a legacy-to-new-platform migration gets sold internally.
- 2
Hold working sessions, not 'user testing sessions'
Gather breakout groups of users to recreate their real workflows in the new platform alongside your team. Run three to six two-hour sessions per group before onboarding them. Segment by team, because each team's workflow differs wildly.
Pro tip Rename user testing sessions to working sessions — the framing shifts users from being tested to collaborating.
Watch out Do not assume one team's workflow generalizes; politics, entertainment, health and homepage teams each needed separate sessions.
- 3
Stress test with a scripted crisis rehearsal
Script a realistic high-pressure scenario end to end and run the platform through it with real users while engineers observe. See the dedicated dress rehearsal framework for the full mechanics.
- 4
Open weekly office hours
Block open time where the PM, design partner and tech lead are simply available — for questions, troubleshooting workflow friction, and casual feedback. Once a week baseline; twice weekly during rigorous onboarding phases.
Pro tip Scale office-hour frequency to the onboarding phase you are in, not to a fixed calendar rule.
- 5
Translate needs into one of three verdicts
After each touchpoint, classify every need as (a) something existing you can optimize, (b) something new you will build, or (c) not viable. Communicate the verdict explicitly back to the requester.
Pro tip Deliver the 'not viable' verdict directly — the trust earned across the four touchpoints is what makes it land.
Watch out Skip the relationship-building touchpoints and 'not viable' reads as dismissal rather than judgment.
In the wild
Gautam's team had to move CNN's entire global editorial staff from a legacy content management system to a new one. Rather than pushing a migration plan, they ran demo days to preview features, three-to-six working sessions per team to rebuild each team's workflow live in the new platform, dress rehearsals to prove it under breaking news load, and weekly office hours for friction.
→ Teams were onboarded one by one across 2022, and a previously fragmented product-editorial relationship became, in her words, a unified partnership where 'not viable' answers were accepted.
Common mistakes
Treating stakeholders as a single audience
Different teams have wildly different workflows and vocabularies. One generic feedback session flattens those differences and produces a platform that fits nobody's real process.
Only talking to users when you need something
If your only contact is a testing request, users experience you as an interruption to their real job. The four touchpoints exist so that contact is continuous and mutual.
Is it for you?
Best for
Platform or internal-tools PMs whose users are busy operators (journalists, clinicians, support reps) with a demanding day job and no obligation to serve the product team
Not ideal for
Consumer products with anonymous, high-volume users where quantitative experimentation replaces direct relationships
From the transcript
“I implemented a system to manage that kind of intake with four different touch points or events so we have weekly demo days working sessions…”
“so we used to call them user testing sessions but decided to move away from that and just call them working sessions”
“we usually do three to six of them depending on the size of the group before the team is actually onboarded for two hours per…”
“it's our job to translate their needs into the functions that we a either maybe already have that we can optimize B we build a…”
From the episode
An inside look at how CNN builds product
Upasna Gautam