One of the most important part of our jobs as Product Managers is setting goals — goals for ourselves, goals for our teams, and goals for our products. Goals are important — they set the North Star for us to know where we’re going, why we’re going there, and how we know whether or not we’ll be successful when we get there. Properly-formulated goals are an essential component of being a successful Product Manager. But how many of us think about non-goals? Those things that we are intentionally choosing not to do in a given project, the things we don’t expect to change due to our efforts, or the subject matter areas that (for one reason or another) we don’t want to address at this time, with this team, or with this project. Non-Goals are just as important as actual goals, and here are a few reasons to keep them in mind in your next kickoff session…
Non-Goals Help Increase Transparency
The most important thing that identifying non-goals can do is to control scope. In most projects there are unspoken limits to the intended scope of work that we’re planning on, that we spec out, or that we put on our backlogs. But the problem with these is that they’re unspoken, which means that they’re opaque to others outside the Product Management and Development teams. As an “agile” organization (note the lower-case “a”), we want to increase transparency whenever possible, and Non-Goals are a way to do that. When we specifically identify the things that we’re not including or considering, others can clearly understand the extent of the scope that we are working with. This cuts down on confusion, increases overall buy-in, and invites conversation early in the project if there are any questions, concerns, or disputes as to what we should or should not be taking into account. If we value transparency as much as we should, then Non-Goals need to be part of our toolkit as Product Managers.
Non-Goals Manage Expectations
Related to transparency, clearly stating our Non-Goals from the beginning of a project helps us to manage expectations from the very first discussion. I’m sure we’ve all been involved in a project where we get 90% of the way there, some stakeholder sits in on a demo, and derails the entire meeting asking about some aspect of the tool or product or feature that was never in scope from the beginning. We’re basically asking for this kind of response when we don’t clearly establish, communicate, and document what the non-goals of our project are. The earlier we can set forth both the goals and Non-Goals of the project, the less likely we are to be blindsided along the way — and if, for some reason, we are then we can point to the documentation as a source of truth that existed from the beginning — we shift the burden of raising issues to the stakeholders who we presume to have reviewed such information, rather than it falling on us near the end to explain why we’re not mind-readers.
Non-Goals Provide Clarity
Above and beyond improving transparency and managing your stakeholder expectations, setting forth your Non-Goals from the very beginning of a project or feature creates a real sense of clarity for the work to be done. Non-Goals can be used to focus discussions, to prevent tangential discussions, to prevent unnecessary refactoring or over-engineering. Setting the rules before a game is essential to enjoying that game; similarly, setting forth exactly what the goals and Non-Goals are for your project is essential to positioning you, your team, and your product for success.
