Implementing Non-Goals
In an earlier essay, we discussed the importance of subtractive non-goals for product managers and product leaders to drive alignment and focus for their teams. There, we analyzed the problem with additive goals, and we provided a real-world example of how subtractive non-goals can unblock conversations and crystallize group identities.
In this second half of our guide on non-goals, we’ll share ways to implement product non-goals across a variety of high-leverage areas, including:
Organizational strategy
Product philosophies
Product execution
Career development
We’ll also discuss what cadence to use to revisit non-goals so that we don’t wind up locking ourselves into outdated decisions for perpetuity.
Let’s now dive into non-goal implementation.
Using product non-goals for organizational strategy
Non-goals are particularly valuable when setting org-wide strategy, whether that’s annual planning exercises, quarterly product strategies, or team roadmaps for the next few quarters.
Org-wide annual planning
Annual planning enables product orgs to align their resources, strategies, and actions towards achieving their objectives. However, while annual planning typically focuses on the goals of the company and the goals of individual products, most annual planning fails to identify non-goals.
Non-goals are areas that the company intentionally chooses not to pursue, even though they may seem attractive or lucrative in the short term, because these areas will hinder overall progress towards the desired outcome. In other words, non-goals help us step away from “first order positive, second order negative” decisions; by avoiding these pitfalls, we sustainably position our overall product portfolio for long-term success.
For instance, if an organization is focused on targeting enterprise B2B customers, a critical non-goal would be to avoid pursuing downmarket SMB segments for its product. While it may be tempting to expand the customer base by targeting smaller businesses, it can dilute the product portfolio’s value proposition, cause a misalignment of resources, and create operational challenges.
Similarly, if an organization's primary objective is revenue growth, then profitability should be set as a non-goal, as a short-sighted focus on profits may come at the expense of innovation and customer acquisition in the medium-to-long run.
After all, the entire point of revenue growth is to prove the earnings potential of the product portfolio to investors; splitting our attention across revenue and profits prematurely can cause us to permanently lose access to future market share. If competitors gain an advantage in the market through aggressive customer acquisition, we might lose out on market leadership.
Identifying non-goals is an essential part of the annual planning process as it helps organizations make deliberate choices about where to invest their resources, focus their efforts, and allocate their time. By setting non-goals as product leaders, we help our teams avoid distractions, prevent scope creep, and stay true to their core values and purpose.
However, identifying non-goals is not enough; we as product leaders must also articulate our rationale for these non-goals, communicate them effectively, and revisit them periodically to ensure they remain relevant and aligned with overall strategy and goals.
Product-specific strategies
Product-level strategy is crucial for achieving the vision of an organization. At Product Teacher, we provide workshops that teach participants how to develop a product-specific strategy that aligns with the company's priorities and vision. These workshops focus on six key components that are essential in developing a compelling product-level strategy: diagnosis, guiding policy, actions, non-actions, goals, and non-goals.
In our workshops, we pay special attention to non-actions and non-goals, because these two components are what truly drive executional alignment across teams.
Non-actions are the activities that the product team will avoid doing, even if they seem like good ideas. Non-actions are just as critical as actions because they prevent the team from getting distracted and keep them focused on the primary objective. A compelling non-action might be “we will not chase the feature set of competitors, because we are focused on delivering value for our specific customers.”
And, non-goals are counterintuitively more important than the goals that we’ve set for ourselves and our products. Keep in mind that the goal of any product is to create massive value to customers while simultaneously enabling our businesses to capture that value. But, to convince customers to switch to our products, we must achieve sufficient critical mass.
Without non-goals, we won’t be able to double down on the key differentiators and the unique value proposition of our products. If we chase 15 different goals all at once, our products won’t have clear identities, and customers will struggle to adopt our products.
For example, consider these two product offerings:
A generic rules engine that lets you create any rule set you want, for any business application that you’d like
A triage decisioning engine for a hospital that allocates scarce resources to maximize patient outcomes
In the real world, most hospitals will choose the more focused “triage decisioning engine” even though they could have used a generic rules engine to do the exact same thing!
This phenomenon happens because “generic rules engine” is too abstract or too distant of a concept for customers to understand how they might benefit from leveraging this product in their lives and in their workflows.
Keep in mind that the point of a product strategy is choosing one option out of many equally compelling options. We should not fear “leaving value on the table” - by doing so, we paradoxically create even more value by sparking critical mass and driving multiplicative, synergistic product growth over time.
Team roadmaps
Team roadmaps enable us to plan out and execute against product initiatives over the next few quarters. When we develop our roadmaps, we should weave in not just the goals that we seek, but also the non-goals that we will actively avoid pursuing.
As an example, we might set a roadmap non-goal of “we will not build every feature in-house.” While many design and engineering teams prefer to build capabilities rather than rely on external integrations or partnerships, building first-party functionality is not always the highest ROI play. By establishing this non-goal, we as product leaders can help our team focus on its core competencies and avoid burning valuable time and resources on low-value functionality that we could have “outsourced” instead.
With this non-goal in place, we encourage our team to leverage product integrations with third-party partners. This approach can help the team utilize the strengths of other organizations and focus on delivering value to its customers through its core offerings.
Salesforce is an example of a product organization that has successfully leveraged this strategy to dominate the market. The strength of the Salesforce platform doesn’t lie in its first-party capabilities; instead, it lies in its deep ecosystem of third-party integrations with partners.
On the flip side, a team could have a non-goal of “we will not open our platform to others to reap short-term revenue, because we believe in having full control over the consumer experience.”
This particular strategy is one that Apple has leveraged successfully for many years, leading to deep customer love for its products. By keeping everything in-house, the team can maintain full control over its offerings and unlock delightful synergies that wouldn’t otherwise be achievable.
For example, consider the “magical pairing” that happens between Apple AirPods and iPhones, and compare it against standard Bluetooth pairing between third-party headsets and Android phones. The Apple experience has significantly less friction because the product team fully controls all of the software and hardware products in its ecosystem, whereas the open ecosystem of Android requires significantly more user effort.
To be clear, there are no universal non-goals that will apply to every single kind of team roadmap. Successful product teams understand that the goals and non-goals they set should be derived from customer value creation and business value capture, and both of these levers are highly specific to each product org and each product’s unique value proposition.
Using non-goals for product philosophies
A product philosophy is a set of principles and values that guide product managers across the organization in making executional trade-offs and decisions that align with the company's vision and objectives. Product philosophies do not simply state what to say “yes” to; they must also provide guidance on the operating principles that we do not endorse. A product philosophy that simply says yes to everything provides little guidance in ambiguous and unclear situations.
The strength of a product philosophy lies in how clearly it guides trade-offs. For example, the statement "it's more important to make one customer extremely happy right now than to make many customers mildly happy later" establishes a clear goal of depth of solution and speed of delivery, with a non-goal of scalability or breadth right out of the gate.
This product philosophy can guide product managers in making decisions that prioritize deep customer delight and swift delivery, which then lets them leverage a “domino effect” of raving customer testimonials and word-of-mouth to virally capture more and more customers over time.
A different anti-tenet that a product philosophy might establish is to “avoid shipping a product with absolutely zero bugs no matter how long it takes." This statement makes it clear to designers, engineers, and customer-facing counterparts that the product will not be perfect and that there will be a trade-off between quality and speed of delivery.
A well-defined product philosophy can help product teams make consistent and effective decisions, stay focused on their goals, and avoid distractions and scope creep. It can also help the team communicate its priorities and decision-making rationale to stakeholders, partners, and customers.
However, we as product leaders must communicate the product philosophy clearly, revisit it periodically, and adapt it as needed to ensure it remains relevant and aligned with the company's overall strategy and objectives.
Using non-goals for product execution
In coaching product managers from both early-stage startups and publicly-traded companies, I’ve found that some PMs may wind up focusing on the wrong objectives or the wrong processes when driving product execution.
Establishing non-goals can help us clarify whether our actions align with our dual mission of creating customer value and capturing business value, while also helping us identify whether we’ve accidentally overindexed on an executional process without sufficient critical thinking.
We provide suggestions below for:
A/B testing
Product development
Product processes
While you don’t have to use all of the below, we believe that these non-goals can help strengthen product execution for your teams.
A/B testing
One key non-goal in A/B testing I recommend embracing is "avoid throwing spaghetti at the wall." That is, we should not randomly choose different elements of a product or feature to change without a clear hypothesis about which customer pains or frictions we’re addressing through our A/B tests.
While it's possible to move a metric and find optimizations through brute force and sheer luck, it's not an effective way to learn from customers, and it tends to reduce customer trust due to a lack of visual consistency over time. Plus, shipping a mish-mash of local optimizations tends to wind up creating a bloated, incoherent product that fails to unlock new growth trajectories.
Here’s an example of why throwing spaghetti at the wall doesn’t work, and why targeted hypotheses are a much more effective approach.
I previously coached a product manager who was charged with driving more growth for their product, which was a workflow that let consumers identify how much their home is worth (similar to the Zillow Zestimate or the Redfin Estimate).
Over multiple quarters, they had changed the order of input fields, added fields, removed fields, added screens, removed screens, moved button positions, tested different text, changed fonts, and many other local optimizations. Yet, product adoption stubbornly refused to improve by more than a fraction of a percentage point.
I asked this product manager to attack the problem from a different angle. After all, their experiments assumed that consumers had problems or frictions with how to request a home estimate, but not problems with why they should get a home estimate.
In our coaching, I gently pushed this product manager on whether they had evidence that consumers already understood the value of having a home estimate, and they admitted that they hadn’t yet done that research. For their next step, I tasked them with running surveys and customer interviews to understand consumer knowledge around home estimates.
Through user research, this product manager discovered that many of their consumers were immigrants and first-time home owners who did not yet understand what a home estimate was for, why a home estimate would be valuable for them, and why they should create an account to receive a home estimate.
By leveraging this discovery, this product manager moved away from minor workflow optimizations and focused more on educating consumers on the value of home estimates, e.g. through helptext, blog content, customer testimonials, etc. These new changes led to double-digit growth in product adoption.
By switching the underlying optimization hypothesis to “help consumers understand the value of home estimates” rather than “make it easier for consumers to get home estimates,” this PM unlocked a new growth trajectory that they previously couldn’t access.
Users adopt products through a multi-stage funnel, and therefore we must take the time to consider where the consumer is in the funnel and what kinds of experiments we should focus on. We should avoid shipping “easy changes” that designers and engineers can knock out quickly, because these easy changes may wind up not unlocking consumer value.
Another non-goal in A/B testing I recommend establishing is “always finding winning experiments.” Some sets of experiments should lose, because experiments are not sure bets.
To be clear, the point of an experiment is to learn what kinds of approaches will accelerate a specific pre-chosen target metric, not to simply see improvements on any metric.
When product managers are implicitly or explicitly encouraged to have their A/B tests always find winners, they will be incentivized to cherry-pick “winning” experiments, even if those experiments increase non-targeted metrics.
As an example, say that a product manager is focused on driving improvements in the number of dollars that users pledge to crowdfunding projects e.g. Kickstarter. They may have a set of three experiments that they run, with the following results:
Expt 1: no increase in dollars pledged per user, statistically significant increase in projects visited per user per session
Expt 2: no increase in dollars pledged per user, statistically significant increase in time on page per user
Expt 3: no increase in dollars pledged per user, statistically significant increase in weekly logins per user
Should they roll out these three experiments to all users?
If a PM has been incorrectly incentivized to always choose winners, then they’ll ship all three. But, none of these actually drove increased dollars pledged per user - and, we don’t know whether these three experiments will wind up causing negative synergy, because we never tested for these impacts.
How might this be possible? Imagine the following:
The first experiment added a “recommended other projects” section to every project
The second experiment pushed the “pledge” button to the bottom of the page
The third experiment forced all users to have to log in before pledging, rather than being able to pledge anonymously
These three experiments in isolation may not cause enough friction to make users pledge less. But, when implemented together, these three treatments may create so much headache and noise that users wind up not pledging at all, causing a net loss against the originally-targeted metric of dollars pledged per user.
Therefore, avoid cherry-picking winners, as this approach leads to optimizations on metrics that don’t matter; and, many times, these optimizations may actually cause negative impacts to desired target metrics.
Product development
One key non-goal in product development is "becoming a feature factory." This non-goal refers to the approach of continually adding new features to a product without a clear understanding of how they contribute to solving customer pain at scale.
While we might believe that adding new features helps us keep up with the competition or helps us keep customers happy, this approach can lead to bloated and confusing products that don't provide value to customers. Product development teams must stay focused on solving customer pain at scale and ensure that each feature added to the product contributes to this goal.
Teams tend to devolve into becoming feature factories when executive leaders ask teams to “catch up with the competition.” We need to remember that our specific customers have real, unsolved pains that we can uniquely address, and that chasing competitors means that we’re not focusing enough on solving the frictions and challenges that our customers face.
But on the other hand, another non-goal we should keep in mind for product development is "taking customer feature requests at face value." This non-goal refers to the approach of blindly implementing customer requests as-is without a clear understanding of how they align with the product's overall objectives and vision.
While it's essential to listen to customer feedback and requests, it's equally crucial to assess whether these requests align with the product's overall strategy and contribute to solving customer pain at scale. As product managers, it’s our responsibility to discover unique angles for addressing customer pain in a way that unlocks value across the entire customer base.
As an example, say that one of your customers requests that you “build an orange square button in the top right hand corner that automatically fills in <Test user> for an input form.”
This feature request is too customized for just this single customer. It’s highly unlikely that any other customer would benefit from such an implementation, which limits the ROI that you create for customers and caps the amount of value that you can capture for your business.
Perhaps the challenge here is that the input form requires regular testing in production; you could come up with different ways to address the issue that scales across all customers.
Or perhaps the challenge here is that some of the end consumers of this form aren’t comfortable with putting in their full name yet, which is why your customer wants to let them skip this input; you could come up with many different approaches for tackling this issue too.
By keeping anti-tenets and non-goals in mind, we can ensure that we’re iteratively discovering and addressing unsolved customer pain.
Product processes
As product managers and product leaders, we’re not just in charge of the products we ship; we’re also in charge of the process through which our products are shipped.
A non-goal we might establish is “enshrining the process.” I’ve worked with a handful of large traditional institutions in manufacturing, finance, etc. where the team zealously followed SAFe approaches without demonstrating critical thinking, or where the team blindly filled out user story templates without ever speaking to customers.
To be clear: the process is never the point.
Processes are tools that enable us to iterate towards creating customer value and capturing value for the business. We should feel empowered to create new processes, discard old processes, and bend existing processes in pursuit of generating better value at faster velocity.
If a product planning process or a product release process becomes stagnant, with endless documentation and too many checklists, then the team has enshrined the process.
Explicitly stating that the goal of any process is not to enshrine it, but to use it as a starting point for endless evolution and change, can help product managers ensure that their processes remain flexible and responsive to changing customer needs and business objectives.
Why does this matter? I’ve seen too many processes collapse under their own weight.
For example, I’ve seen crisis management processes create too much overhead and paperwork for PMs to actually resolve the crisis and drive prioritization tradeoffs for resolving the issue. Instead, they spend too much time gathering info and sending updates to “adhere to the procedure.”
I’ve also seen prioritization processes take up months and months of active work, to the point where the product team loses significant bandwidth to actually ship functionality and learn from customers to make real progress.
And I’ve seen analytics reporting and business review readouts consume dozens of person-hours per week without generating net-new insight or high-value next steps.
When teams hew too closely to established processes, they lose the ability to think for themselves and to drive real innovation and improvement for customers and for the business. And, they become at-risk for losing key talent to competitors who empower their teams to make decentralized context-specific decisions.
That’s why it’s crucial that we as product leaders empower our teams and our direct reports to establish non-goals around enshrining product processes.
Using non-goals for PM career development
As a product person, you could theoretically upskill in infinitely many skill areas, such as technical mastery, UX design, negotiations, communications, pitching, managing upwards, and more.
With so many options, it can be overwhelming to decide where to invest your time for future growth. Trying to learn every skill at once isn’t feasible, as we have limited time as PMs.
That's where setting non-goals comes in.
By setting non-goals, you can prioritize what to focus on next in your career development. This helps you become more intentional about your career trajectory and make the most of your time and resources.
While product management is a diverse field that benefits from having exposure to a broad range of skills, not all skills are equally important at all times.
For example, if you're working on product integrations or on migrating your product to a new architecture, you may need to focus more on technical comfort.
On the other hand, if you're working on launching a consumer product to the market, you may need to focus more on consumer psychology and GTM (go-to-market) skills.
Setting non-goals can help you to identify which skills you need to develop right now and which skills you can put on hold. This can help you to be more efficient and effective in your career development. It can also help you to avoid burnout, as trying to do everything at once can be overwhelming and stressful.
Setting non-goals is also important for managing the careers of your direct reports. As a product leader, you’re responsible for the sustainable development of product team members.
By setting non-goals for them, you can help them to prioritize their career development and focus on the skills that will be most valuable for their current role, while also helping them avoid burnout, anxiety, and despair.
Putting an expiration date on non-goals
Establishing non-goals is one way to guide our decisions, but we must put expiration dates on our non-goals to ensure they remain relevant and effective.
The world is always changing, and what may have been a non-goal in the past may now be essential for the success of the product or the organization. Therefore, we should revisit non-goals at least every year, if not more frequently in contexts where the situation is rapidly evolving.
By expiring our non-goals and setting new ones, we as product leaders can stay current with evolving market trends, changing customer needs, and emerging technologies, and ensure that our decisions remain aligned with the overall objectives and vision of the organization.
However, we should also avoid changing non-goals too frequently e.g. every month or every week. Constantly changing non-goals can create confusion among team members, reduce the weight and gravitas of any given non-goal, and undermine the overall strategy of the organization.
Therefore, we should set a balanced cadence for revisiting non-goals, so that we maintain a stable and coherent strategy. By specifying a time frame for each non-goal, our teams can avoid becoming too attached to outdated information and stay focused on creating value for customers and the organization.
Closing thoughts
Non-goals are an essential yet overlooked component of product leadership. They provide focus, free up resources, foster innovation, and align teams across multiple scopes, ranging from organizational strategy to day-to-day execution.
As product leaders, we must carefully consider which objectives we will not pursue, and we must communicate this clearly to our teams. By doing so, we can ensure that our organizations remain competitive, innovative, and successful.
If you would like help with non-goals for your team, reach out to book a workshop or a coaching session with us.
Thank you to Pauli Bielewicz, Mary Paschentis, Goutham Budati, Markus Seebauer, Juliet Chuang, and Kendra Ritterhern for making this guide possible.
