Company Context

NoteFlow is a Series B workplace productivity SaaS company with 3.5M monthly active users across individuals, startups, and mid-sized teams. Its core product helps users capture meeting notes, organize documents, and collaborate asynchronously. The company has strong adoption in self-serve accounts, but paid team expansion has slowed over the last two quarters.

Problem

The product team receives user feedback from many channels: in-app surveys, app store reviews, support tickets, sales calls, community forums, and customer interviews. Today, this feedback is handled inconsistently. Teams often react to the loudest requests rather than the most important user problems. As a result, NoteFlow shipped 6 major improvements in the last 2 quarters, but only 2 drove measurable adoption, and NPS has remained flat at 31.

Recent research shows three recurring themes: new users struggle to understand the product's core workflow in their first week, team admins want better control over shared workspaces, and power users request more customization. Engineering capacity is limited, and leadership wants a clearer process for turning feedback into product decisions without slowing delivery.

Deliverables

1. Explain how you would incorporate user feedback into NoteFlow's design process from collection through launch.
2. Identify which user segments and feedback signals you would prioritize first, and why.
3. Describe how you would distinguish between feature requests and underlying user needs.
4. Propose how product, design, engineering, support, and sales should work together in this process.
5. Define success metrics to evaluate whether the feedback-driven design process is improving product outcomes.

Constraints

• You have one product designer, one user researcher, and two product managers supporting three squads.
• The team can only run 8-10 in-depth user interviews per month.
• Engineering can support one medium-sized improvement and two small UX changes in the next quarter.
• Leadership expects a repeatable process within 6 weeks, not a one-off recommendation.
• You cannot rely on building a large new research operations tool; use lightweight workflows and existing systems where possible.