My “Now, Soon, Future” Framework for Recommendations

As a consultant, I make recommendations. A lot.

These recommendations are often day-to-day, immediate recommendations, made on the ground. But sometimes the scale gets bigger and stretches out longer, and that’s when I need to communicate just how important each recommendation is.

Some time ago, I was engaged with a client who had been maintaining a codebase for several years. They’d asked us to take a look at what they had.

Even when things seem to be going well, this can be helpful. The context that builds up over time is helpful to orient us day-to-day but can also make it difficult for us to see opportunities to do our work even better. Bringing in someone else with experience can help break that and expose us to those opportunities.

After spending some time with their codebase, leveraging Mike Marsiglia’s very helpful application audit framework as a guide, I amassed a list of recommendations. I collected them in my draft in several sections.

But a long list of bullet points isn’t very helpful. Not even several lists broken down into categories like Testing, Deployment, and Security were all that useful. They were missing the kinds of context needed to make informed decisions about what to do with what I’d found.

It’s all about when — and why.

A common strategy for attacking this problem is to define a term to slot recommendations into. Typically, teams use “short,” “medium,” and “long.” They’re tidy, they’re in the common lexicon, and everyone uses them. They’re very friendly. I put them in.

But the longer I stared at them, the more I found they inadequately conveyed how quickly one needed to get to any given recommendation.

I imagined myself at a retrospective. The team would discuss a day-to-day development challenge that needed to be addressed urgently, but our output was that the team characterized it as a “short-term objective.” I knew I’d end up wondering to myself how many more sprints we’d have to suffer without it.

Breaking that feeling down some more, I realized that “short-term” in particular doesn’t convey a sense of action. It conveys a sense of “there are more meetings to be had before we do this.” It is not the language of an empowered product team.

What I thought we needed for these urgent items was a sense that we needed to do them, precisely, now. I tried changing that heading. It immediately felt better. (It also prompted me to move one or two items out of that heading. This also improved things — it made “now,” as a relative importance, much more meaningful.)

To fall in line with the power of “now,” I relabeled the other two sections “soon” and “future” and shuffled recommendations around a little more.

Define “now,” “soon,” and “future.”

With that work done, I could see patterns emerging. Those meanings are the basis of the framework I use to prioritize documented recommendations I now use just about everywhere.

Here are some of those patterns. I’m going to start sharing variations of these lists with recommendations, to help make the framework even more clear.

Now

“Now” affects the day-to-day.

1. Making this change will quickly improve current work.
2. Deferring this change creates a negative impact on current work or operations.
3. People currently working on this project can make this change now.

Soon

“Soon” affects the project on the near horizon.

1. Making this change will improve work planned for the near future.
2. The project team needs to plan for and prioritize this change now.
3. People currently working on this project should start researching what it will take to make this change.
4. Team members currently working on this project will need new skills to make this change.
5. People who aren’t currently working on this project will need to be added to make this change.
6. If left long enough, “soon” work can become “now”.

Future

“Future” holds what is beyond what we can see right now.

1. The project team can talk about this as a goal and intermediate steps they can take along the way.
2. The recommendation itself is likely to evolve as the team continues to build and learn.
3. Who is needed to make this happen may not be clear yet. The project team can find out.
4. The team should consider at what point the recommendation may move to “soon.”

Give your team a better sense of “when.”

This framework gives a much better sense of “when” than vague lengths of time did, while still allowing teams autonomy to decide what works for them in the longer term.

Of course, getting there isn’t simply swapping “term” terminology out and swapping this framework in — it requires thinking about what is urgent and what teams can take time to do.

I hope that, equipped with this knowledge, recommendations can be easier to understand, and more useful.