Let the field overrule the roadmap

A roadmap is a forecast. It’s written from dashboards, stakeholder asks and what the team believed last quarter about how people use the product. The field is where you find out whether any of that was true, and in my experience it wins the argument often enough that I’ve stopped treating it as an occasional input.

The decision this essay helps a PM make is when observed user behaviour should change what you build, and how to make that observation cheap enough to do every cycle instead of once a year. Four settings taught me the answer: a local-news app for Tier 2 and Tier 3 users, a creator platform, a multilingual newsroom, and a voting app I run now.

Lokal: watch people where they use the product

At Lokal I was an associate PM owning onboarding and sharing for users in Tier 2 and Tier 3 towns. The roadmap for both was corrected by field usability testing and interviews, run with real users in their own context, away from the office where the flows had been designed.

The funnel charts could show where people dropped. The sessions showed why. We redesigned onboarding around what we observed, and completion rose 9%. We reworked the share formats the same way, and organic installs from sharing rose 10%.

Analytics can tell you that a step is failing. Only watching someone go through it tells you what they believe is happening on the screen. When those two disagree with the roadmap, the roadmap is the one carrying the assumption, so it’s the one that should move.

ShareChat: loop speed is a product decision

At ShareChat I was a product operations lead on Creator Hub, and one change I’d point to is how quickly a creator’s problem reached someone who could act on it. I set up a creator feedback loop that cut query turnaround from 7 days to 2.

I count that as a product decision. The speed of a feedback loop sets how fast the product can learn. A creator who waits a week for an answer may well have moved on or worked around the problem by then, and the signal goes stale before it reaches the roadmap. Cut the wait to two days and the same creators become a steady source of field evidence, arriving while the problem is still live.

If you want the field to overrule the roadmap routinely, this is the cheapest lever. The research you already get is often enough once it arrives fast.

Asianet: adoption is the field talking

At Asianet News I rebuilt the editorial CMS with AI workflows for a network publishing in eight languages. The design decision that mattered most was keeping the publish call with editors. The editor of each language approved every AI-assisted draft before it went out.

The field response to that decision was adoption, desk by desk. Editors took up the tools at their own pace, because nothing in the workflow could publish without them. Editorial output tripled, and that work supported a period in which users grew 130%. I’ve written up how that newsroom system was built.

Adoption by desk was the field telling us the design was right. If a desk had held out, that would have been the signal to go and sit with it, because a tool editors avoid is a tool that’s wrong for how that desk works. Adoption by team or by desk is a field metric you can read without scheduling a single session.

The voting app: an audience with a calendar

The product I run now with the most obvious field signal is a reality-TV voting app I shipped on Android in two languages, now past 10,000 downloads. The show defined its audience before the first build.

The show runs in seasons, so the app is seasonal. It has audiences in more than one language, so the app shipped in two. And the season moves in weeks, so the retention loop is a weekly push notification for the next vote, with a companion web property updated on the same rhythm. Each of those choices follows the audience’s calendar. None of them came from a feature list.

In a product like this, the field sets the plan from the start. When the audience’s behaviour is that legible, the PM’s job is to notice it and refuse to build against it.

Making it cheap enough to do routinely

Field research turns into a habit only when each round costs little. The pattern across all four settings is the same:

Put the sessions on the calendar. A standing slot with real users is cheaper than a research project, because nobody has to approve it each time.
Shorten the loop before you widen it. Faster answers to the feedback you already get beat a new survey.
Use adoption as a field metric. Track uptake by team, desk or market, and go and watch wherever it stalls.
Let the audience’s own rhythm set the cadence. Seasons, weeks and languages are field facts. Build to them.

When the field should win

The field should overrule the roadmap when three things line up. The behaviour repeats across people rather than coming from one memorable session. It contradicts an assumption the roadmap depends on, which is a different thing from contradicting a preference. And it sits on a step that most users pass through, like onboarding or sharing, where a fix moves the whole funnel.

When only one of those holds, write it down and watch for it next round. When all three hold, change the plan.

What this means if you’re the PM

Treat the roadmap as a hypothesis about behaviour, and schedule the observation that tests it. If nobody on the team has watched a real user in the last cycle, the plan is running on memory.

Count feedback-loop speed as a product metric. Moving a loop from a week to two days can do more for what you learn than adding a research study.

Read adoption by unit. A desk, team or market that holds out is pointing you to the next field session.

When the field contradicts a roadmap assumption on a step everyone passes through, the field wins. You own that call, and the evidence for it should be written down where the team can see it.

Lokal, ShareChat and Asianet outcomes are from my résumé roles (2020–2025); the voting app’s download count is from its public Play Store listing.