Stakeholder Feedback Request (CQ)¶
Owner: Vi | Updated: 2026-02-05
Purpose¶
Help developers get input from stakeholders (Erik, Ryan, clients) without hesitation. Asking for feedback is not bothering people—it's how we build the right thing.
The problem we're solving: Devs build in isolation → ship wrong thing → rework.
The fix: Ask early, ask often, ask with structure.
Mindset Shift¶
| Old Thinking | New Thinking |
|---|---|
| "I'll ask when it's ready" | Show early, even if rough |
| "I don't want to bother Erik" | Erik wants to see progress—silence worries him |
| "What if they don't like it?" | Better to know now than after you've built it |
| "I should figure this out myself" | Your job is to build the right thing, not guess |
Feedback is not judgment. It's alignment.
When to Request Feedback¶
Mandatory Checkpoints¶
| Phase | When to Request | What to Show |
|---|---|---|
| Alpha | Feature is roughly working | Prototype, core flow, "does this direction make sense?" |
| Beta | Feedback incorporated, more polished | Full flow, edge cases, "anything missing?" |
| Before Final | Ready for polish | Complete feature, "ready for designer?" |
Optional (But Encouraged)¶
| Situation | Request Feedback |
|---|---|
| Unsure about requirement | Before you start building |
| Multiple ways to implement | Before you pick one |
| Edge case unclear | Before you handle it |
| UI/UX decision | Before you finalize |
| Something feels wrong | Trust your instinct, ask |
Rule of thumb: If you're guessing, ask.
Who to Ask¶
| Question Type | Ask | Channel |
|---|---|---|
| Requirements / "what to build" | Vi first → Ryan if needed | #cq-product or DM Vi |
| Priority / "should we build this" | Ryan | #cq-product, tag Ryan |
| Product direction / strategy | Ryan → Erik | Ryan will loop Erik |
| Technical approach | Senior dev or Ryan | #cq-product |
| Design/UX opinion | Vi → Designer | Vi coordinates |
| Client-specific question | Ryan | Ryan handles client comms |
When in doubt: Ask Vi. She'll route to the right person.
How to Request Feedback¶
The Template¶
Post in #cq-product:
**Feedback Request: [Feature Name]**
**Phase:** Alpha / Beta / Pre-Final
**Link:** [Staging URL or Loom video]
**Context:** [1-2 sentences on what this is]
**Specific Questions:**
1. [Question 1]
2. [Question 2]
3. [Question 3]
**Decision needed by:** [Date, if time-sensitive]
@vi @ryan (or whoever is relevant)
Example: Good Request¶
**Feedback Request: User Dashboard Redesign**
**Phase:** Alpha
**Link:** https://staging.cq.app/dashboard (login: test@test.com / password123)
**Context:** Rebuilt the dashboard layout to show key metrics upfront.
This is rough—focusing on layout and information hierarchy.
**Specific Questions:**
1. Is this the right data to show first? (Active users, revenue, churn)
2. Should the date range selector be top-right or integrated into each card?
3. Any critical metrics missing?
**Decision needed by:** Thursday (so I can move to Beta)
@ryan @vi
Example: Bad Request (Don't Do This)¶
Hey can someone look at the dashboard and let me know what you think?
Why it's bad: No link, no context, no specific questions, unclear who should respond.
Async Demos (Recommended)¶
For complex features, record a quick video instead of just a link.
Loom Format (2-3 minutes)¶
- Intro (10 sec): "This is Alpha for [feature]. Looking for feedback on [X]."
- Walkthrough (1-2 min): Show the flow, narrate what you built
- Questions (30 sec): "Specifically, I need input on [1, 2, 3]"
Why video works: - Shows intent, not just output - Erik/Ryan can watch anytime (async-friendly) - You explain your thinking—stakeholders understand your decisions
Response Expectations¶
| Request Type | Expected Response Time |
|---|---|
| Alpha review | 24-48 hours |
| Beta review | 24 hours |
| Urgent/blocking decision | Same day (mark as urgent) |
| "Nice to have" input | 48-72 hours |
If You Don't Get a Response¶
| Time Passed | Action |
|---|---|
| 24 hours | Ping in thread: "Bump—need input to continue" |
| 48 hours | DM Vi: "Haven't heard back on [X], can you help?" |
| 72 hours | Vi escalates to Ryan |
Don't sit waiting silently. Follow up.
For Stakeholders: How to Give Good Feedback¶
DO¶
- Be specific: "The button should say 'Save' not 'Submit'"
- Prioritize: "Must fix X, nice-to-have Y"
- Explain why: "Users might be confused because..."
- Respond quickly: Dev is waiting
DON'T¶
- "I don't like it" (why? what specifically?)
- "Let me think about it" then disappear
- Redesign the whole thing at Beta (should've caught at Alpha)
- Give feedback outside the thread (keeps everything together)
Feedback Loop Hygiene¶
After Receiving Feedback¶
Dev responds in thread:
Thanks! To confirm:
- [ ] Will fix: [X]
- [ ] Will fix: [Y]
- [ ] Question: You said [Z]—did you mean [A] or [B]?
ETA for next version: [Date]
After Applying Feedback¶
Updated based on feedback: [new link]
Changes made:
- [X] → done
- [Y] → done
- [Z] → handled differently because [reason]
Ready for next review.
Making Feedback Safe¶
For Devs¶
- Feedback on your work ≠ feedback on you
- "This needs changes" ≠ "You did bad work"
- The goal is shipping the right thing, not being right
For Vi/Ryan¶
- Start with what's working: "The core flow is good. A few tweaks..."
- Be direct but kind: "This needs to change" not "This is wrong"
- Remember: Showing early takes courage. Reward it.
FAQ¶
Q: What if my Alpha looks really rough? A: That's fine. Alpha is supposed to be rough. Say "This is early—focusing on [X], not polish."
Q: What if I disagree with the feedback? A: Respond with your reasoning. "I hear you on X, but I did it this way because [reason]. Should I change it anyway?" Healthy discussion is good.
Q: Can I skip Alpha and go straight to Beta? A: Not recommended. Alpha catches direction problems early. Skipping it risks more rework.
Q: What if Erik gives feedback that contradicts Ryan? A: Ask for clarification. "Ryan said X, but Erik said Y—which should I follow?" Vi/Ryan will align.
Q: How much feedback is too much to ask for? A: If you're at a checkpoint (Alpha/Beta) or genuinely stuck, ask. If you're asking every hour, you might need more context on the feature—ask Vi for a briefing.
Summary¶
| Step | Action |
|---|---|
| 1 | Build to checkpoint (Alpha, Beta, etc.) |
| 2 | Post feedback request with link + specific questions |
| 3 | Wait for response (follow up if no reply in 24 hrs) |
| 4 | Apply feedback, confirm what you changed |
| 5 | Continue to next phase |
Ask early. Ask specific. Ask often.