“Strong desire to have an answer…Important to realize that “I don’t know” is often better than a long-winded response…”
This quote from my performance review summed up what my manager advised: don’t put all the burden on yourself – ask for help.
Being a leader doesn’t mean you have all the answers, but rather a clear vision and engagement skills to shepherd your team in solving the challenges at hand. The product manager must be assertive and take prudent risks, striking a balance between conjecture and waiting for perfect information.
Not everyone can, or should, be in the room when the product manager meets with customers, sales, engineering, or executives. Full visibility will never occur as competitors maneuver, use cases shift, and development surprises appear. There are times when she has the benefit of thoughtful group discussion and others when she must be decisive in the moment. My manager was saying that “let me get back to you” can be an acceptable response when my type-A personality screams “let me figure this out” in the moment.
A critical third approach is “let’s figure this out together.” I’ve learned to employ this approach by checking my assumptions and soliciting details and perspectives from everyone around me. Knowing when to employ each approach enables the product manager to move quickly and instills confidence in her leadership.
Figure this out now!
Sometimes you’ve got to make an executive decision in the moment. There may be only one correct answer even when not all the details are available to support it.
I’ve been fortunate to observe great leaders with the confidence and conviction to look out for the customer even when it means a near-term, unexpected disruption. Our largest customer put its faith in us to manage their Windows servers using our latest software release. Despite careful research into the customer’s use cases, both sides missed a requirement that significantly reduced the value of what we promised.
Once the product gap was recognized, our executive team immediately pledged unconditional support with a timely, targeted release to satisfy the customer’s need. This was despite lacking a full understanding of what it would take to deliver the new features. Though we had time to partially scope the work, uncertainty remained. It was abundantly clear that we had an obligation in rising to the faith that was invested in us.
I’ll get back to you
Complex use cases and multiple priorities can mean a more lengthy process in understanding a problem and the appropriate response. When you can do more harm than good with an immediate response, admit you don’t have all the answers and commit to a timely follow-up. This approach boosts confidence compared with off-the-cuff pronouncements that turn out to be wildly inaccurate.
Following organizational changes, a sales team unwittingly set customer expectations for software delivery that were unachievable. Promising every requirement in the originally stated timeline simply wasn’t possible and would have misled the customer. My general manager delivered an unequivocal message that the customer would be taken care of and tasked my team with figuring out the best approach that would balance the needs across our customer base.
We pulled together several engineering teams, considering existing commitments plus the late-breaking customer challenge. With finite time and resources, we went back to the customer to more accurately understand their deployment priorities, which were not monolithic. The product team spread use cases across multiple releases that coincided with the customer’s timeline and that of our broader business.
Let’s do this together
Joint investigation allows the product manager to solicit feedback in the moment when challenges are first uncovered and domain experts are in the room. Seeking details on the ask and hearing others’ ideas improves clarity and makes her constituents part of the solution – whether they are within or outside her organization.
A partner released a new boot feature that complemented our configuration abilities and would hand us another way to deliver unique value to joint customers. Unfortunately, engineering was already committed on the next release. Missing that release would prevent us from realizing the full value of the partner’s product launch. Initial feedback was grim: we either wait for the next release cycle to build a whole new feature or rely on third-party software to make our two products work together. I certainly couldn’t solve this on my own.
Together with engineering, we outlined the steps a user would follow to manually achieve the use case with and without our product’s unique capabilities. Actions would be required in both the partner’s UI and ours. As the use case became more clear, we realized that a short string could be inserted in our UI that would activate the user’s desired boot image. Adding this string turned out to be a modest effort that fit into the upcoming release. We demonstrated our new capability at the partner’s user conference and marketed the value it brought to customers who were adopting the latest capabilities.
Some people may find it easier to ask for help than others. If you’re an engineer turned product manager like me, there may be a lingering sense of pride in figuring out something for yourself or wanting to always appear informed. Knowing when to say “I don’t know” or “I’ll get back to you” or “let’s do this together” is both personally liberating and most fair to those you’re working with.