Review the Conditions

by Kristen DeLap


End of year is review season. Most of that attention points at individuals: what each person delivered, how they grew, where they fell short. Annual reviews are a valuable time to take stock of your successes and your opportunities. 

But questions about an individual only tell half the story. A product team’s outcomes depend just as much on the conditions it worked within. Many of those conditions are set by leadership.

Product leadership exists to create the conditions for success. That means leaders sharing priorities and business context, including the constraints (budget, legal, commercial commitments) that come with them. It means making clear how decisions get made, providing access to users and to evidence (data, market context), and protecting the team’s clarity and psychological safety. It also means standing behind the team when it makes a hard call.

Those conditions let a team understand the problem it’s solving, find solutions that hold up, and own the outcome. When one is missing, the team can feel it acutely. It shows up as rework, as hedged decisions, as a roadmap that drifts and no one is quite sure why.

So before the year closes, take the time to not just do the standard performance review of people, but also review the conditions of the work.


STAND-UP EXERCISE

Bring the team together without leadership in the room. Walk through the below conditions as well as others that might be particular to your business.

  • Do we understand the priorities, and the business context behind them?

  • Do we know our constraints up front, or do we discover them late?

  • Is it clear how decisions get made, and by whom?

  • Can we reach our users and get to the evidence we need?

  • Is it safe to raise a concern, change our minds, or say we don’t know?

  • When we made a hard call this year, were we backed?

Then turn what surfaces through the discussion into a few specific asks for your leadership. “We need more context” is too broad. “We need to know the budget constraint before discovery starts, not after we’ve scoped a solution” is something a leader can act on. Bring those asks to your product or business leaders the way you’d bring any other finding: with evidence, and with a clear sense of what would change.

A team can’t own an outcome it was never set up to reach. Asking for the conditions isn’t a complaint. It’s part of owning the work.

Flat line art illustration of four team members at a whiteboard reviewing a checklist. Some items are checked, others are open.