Product Management Tactics — Unknowns Don’t Work on a Schedule
As teams tackle the various scopes of work, it’s often that tasks are tracked so that we know which tasks have been completed and which tasks have not. But aside from the tasks that are tracked, we should also be tracking the “unknowns.”
As product people, we’re very quick to tell you the difference between our roles as Product Managers and that of Project Managers. But, let’s face it — even though it may not be the primary purpose and role of a product person, we are still often managing projects. And as anybody who’s ever managed a product before knows, it’s always important to be tracking the tasks so everybody knows what has been completed and what work still lies ahead.
But, is that the only thing that we should be tracking within a project? Ryan Singer of Basecamp doesn’t think so.
At Basecamp, they make it a priority to not just track tasks within a project, but also the unknowns of a project. Why is this the case? As Ryan puts it, “unknowns don’t work on a schedule. An unknown can block you for years if you don’t know what the answer is.”
The last part of his statement sort of knocked us back in our tracks a bit. An unknown can block you for years if you don’t have the answer. If this is true (and we’d venture to say that it is), then why aren’t unknowns given so much weight when planning a project? Most project management tools that we’ve used — complete with all sorts of bells and whistles — don’t necessarily have an “unknown tracker.”
Of course, we as product people, aren’t exactly ignoring these unknowns. In fact, it’s likely that we know innately that in order to complete any sort of project, we will have to go and find the answers if there are any big, looming unknowns. And so, we do. But, Ryan suggests being more deliberate about the way that we list and track our unknowns — and it certainly seems like a good idea.
There are a couple of ways that this can be done, practically:
- One way is to keep a very visible list of the major unknowns of the project so, at a minimum, everybody on the project team is aligned on understanding what these unknowns are.
- Perhaps the timeline itself could start with these unknowns. Within each unknown, tasks emerge in order to find the answer that the team needs in order to complete the project.
Regardless of how you incorporate unknowns into the project plan, it’s probably a good idea to take Ryan’s advice and not simply treat the project as a collection of tasks. Instead, put as much weight and emphasis on answering these major unknowns.