How to build a feature request tracker in Notion without a template
You need five properties and two views, and none of them are exotic: a title, a Status property, a Multi-select for the product area, a Created by property, and a Relation to whatever you use for engineering work. Everything else people bolt onto a "feature request tracker" template is decoration on top of that. Build it from a blank database in about ten minutes, and it will hold up until the point where the problem stops being "what properties do I need" and starts being "how do I know this is the same request I already have."
That second problem is the real one: a Notion database is a place to put requests once you already know about them. It has no opinion on whether two requests are the same idea said twice, and no way to see a request that never got typed in. Keep that limit in view while you build, because it decides how far this setup can take you.
Step 1: pick the properties, not a template
Skip the Notion template gallery. Templates arrive pre-loaded with properties for problems you don't have yet: a rollup for a linked "Customers" database you haven't built, a formula for a scoring system nobody on a five-person team is going to maintain. Half the setup work becomes deciding what to delete. Start from a blank database instead and add exactly this:
- Name (Title): the request written as a full sentence, not a fragment like "exports"
- Status: Notion's Status property type, not a plain Select. Notion's own property reference groups Status options under three categories (To-do, In Progress, Complete), so a board view sorts into meaningful columns automatically instead of however you happened to order a Select list
- Area (Multi-select): the product surface the request touches, tagged with something like
billing,reporting, orpermissions. Multi-select because some requests genuinely span two areas; a plain Select forces a single tag and you'll fight it within a week - Asked by (Created by): Notion fills this in automatically with whoever added the row, so you never have to type it
- Linear issue (Relation): connects the row to your issue tracker once the request is actually being built
That's the whole schema. A DEV.to walkthrough on using Notion as an issue tracker lands on a similar shape from the other direction, with text, a couple of tag-style properties, and a Select-driven board, which is a good sign this isn't a personal preference so much as the natural minimum for the job.
“export is broken for us”
“any update on SSO?”
“we hit the rate limit again”
Read + clusteredStep 2: build the two views that actually get used
Properties without views are just a spreadsheet with extra steps. Two views cover the daily and monthly use of this database:
- A board view grouped by Status, filtered to hide Complete. This is the view you open to answer "what's in flight," and it should never require a filter click to be useful.
- A table view grouped by Area, sorted by created time descending, with Complete included. This is the view for a monthly look at volume by product surface: "reporting had eleven requests this month" is a sentence this view gets you to in one glance.
Notion's views documentation confirms both moves are supported per-view without side effects: "You can view the same database in multiple ways, and switch back and forth between them depending on your needs," and each view keeps its own filters and sort order, so the board staying uncluttered doesn't cost you the shipped-history table.
Resist adding a third view before you've used these two for a month. An unused view is a maintenance cost with no payoff, and the fastest way to make a teammate distrust the database is to show them two views with different numbers in them because one has a filter the other doesn't.
Step 3: log requests where they happen, in one sentence
The database only works if adding a row is faster than not adding one. The habit that holds up: whoever hears the request, whether that's support, sales, or an engineer sitting in on a customer call, opens the database from a bookmark, adds one row with a full-sentence Name, tags one Area, and leaves Status at To-do. No triage happens at intake. Triage is a separate, scheduled pass, not something you ask someone to do in the middle of a call.
A trucking software team's first month with it
Milford builds fleet-maintenance software for regional trucking operators, nine people total, and Teagan Pryce handles product there. Before this, feature requests lived wherever they were first said: a pinned Slack message here, a note in a call doc there. Teagan was the only person who remembered most of them.
"I built the five-property version in an afternoon and told the team: if a customer asks for something, it gets a row before the call ends," Teagan said. "For about three weeks it was genuinely great. I had a board I could point to in a planning meeting instead of my memory."
The cracks showed up in week four. A sales rep logged "need to export driver logs as CSV," and two weeks later a support rep logged "customer wants to download the driver log in a spreadsheet." It was the same ask, worded differently enough that neither of them noticed, and both rows sat in the To-do column collecting their own separate histories.
"I only caught it because I happened to read both rows back to back while grouping by Area," Teagan said. "If I'd been out that week, we'd have shipped it and only realized after the fact that we'd told two different customers 'noted' for what was one request, not two. And that's just the ones that got typed in at all. I have no idea how many just got answered on a call and forgotten, because nothing about the database tells me what's missing."
Three gaps that show up as requests pile up
Be specific about the limits, because they show up in a predictable order as volume grows past what one person can hold in their head:
- No dedup. Notion has no built-in way to flag that two rows describe the same request. Catching it depends on someone reading closely, and that gets less reliable every time volume climbs past what it was the month before.
- No cross-source aggregation. The database only contains what got manually typed in. A request mentioned in a Slack channel, a support ticket, or a sales call that nobody re-typed here doesn't exist as far as this system is concerned. It isn't logged as zero; it's simply absent, which is worse, because nothing prompts anyone to notice the gap.
- Ranking is a headcount, not a demand signal. A Multi-select and a Status property tell you what was said and what state it's in. They don't tell you which requests came from paying accounts versus which came from one enthusiastic user, unless you build that out separately.
Past that point, teams add a layer that reads requests out of the places they're actually said, instead of depending on someone to notice and re-type them. That's the category Modem works in: it reads feature requests directly out of Slack, support tickets, and sales calls, matches differently-worded mentions of the same ask into one counted topic the way "CSV export" and "download as spreadsheet" should have matched for Teagan, and keeps every requester attached to it. Modem's Notion integration can write those counted topics into your workspace as pages or database rows, with your approval, so the two-view structure above keeps working; only the source of the rows changes, from someone remembering to type them to Modem reading them directly. Modem is what we build, so read that recommendation knowing where it comes from: the plain database above is a genuinely fine system for a team small enough that one person can still read every row.
Related reading: how to handle duplicate feature requests goes deeper on the dedup problem specifically, and how to centralize customer feedback covers the wider version of the cross-source gap once requests are landing in more than one tool.
The setup in one pass
Create the five properties above in a blank database, add the board and table views, and put the intake rule (one sentence, one Area tag, no triage at capture time) somewhere the whole team will see it. That's the entire native system, and it will carry a small team further than a downloaded template with forty unused properties ever would.
