Yes, No, Maybe
As a leader, you’re going to get questions. Sometimes it’s a question from a customer asking about an upcoming feature, sometimes it’s a question from a team member asking about a new process or policy. Originally intended for product managers, but general enough for any leader, I often use the “yes, no, maybe” framework. It’s a simple way to set expectations. There are three possible responses:
- Yes — We have committed to implement it in the next three months
- No — We have no plans to implement it in the foreseeable future
- Maybe — We might implement it down the road, but either need more information or plan to, but can’t commit to it right now
Regarding feature development, I’ve always enjoyed “under promise, over-deliver” philosophy, and I bring that same approach to leading teams. The worst place you can find yourself as a leader is promising something to stakeholders (again, internal or external) that you cannot deliver, mainly if they rely on you for it. It’s human nature to avoid uncertainty, so it’s only natural for others to take interest in your direction, vision, and what they might expect down the line.
Yes — ”We’re doing that.”
This three-month mark creates a good bright line where it’s safe to say “yes” we’re doing that (or are going to soon). Often, projects are in flight at this point (or planned and committed to), and even if the exact ship date is unknown, the project will likely eventually ship in one form or another. At this point, you should have high confidence that you can say “yes” without risking that you may violate the customer’s expectations down the line. “Yes” is a verbal contract between you and the customer that you will do the thing you say you’ll do.
For those features not on a team’s short-term roadmap, you have two choices:
No — ”We’re not doing that.”
If it’s something that doesn’t make sense strategically, the answer is simple: “No” or “We’re not planning on doing that in the foreseeable future,” more verbosely (ideally with the reason why). While there are many reasons to say “yes”, and “no” is often the more complicated choice to convey to those impacted, if you genuinely have no plans to do the thing “no” allows them to pursue other ways to fix the problem (workflow, policy, tooling, etc.), and shows them that you’re being honest and transparent about your vision and direction, even if the news is unpopular in the short-term.
Maybe — ”We might do that.”
If it’s something you’d like to do but haven’t yet committed to (for example, 4+ months out) or something that might make strategic sense but haven’t yet looked into, you give the best answer you can: “Maybe.” I like to constantly follow up “maybe” with as much context as I can provide, for example, explaining that it’s on our medium or long-term roadmap but that you can’t yet commit to it or explaining that it’s a great idea that you should (genuinely) look into (with a promise to get back to them when you do). Maybe it isn’t a cop-out, but a commitment to follow up with either “yes” or “no” once a decision’s been made.
As with code, I strive to be transparent, unless there’s an overriding business or practical concern not to (after all markets are conversations). Think of “yes, no, maybe” like a “green, red, yellow” stoplight indicating the status of your efforts, and in the inverse, the customer’s need to pursue a workaround (or alternative) to the problem they face.
It sounds simple written out, but if you start from this point when responding to feature requests, your answer should almost always be in the form of “We’re doing that,” “We’re not doing that,” or “We might do that,” and thus should ensure you consistently meet or ideally exceed customer expectations when it comes to upcoming features.
If you enjoyed this post, you might also enjoy:
- 15 rules for communicating at GitHub
- How to make a product great
- Twelve tips for growing communities around your open source project
- Why open source
- The difference between 18F and USDS
- Eight things I wish I knew my first week at GitHub
- Five best practices in open source: external engagement
- Speak like a human: 12 ways tech companies can write less-corporate blog posts
- 19 reasons why technologists don't want to work at your government agency
- The seven habits of highly effective GitHubbers
- Why everything should have a URL
Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →
This page is open source. Please help improve it.
Edit