Have you ever that overwhelming feeling when your team is waiting on you to provide perfect answers when you don’t have any? Have you been in a situation that you’re building a product based on a loose vision not knowing exactly how it’s going to look or behave?
I have been in these situations many times before. In fact as my career progressed and I took on bigger and more complex projects I had to constantly deal with ambiguity defining the product. Although dealing with ambiguity is one of the most fun aspect of product management it can be challenging too. Here are some time-tested approaches I learned to manage ambiguity better:
Get comfortable with being uncomfortable!
I can still feel the panic setting in when after a two minute chat my manager suggested a completely new improvement instead of my carefully thought original plan. His idea made sense but what should I do?!!? In few hours I was going to Montreal to kick this project off and I had very little time to think things through. At first I was paralyzed but then figured nothing would be worst than showing up empty handed, not even piecing together that little bits of information I had. My next few hours was spent on talking with few people and teasing out ideas and I felt a bit more confident! During kick off I told my team about the change of plans and challenged them to come up with a solution to satisfy the ask. By the end of the meeting we had a solid idea of the next steps and how to go about them. It was like magic and I couldn’t have asked for a better kick off!
Recently I came across this blog post from Ken Norton which validates my experience. The fact is as a product manager ambiguity and change is part of your life and you need to embrace it despite feeling jittery and uncomfortable! This is in conflict with another aspect of our job which is to bring clarity and reduce risks but the fact is you don’t always have and know all the answers and you need to be okay with it!
Do just enough to get started
Even though you don’t have all the answers up front it doesn’t mean you’re off the hook ! Your team still needs your help to understand the problem and the results we want to achieve. This means you need to work ahead of your engineering team and understand the business problem and identify the goals and success metrics based on it.
Much has been said about Amazon’s approach or completing some sort of canvas as the first step. I tried multiple approaches and what worked so far is to write a one pager (which is not a slide deck!) and have it somewhere central for the team and stakeholders to view and comment on. Google docs, Confluence or any other wiki-style collaboration software works just fine but don’t email around a Word document as things start to get out of hand! Usually comments and discussions following provide guidance on next step on whether to dig deeper or the vision is good enough for the team to get started!
Keep connecting the dots until full picture emerges
Your initial one-pager resulted in a set of questions to investigate further! Now in addition to finding answers to these questions you also need detailed discussion with key people to make your vision more concrete. When I was involved in building a new web application system from ground up I worked closely with web architect and engineer lead to flesh out use cases for user permission and access levels while on UI front I worked with designers to solidify how the web application going to look like and collaborated on user research and testing. I also kept the business side in the loop by asking their feedback on working prototypes. As I connected these different aspects of this product together, I felt more confident about the vision and solution being built and I could answer many more questions in greater details!