Some solution vs. no solution

It’s natural to argue over what is the best, most perfect solution. Who would want to build anything less? This is especially true when we have our design or development hats on with a specific idea we hope to see in the final product. But it turns out that in the shaping phase, what’s “best” isn’t always the right question to ask.

I’m shaping a feature right now for Basecamp 4 that adds a time dimension to projects. My Basecamp home screen today is a messy mixture of some current projects and many outdated ones. There’s never a right time to do the housekeeping required to archive old projects. Part of the idea of this feature is to set end dates on projects, so we can automatically filter out the things that are no longer relevant and raise the signal on the home screen.

There’s a tricky part to this. We want to hide past projects so they don’t clutter the screen. But the reality is projects almost always run beyond the exact day they are due. So when is the right time to hide a project? Will somebody try to navigate to a project a day after it’s supposedly over and not be able to find it? When is a project “past”? How do we both show past projects and not show them? How do people extend projects, when and where do we ask them to do it, and what goes wrong if they don’t?

I don’t know the best answer to these questions. But I have a few different good-enough answers.

This is where shaping work is different from normal work. Inside a fixed timebox, designers and programmers have to decide which specific direction to build. But before we’re inside the timebox, before we bet time and people on the project, the question is different. I don’t need to know what the best solution is. I need to know that a solution exists.

There’s a big difference between no solution, some solutions, and the best solution. If there’s no solution to this particular question, and the question matters, the project will die on it. If there are some solutions that all basically work, then we can move forward. What’s important is we get to that bigger outcome we want when all the parts of the project integrate together.

In this particular case, I have at least three different solutions sketched out. Some involve explicitly asking people to move the end date. Others reveal past projects for a longer grace period so they don’t disappear. I don’t know which one is right. I don’t know which one is best. But I’m confident that the project won’t die on this question. Any of these will work. Some solution exists within the amount of time we’re willing to give the team.

This is another example of capping downside instead of seeking the highest upside. The team working in the timebox might find a solution that’s better than any of the ones I’m shaping now. But if they don’t, at least I know there’s an okay-enough solution to hold the project together.