Most feedback I've received has been vague and hard to act on. I started using a simple mental model to make it clear what to do now, what to explore briefly, and what to just keep in mind.
I want each piece of feedback to answer a simple question: what should we do next?
The Do–Try–Consider model
Every piece of feedback fits into one of three categories: something that must happen (Do), something to test out (Try), or something to keep in mind (Consider).
- Do: Non‑negotiable requirement or quality bar. Phrase it as an outcome, not a solution.
- Try: A small, time‑boxed exploration to de‑risk a hunch. The team decides after the spike.
- Consider: An optional perspective that sharpens thinking. Acknowledge, then move on.
Do
On my team, I use Do when the decision is hard to reverse or impacts quality or security beyond the team's scope.
- Do: Fix the broken login button before launch.
- Do: Add error handling for the payment flow.
- Do: Remove the hardcoded API key from the code.
How to respond: Commit to a solution by the next milestone. If the cost balloons, sync and renegotiate.
Try
I reach for Try when a quick spike will likely lead to a better outcome.
- Try: Test the new button color with 10% of users for a week.
- Try: Replace the dropdown with radio buttons and see if it's clearer.
- Try: Cache the API response and measure if the page loads faster.
How to respond: Share the findings (one paragraph or a few numbers) and either adopt or keep the original.
Consider
I use Consider when the idea is helpful to think about, even if nothing changes now.
- Consider: Change "Delete" to "Remove" to sound less harsh.
- Consider: Add a search bar to help users find things faster.
- Consider: Use icons next to menu items for better recognition.
How to respond: Acknowledge briefly: “We’ll do this” or “Keeping as‑is due to X.”
How I apply it to PR reviews
I've just introduced this mental model to my team, starting with PR reviews (pull requests: where we review each other's code changes before they go live). It's been a natural gateway to using Do–Try–Consider across all our feedback, since code reviews happen daily and give us lots of practice.
The same Do, Try, Consider labels work just as well outside engineering—in 1:1s, planning meetings, or any place where you want clearer, more actionable feedback.
Inspired by Do, Try, Consider — How we give product feedback at Asana by Jackie Bavaro.