Feature Intake & Prioritization (CQ)¶

Owner: Vi | Updated: 2026-02-05

Purpose¶

Define how feature requests enter the backlog and get prioritized. Not everything gets built. This SOP ensures the right things get built in the right order.

Feature Sources¶

Source	Examples	Who Captures
Erik/Ryan	Strategic direction, new capabilities	Vi
Client feedback	Support tickets, user interviews	Vi
Internal team	Dev suggestions, UX improvements	Vi
Competitor analysis	Features competitors have	Vi
Bug patterns	Repeated issues indicating missing feature	QA → Vi

Rule: All feature requests flow through Vi. She owns the backlog.

Intake Process¶

Step 1: Capture the Request¶

When a feature request comes in:

Create ClickUp task in "Intake" list
Label it [Intake] in title
Record source (who requested, why)
Add raw notes (don't over-process yet)

Intake task template:

## Source
Who: [Erik/Client/Dev/etc.]
Date: [When requested]
Channel: [Slack/Call/Email]

## Raw Request
[Exact words or summary of what was asked]

## Initial Notes
[Your interpretation, questions, related context]

## Status
[ ] Needs clarification
[ ] Ready for prioritization
[ ] Rejected (reason: ___)

Step 2: Clarify Before Prioritizing¶

Before a feature enters the backlog, Vi should be able to answer:

Question	Why It Matters
What problem does this solve?	Features without problems are waste
Who is the user?	Affects design and priority
What's the success metric?	How do we know it worked?
Is there a reference?	Best-in-market example to imitate
What's the urgency?	Client deadline? Competitive pressure?

If you can't answer these: Go back to the requester before proceeding.

Step 3: Prioritize¶

Vi reviews intake tasks weekly and decides:

Decision	Action
Build Now	Move to backlog, assign phase (Alpha), set deadline
Build Later	Move to backlog, no deadline yet
Need More Info	Request clarification from source
Won't Build	Archive with reason

Prioritization Framework¶

The 4 Questions¶

For each feature, ask:

Impact: How many users? How much value?
Urgency: Is there a deadline? Competitive pressure?
Effort: How long? (Alpha = 3 days, Beta = 2 weeks, Final = 1 month)
Risk: Dependencies? Technical unknowns?

Priority Matrix¶

	Low Effort	High Effort
High Impact	Do First	Plan Carefully
Low Impact	Quick Wins	Don't Do

Priority Levels¶

Level	Meaning	Example
P0	Drop everything	Production broken, major client blocker
P1	This week	Key feature for upcoming demo
P2	This sprint	Important but not urgent
P3	Backlog	Nice to have, do when capacity

Who Decides Priority¶

Priority	Who Decides
P0	Erik or Ryan (Vi can escalate)
P1	Vi (with Ryan/Erik input)
P2	Vi
P3	Vi

Conflict resolution: If there's disagreement, Ryan decides. If Ryan is unavailable, Erik decides.

Weekly Prioritization Ritual¶

When: Every Monday (part of weekly planning) Who: Vi Duration: 30 minutes

Agenda: 1. Review intake list (new requests) 2. Decide: Build Now / Build Later / Won't Build 3. Update backlog priorities 4. Identify top 3 priorities for the week 5. Flag anything needing Erik/Ryan decision

Output: - Updated backlog - Clear top 3 for the week - Escalations to Ryan if needed

Saying No¶

Not everything gets built. Valid reasons to reject:

Reason	Example
Doesn't solve real problem	"Nice to have" with no user need
Too small impact	Helps 1 user, not worth engineering time
Not aligned with strategy	Feature that pulls us off focus
Already exists	User doesn't know about existing feature
Technical debt	Requested feature would add complexity without value

How to reject: 1. Thank the requester 2. Explain the reason briefly 3. Offer alternative if possible 4. Archive the task with reason documented

Example rejection:

Thanks for the suggestion! We're not going to build this because:
- Only affects ~2% of users
- Workaround exists (export → edit → import)
- Would add complexity to an already complex flow

If this becomes a bigger pain point, we can revisit.

Feature Request Template (for devs)¶

When devs suggest features, use this format:

## Feature Request
[One sentence description]

## Problem
What problem does this solve? Who has this problem?

## Proposed Solution
How should it work? (Don't need full spec, just the idea)

## Why Now
Why is this important now? What's the impact of not doing it?

## Reference
Link to competitor or example (if applicable)

Red Flags¶

Reject or push back when you see:

Red Flag	Response
"I think users might want..."	"Which users? Any evidence?"
"Competitor X has this"	"Do our users need it? Why?"
"It would be cool if..."	"What problem does this solve?"
"Can we just add a small..."	"What's the impact? Who benefits?"
"Erik said to do this"	Document it, but still clarify scope

Integration with Other SOPs¶

SOP	Connection
Task Creation Standards	Features become tasks with deadlines
Alpha-Beta-Final	Features enter at Alpha phase
Weekly Planning	Priorities reviewed weekly
Scope Change	When requirements change mid-build

FAQ¶

Q: What if Erik asks for something directly? A: Still goes through intake. Vi creates the task, clarifies scope, sets deadline. Erik's requests get priority but still need documentation.

Q: Can devs start features without going through intake? A: No. All features flow through Vi. This ensures we're building the right things.

Q: What if there's too many P1s? A: You have a prioritization problem. Force-rank them. There can only be one #1 priority.

Q: How do we handle "quick wins"? A: If truly quick (<30 min), dev can just do it and report in daily update. If longer, it needs a task.

Summary¶

Principle	Why
All features through Vi	Single point of prioritization
Clarify before building	Don't build the wrong thing
Say no to low-impact work	Protect dev capacity
Document rejections	Learn from patterns, avoid repeat requests
Weekly review	Keep backlog fresh and prioritized

The goal: Build the right things, in the right order, for the right reasons.