I’ve always been interested in figuring out what signifies greatness in PM, what makes a great PM?
A source of signal for me has been the ability to deal with ambiguity. Great PMs have this innate ability to take ambiguous thoughts/ideas/strategies as input and come up with a coherent executable plan which then they execute ruthlessly. A great PM has the superpower of bringing clarity to everything.
So what exactly is dealing with ambiguity? Its easier to describe how it looks like in the negative, i.e what are the symptoms that indicate a failure in dealing with ambiguity
Massive pushback and tonnes of clarifying questions
While a healthy skepticism of ideas and clarifying questions are expected there is an outer limit. PMs who cannot deal with ambiguity will constantly push back against ideas. They ask so many clarifying questions that the idea submitter just gives up. Another pattern is to always highlight why the idea won’t work and is not consistent with some strategy. Or to bemoan that there is no strategy at all. This is always interesting to me as a product person – the job of the PM is to create the strategy. If you don’t see a strategy, create one – that’s your job!
Analysis paralysis
Nothing gets done, but it feels like a lot is going on. There are lots of meetings, lots of off-sites, lots of sticky notes, lots of slide decks and lots of perfectly modeled excel financial forecasts – but nothing ships. The user never gets to see their actual problem solved.
Ok great, you know how bad looks like, now what? How to get better at dealing with ambiguity? A few practical techniques
Have a deep focus on understanding the user problem that you are trying to solve
This is a skill that you have to constantly work on. You need to do the grunt work of talking to users, stakeholders and forming an opinion. Great PMs understand this intuitively and build this “user problem identification” intuition quickly. Over time in their particular area of expertise, they gain a lot of contexts and get to do this pretty quickly. You have to develop a sixth sense of tying ideas to problem statements extremely quickly.
Figure out the minimum viable plan aka plan for the plan
You have to know project management 101. Great PMs know how to break down large tasks into smaller chunks and get the team moving. It’s an iterative plan, you don’t need a full-fledged 50-page Gant chart. Figure out what is the minimum viable plan to get going. It could be as simple as
- Document the user problem to solve
- Brainstorm with a few key stakeholders on some initial ideas of how to solve the user problem
- Start a task list of items
- Timebox items
- Start executing the task list
This is a bare-bones v1 plan – start making progress as soon as you can and keep the momentum going.
Think simple first
Once you have a good enough understanding of the user problem, what next? Great PMs know how to start with the right level of detail. I call it the skill of “can you draw the flowchart boxes at the right level”. Always start with the simplest happy path flow for one user. By focussing on the happy path – you are designing for the majority case. Once this happy path is designed you can start ticking off areas where there will be exceptions. These are your first cut of unhappy paths. By keeping it focused on a subsection you can avoid analysis paralysis.
Plan for misalignment, in fact, expect it to happen.
Alignment is a sacred cow, every organizational blog post talks about how alignment is the holy grail. If everybody is aligned – success is guaranteed. While there is some truth to that, over alignment is a real problem. There is a tendency to fully align everybody before doing anything. This is equivalent to a large global lock, which unnecessarily slows things down. Great PMs break down work in such a way that there is inherent parallelism. Great PMs prefer speed over alignment. Great PMs expect some amount of misalignment to happen and deal with it in runtime. Some practical tips
- Structure stakeholder groups in such a way that there is a separation of concerns. While it is good that every internal group is aware of every change, is it really necessary?
- Have structured forums to surface misalignments in run time. Rather than focus on how to avoid misalignments all together, focus on having a regular forum where misalignments can be dealt with in runtime. This optimizes for speed and you also get a true sense of how many incidents of misalignment occur. There is a tendency to assume a high incidence of misalignment before a project starts. By solving these at runtime you are reacting to actual misalignments, not perceived misalignments.
What do you think? What are some good techniques to deal with ambiguity? Comment away!