I’ve worked in a lot of companies where the direction or vision that we were shooting for was in question or even in transition. And, when that happens, the natural result is a lot of chaos and uncertainty. I recall in one very contentious meeting regarding a new direction one company was taking, a very smart man in the room spoke up and said these words:
“We have to embrace ambiguity and drive it out where we can.”
This has, in many ways, become a bit of a mantra for me, as the whole concept of Agile development has built in to it this very concept. You define what you know is important, when you know that it’s important, and you move forward. This really is simply another way of rephrasing the common aphorism of “Fail Fast, Fail Early, and Fail Often.”
But what does all of this really mean to a Product Manager who’s charged with leading a team? It means that you need to understand (with all apologies to Donald Rumsfeld):
- What are your “known knowns” — What you know right now, what you can define now, and what you can execute on right now;
- What are your “known unknowns” — What you know that you don’t know, what needs more research, what needs more elaboration or justification; and
- How to handle any “unknown unknowns” — There are things that you don’t yet know, questions that people haven’t asked yet, responses and reactions that you haven’t yet seen and will someday need to take into account.
Managing your “known knowns” is a pretty simple thing – this is what you do every day. This is the backlog, the sprint commitments, the work that’s planned and the work that’s already underway. These are the things that everyone can see, hear, and feel — whether or not they necessarily “agree” with them.
It’s a little trickier to manage your “known unknowns” — this is the constant stream of challenges, questions, and nit-picks that come from everyone in the company and outside the company. These are the design challenges that you have in creating something that’s both usable and complex. These are the questions of whether or not the product that you’re building is really solving the problems that you’re setting out to, and whether or not your customers are going to be willing to pay for it in the end.
But these “known unknowns” are something that you can get a handle on. You can collect the feedback, enumerate the questions that you have on hand, and you can make specific plans to answer those questions or resolve those unknowns. These are almost always actionable, though whether or not it’s urgent to resolve them is for you to determine according to the needs of your product and your team.
Finally, there are the “unknown unknowns” — this is where your ambiguity lies. This is the discomfort that comes from not knowing everything, not having every answer, not being able to plan for every single contingency. But the reality is, as a famous German field marshal once said, “No plan survives contact with the enemy.” And the same goes for product plans.
“No plan survives
contact with the enemy.”
This is where your number one tool and skill as a Product Manager comes into play — your ability to lead through influence. You have to work closely with your sponsors, your stakeholders, and your teams, to ensure that you’re constantly working with them to manage their expectations. You have to be honest with them that there are things that nobody knows, that will change the plan, and that may derail certain aspects of the project. And you have to reassure them that, when those things come up, you will take the lead in ensuring that those questions are answered, that those concerns are addressed, and that the plan is revisited and revised to handle what you don’t yet know.
The alternative is to fall into a form of “analysis paralysis”, where the teams go around and around, doing nothing productive, but looking for every possible question to ensure that it can be answered, poking at every possible hole in the plan to ensure that it’s certain to be a success, plotting and planning and working solely to ensure that the plan is solid — without ever writing a single line of working code, or solving a single customer problem.
The simple fact is, nobody can be 100% sure that what they’re planning for will come to fruition. Nobody can predict with 100% certainty what the market will want or need in 6, 9, or 12 months. Nobody can be 100% positive that there will be no technical obstacles that arise, which challenge all of the work done before. But, you can’t let any of that deter you from doing what you can demonstrate to be necessary at the present time; what you can show to be of value to your customers and your market, at the time you’re starting work on it; and you can’t let it keep you from innovating, evolving, and delivering value.
Embrace that ambiguity, and drive it out wherever possible.