Do, Try, Consider — How we give product feedback at Asana

How do you empower your team while ensuring consistent, high-quality results?

Some companies get stuck choosing one — either leaving decisions entirely to the teams and not being able to enforce quality, or giving lots of mandatory feedback and leaving the team feeling disempowered. Some people alternate between both and leave the team confused about what was mandatory or not.

A while back at Asana we noticed teams were laser focused on shipping and would carefully ask if each piece of feedback was “launch blocking” at our launch reviews. Often non-blocking feedback would be brushed aside even if it was relatively cheap and would really improve the quality of the product.

We reflected on what was happening and realized that we didn’t have clear language or norms on how to give or respond to feedback. And so, the Do, Try, Consider framework was born.

The Framework

When leaders give feedback on product work like designs, specs, or during launch review, we say explicitly if it is a Do, Try, or Consider. The note taker creates a task for each do, try, and consider, and assigns it to the relevant person for follow-up.

Note: We only use “Do”, “Try”, or “Consider” for constructive feedback on the work, not for regular action items like “Set up training with the sales team” or “Come back Wednesday with the next version”.

Do

“Do” is used for mandatory feedback. It overrules the team, and so we use it very rarely — just for times when a decision is hard to reverse and has a big impact on quality or system complexity. Most projects never get any “do” feedback, and the rest mainly get 1 or 2.

To reduce disempowerment and micromanaging, we try to give “do” feedback framed as a problem or goal rather than a specific solution:

Do: Make sure there’s a good first experience in the empty state

Do: Find a solution that doesn’t increase eng debt

“Do” feedback is appropriate when the quality bar impact or systems impact goes beyond the scope the team is responsible for. For example a change might break workflows, cause thrash, be hard to reverse, affect the marketing moment success, or be misaligned with the company’s future vision. We see this in cases of eng debt, design debt, complexity, or inconsistency.

How to respond to “Do” feedback

Teams try to find a solution and implement it by the next milestone. Then they’ll loop back with stakeholders to let them know it’s done.

Sometimes the team finds out the solution will be much more expensive than anticipated or other surprises come up… that’s ok, they can discuss the new information with the person who gave the feedback. “Do” means “this feedback is not optional”, not “Do this no matter what and don’t ask any questions”.

It usually takes, minutes, hours or days to incorporate “do” feedback.

Try

“Try” is used to request a specific exploratory next step like drawing some options or looking into the code to cost something. After doing the exploration, the team is empowered to decide whether to change course or not.

We use “Try” when we think the proposed solution has tangible downsides and we think more exploration or investigation would likely lead to a better outcome. We also use “try” for little mistakes or rough edges we catch in launch review — they should be fixed as long as the investigation shows they’re cheap. It’s pretty normal to get 1–3 pieces of “Try” feedback in a project across design and launch review.

The “try” feedback can have more of a suggested solution, since the team is fully empowered to take the feedback or not once they’ve explored it:

Try: Explore options that show more content on the screen, such as removing the header

Try: Truncate the text when the task name is very long

Try: See if we can solve this with an existing design pattern instead of inventing a new one

“Try” feedback is appropriate when you think the extra time for exploration is really worth it, which is why it usually happens when a product leader has a hunch for an alternate solution. For example a team might have narrowed in on a single solution quickly because they’re trying to move at high velocity, but they missed a potential direction that would create a better user experience and save time.

How to respond to “Try” feedback

Teams share the explorations back to stakeholders and with let them know if they are going to use one of the new explorations or stick with the original plan:

“Here are some quick mocks where we tried decreasing the line height, decreasing the font size, removing the header, and letting the header scroll off screen. We’re going to go with the scrolling option.”

“We looked into truncating the text, and it turns out that part is rendered by a third party component that we can’t easily update, so we’re going to leave it as-is.”

It usually takes minutes or hours to incorporate “try” feedback.

Consider

“Consider” is used to share ideas or alternate ways of thinking about a problem. After thinking through the point briefly and responding, the team is empowered to take the feedback or not.

We use “consider” frequently because we believe in coaching through the work — even if the ideas wouldn’t be worthwhile to change on the current project, they might be helpful for the next project.

By marking these ideas as “consider”, we make it clear exactly how optional the feedback is: it’s not just a random idea that the team can brush off without thinking about it, and it’s not so lightweight that it doesn’t need a response, but the team is fully empowered to respond however they want. The response is helpful because it catches miscommunications and lets stakeholders know the real state of the product so they can share the correct information across teams.

The “consider” feedback is often framed as a question:

Consider: Could we combine the two screens into one?

Consider: How might we make the entry point more discoverable?

Consider: Does the button have a strong enough call to action?

Consider: How might we get project color to show up on timeline?

“Consider” feedback is appropriate when you think people on the team will benefit from thinking about an idea, and you’d be okay if they did not take the feedback. When teams have a plan for validating their ideas, such as running an A/B test or having a beta program, most feedback can be “consider”.

How to respond to “Consider” feedback

Teams think about the feedback and respond either in the moment, or in a written follow-up.

Responses can be very short:

“We’ll do this”

“The user research we did before showed the current way is already very discoverable.”

“Ideally we’d show project color but I don’t think it’s important enough to be worth the iteration cost”.

It usually takes seconds or minutes to respond to “consider” feedback.

Do, Try, Consider has worked really well for us at Asana, and we’d love if you’d try it out at your companies. Let us know how it goes!