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. I often use the “yes, no, maybe” framework, which @gnawhleinad and @nayafia introduced me to. It was originally meant for product managers, but it works for any leader. It’s a simple way to set expectations. Every request gets one of three responses:
- Yes. We’ve committed to implementing 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 need more information, or plan to and can’t commit to it yet.
Regarding feature development, I’ve always liked the “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, especially 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 means “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 means “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). Saying “yes” is tempting for plenty of reasons, and “no” is often harder to convey to the people it affects. But if you genuinely have no plans to do the thing, “no” frees them to solve the problem other ways (workflow, policy, tooling, etc.) and shows you’re being honest about your vision and direction, even if the news is unpopular in the short term.
Maybe means “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 you haven’t yet looked into, you give the best answer you can: “Maybe.” I like to always 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” isn’t a cop-out. It’s a commitment to follow up with either “yes” or “no” once you’ve made a decision.
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. Start from this point when responding to feature requests, and nearly every answer becomes “We’re doing that,” “We’re not doing that,” or “We might do that.” That’s how you consistently meet, and ideally exceed, customer expectations about upcoming features.