Specifying Constraints with RED: Required, Expected, Desired

A shockingly effective framework for communicating needs and priorities

Rose Peck

2025-02-21

Every project management tool, framework, or methodology needs a catchy acronym, right?

[🔴 required] We need a single source of truth for our product data
[🔴 required] Cost of server resources must stay within the outlined budget
[🔴 required] We can integrate our data storage with external tools and systems if we need to, to pull in any contextual information that they might store
[🟡 expected] Our system can export data to CSV format
[🟡 expected] Our system can export product data directly to external systems, like our CRM
[🔵 desired] Inlucde some kind of tracking or audit system that shows who inputted what data into the system

Whenever I'm designing a feature, writing an RFD, or putting together a new architecture, I start by writing out the relevant constraints. These define both the goals of the new system (what it's trying to achieve, what it must accomplish, etc.), but also any limits that must be avoided (what costs are unacceptable, what features are explicitly out of scope, etc.).

Lots of methodologies split this process into must-haves and nice-to-haves, to help communicate what's actually necessary, and what can be cut if the team starts running out of time. However, I would take this one step further. I've often found it useful to have a middle category: somewhere to place constraints that are important, but not strictly necessary Things that I'm willing to cut for time, but that I'd really rather not. Or things that are technically nice to have, but that I'd expect any full-fledged solution to have.

So, when writing out my constraints, I use RED:

Required: These are things that must be satisfied for the work to be considered complete
Expected: This is a middle category for things that I would expect to see in a full solution, or that we really want, but can sacrifice if it ends up being a pain
Desired: Things which are nice to have. Good to add if we have time, but quickly cut if we start running out of scope

The block above shows an example of this system in use :)