Defining Measurable Product Goals in GIST Planning
This skill teaches you to write strategic, outcome-based product goals using a metric, target, and timeframe structure that anchors the entire GIST hierarchy and replaces vague themes on a traditional product manager roadmap.
Start by identifying a specific business or user outcome you want to move, not a feature to ship. Write the goal as a metric plus a target value plus a timeframe. For example, 'Increase 30-day retention from 22% to 30% by Q3.' Then validate that the metric is observable today, that the target is ambitious but achievable, and that the timeframe gives your team enough room to run experiments. This goal becomes the top of your GIST hierarchy, anchoring every idea, step-project, and task beneath it.
Outcome: You produce a small set of concrete, time-bound product goals with baseline metrics and targets that the entire team can evaluate ideas against, making prioritization decisions faster and removing ambiguity from your product manager roadmap.
Prerequisites
- Basic familiarity with the GIST Planning Framework and its four layers (Goals, Ideas, Step-projects, Tasks)
- Access to current product analytics or business metrics so you can identify baselines
- Understanding of your company's strategic objectives for the current planning period
- Working knowledge of the difference between leading and lagging indicators
Overview
Every product manager roadmap eventually faces the same problem: the themes at the top are too vague to guide decisions at the bottom. Labels like 'Improve onboarding' or 'Expand enterprise' sound strategic, but they fail the most basic test of usefulness. When a developer asks 'Should I build feature A or feature B this sprint?', a vague theme provides no answer. Defining measurable product goals in the GIST Planning Framework solves this by replacing those fuzzy headings with goals that specify exactly what outcome to move, how much to move it, and by when. The result is a hierarchy where every idea, experiment, and task can be traced back to a number the team is trying to change.
The artifact you produce is a goal sheet containing 2-5 goals, each written in a consistent format: a named metric, its current baseline, a target value, and a deadline. Something like 'Reduce median time-to-first-value from 14 minutes to 6 minutes by end of Q2.' This sheet becomes the top layer of GIST and the filter for everything beneath it. Ideas get generated to serve these goals. Step-projects get scoped to test whether those ideas actually move the metric. Tasks get assigned to execute the step-projects. Without crisp goals, the rest of the framework drifts into feature-factory mode, where teams ship things but cannot explain why.
The specific challenge this skill addresses is the translation gap between company strategy and team-level execution. Company strategy might say 'grow revenue 40% this year.' That is a valid business objective, but it is too broad for a product team to act on directly. Your job is to decompose that into product-level outcomes that are within your team's sphere of influence. For a product manager roadmap to be credible, it needs goals that the team can actually affect through product changes, not goals that depend on sales hiring or macroeconomic conditions. This skill teaches you to find that sweet spot and write goals that are high enough to matter strategically but specific enough to drive daily prioritization.
Success looks like this: every member of your team, when asked 'What are we trying to achieve this quarter?', gives the same answer, phrased in the same metric, with the same target number. That alignment is not a soft cultural benefit. It is a mechanical prerequisite for the rest of GIST to function, because ideas, step-projects, and tasks all inherit their justification from goals.
How It Works
A measurable goal in GIST works because it converts strategic intent into a feedback signal. Without a feedback signal, the team cannot distinguish between an idea that is working and one that is not. The goal provides that signal by naming the metric you will watch and the movement you expect to see.
The structure of a GIST goal has four components. First, the metric itself, which is a number your product can influence. Second, the current baseline, which is the value of that metric right now. Third, the target, which is the value you want to reach. Fourth, the timeframe, which is the deadline by which you expect to reach it. All four components are necessary. Drop the baseline and you cannot tell whether the target is ambitious or trivial. Drop the timeframe and you have an aspiration, not a commitment. Drop the target and you have a dashboard, not a goal.
The reason this structure works within the GIST Planning Framework is that it creates a clean evaluation function for the layers beneath it. When you have a bank of ideas, you can ask: 'Which of these ideas, if successful, would move this metric by this amount?' That question is answerable. If your goal were 'Improve the user experience,' the same question becomes subjective and political. Metrics make prioritization mechanical rather than emotional.
There is an important distinction between outcome metrics and output metrics. Output metrics count things you ship: number of features released, pages redesigned, integrations built. Outcome metrics count things that change for users or the business: retention rate, revenue per user, time to complete a task. GIST goals must be outcome metrics. The reason is structural. If your goal is 'Ship 5 integrations,' then every idea that involves building an integration automatically scores well, regardless of whether it moves the business. You have turned your goal into a feature specification, which defeats the purpose of having a goal at all.
The timeframe component deserves special attention. In GIST, goals operate on the longest cadence, typically annual or quarterly. They change less frequently than ideas (quarterly to monthly), step-projects (weekly to biweekly), or tasks (daily). A good timeframe is long enough that meaningful experiments can run but short enough that the team feels urgency. For most product teams, quarterly goals hit this balance. Annual goals work for large strategic bets where the metric will not move in 90 days, such as entering a new market segment.
One subtle but critical mechanic: goals should be partially within your control. If a goal depends entirely on external factors, like a macroeconomic shift or a partner's product launch, the team cannot learn from failure. They cannot tell whether their ideas were wrong or their environment changed. The ideal goal sits at the intersection of 'strategically important' and 'we can influence this through product decisions.' When you find that intersection, you have a goal that motivates action and produces learning regardless of whether the target is hit.
Finally, the number of goals matters. Cognitive load research and practical experience converge on the same range: 2-5 goals per team per quarter. Fewer than two and you risk tunnel vision on a single metric at the expense of everything else. More than five and the team cannot hold them all in working memory, which means prioritization reverts to gut feel. Three is often the ideal number for a team of 5-8 people.
Step-by-Step
Step 1: Inventory the strategic inputs
Collect every document, presentation, and verbal directive that describes what the company or business unit is trying to achieve. This includes OKRs, board deck highlights, CEO memos, strategy documents, and any explicit priorities from leadership. Also gather recent customer research, NPS data, churn analysis, and support ticket trends. The purpose of this step is to build a complete picture of the strategic landscape so your goals do not exist in a vacuum.
Read through all materials and extract a flat list of stated objectives, each phrased as closely to the original wording as possible. You should end up with 8-20 raw strategic inputs, some overlapping, some contradictory. That is normal at this stage.
Tip: If strategic inputs are scattered across Slack messages and meeting recordings, timebox this collection to 90 minutes. Perfection here is the enemy of progress. Missing one input is far less costly than spending a week gathering inputs and never writing a goal.
Step 2: Identify the metrics your product can influence
' Map each input to one or more candidate metrics. ' Write down every candidate metric, even if you are not sure the data exists yet. Then filter the list by two criteria: (a) the metric is observable today, meaning you can pull a current number from your analytics, database, or a manual count, and (b) the metric is influenceable by product changes your team can ship. Remove any metric that fails either test.
You should have 5-12 candidate metrics remaining.
Tip: If you discover that a strategically important metric is not currently being tracked, flag it separately. Setting up instrumentation for a missing metric can itself be a step-project under the goal once the goal is defined.
Step 3: Establish baselines for each candidate metric
Pull the current value for each candidate metric. Use the most recent complete period, whether that is the last 30 days, last quarter, or last month, depending on the metric's natural cadence. Document exactly how the metric is calculated, including the query, the dashboard, or the spreadsheet formula. This documentation matters because goals are useless if two people calculate the metric differently and get different answers.
If the metric has meaningful variance, pull 3-6 periods of historical data so you can see the trend. Write down the baseline value, the source, the calculation method, and the trend direction for each metric.
Tip: Beware of seasonality. If your product has a strong seasonal pattern, a trailing 30-day average might not represent the true baseline for the upcoming quarter. Compare the same quarter last year, if available, to get a more honest starting point.
Step 4: Select 2-5 goals and set targets
From your candidate metrics, select the 2-5 that best balance strategic importance, team influence, and measurement feasibility. For each selected metric, set a target value. The target should be ambitious enough that hitting it requires new ideas and experiments, not just continuing current work. But it should be grounded enough that the team believes it is reachable with strong execution.
A useful heuristic: if the team is 90% confident they will hit the target, it is too easy. If they are less than 30% confident, it is demoralizing. Aim for 50-70% confidence. Write each goal in the format: 'Metric: [name].
Baseline: [current value]. Target: [target value]. ' Below each goal, write one sentence explaining why this metric matters to the company strategy, creating the link back to the strategic inputs from Step 1.
Tip: If you are torn between two metrics that seem equally important, ask: 'If I could only know one number next quarter, which would tell me more about whether we are on the right track?' That question often breaks ties quickly.
Step 5: Stress-test each goal for gaming and perverse incentives
' This is not cynicism. It is a design review for your measurement system. If the goal is 'Increase free trial signups by 40%,' the laziest path might be removing all friction from the signup form, which could flood the funnel with low-quality leads and actually hurt downstream conversion. If you discover a gaming vector, you have two options: add a guardrail metric (a secondary metric that must not degrade while you pursue the primary metric) or redefine the goal to be more specific.
For the trial signup example, changing the goal to 'Increase free trial signups that reach activation milestone by 40%' closes the gaming vector. Document any guardrail metrics alongside each goal.
Tip: Run this stress test with engineers and designers, not just PMs. Engineers in particular are excellent at identifying shortcuts that technically satisfy a metric while violating its intent.
Step 6: Validate alignment with stakeholders
Share your draft goal sheet with your manager, cross-functional leads (engineering, design, marketing, sales), and any key stakeholders. The goal of this conversation is not approval. It is alignment testing. ' Collect feedback and adjust.
Common adjustments include adding a guardrail metric a stakeholder flagged, narrowing a target that leadership thinks is too aggressive for the current quarter, or swapping a metric that another team is already owning. The output of this step is a finalized goal sheet with stakeholder buy-in.
Tip: Present goals as drafts, not finished products. If stakeholders feel like they are being presented a fait accompli, they will push back on principle. If they feel like co-authors, they will become advocates.
Step 7: Connect goals to the idea layer
For each goal, brainstorm 3-10 ideas that might move the metric toward the target. These are hypotheses, not commitments. ' Store these ideas in your idea bank. This step is critical because it tests whether the goal is actionable.
If the team cannot generate at least three plausible ideas for a goal, the goal might be too abstract, too distant from the product, or outside the team's sphere of influence. In that case, revisit Step 4 and refine or replace the goal. The connection between goals and ideas is what makes a product manager roadmap in GIST dynamic rather than static. Goals stay fixed.
Ideas are the flexible layer where creativity and experimentation happen.
Tip: Do not evaluate or score ideas at this stage. The point is to verify that the goal generates ideas, not to pick the best one. Scoring comes later using ICE or a similar framework. See [Prioritizing Product Ideas Using ICE Confidence Scoring](/skills/prioritizing-ideas-with-ice-scoring) for that step.
Step 8: Publish the goal sheet and set the review cadence
Put the finalized goal sheet somewhere the entire team sees it regularly: a wiki page, a Notion doc, a physical poster, a pinned Slack message. The location matters less than the visibility. Then set a review cadence. For quarterly goals, a monthly check-in is appropriate.
During each check-in, pull the current metric values, compare them to baselines and targets, and discuss which ideas and step-projects are contributing to movement. If a metric is flat after the first month and no experiments are in flight, that is an early warning that the team has not translated the goal into action. The goal sheet is a living document. If the business context changes dramatically mid-quarter, such as a major competitor launch or a pivot in company strategy, update the goals rather than pretending the original goals are still relevant.
Tip: Color-code goal progress with a simple traffic light: green if the metric is trending toward the target, yellow if flat, red if moving in the wrong direction. This makes the monthly review a 5-minute scan rather than a 30-minute analysis.
Examples
Example: Early-stage B2B SaaS (team of 5)
A small B2B SaaS company selling a project management tool to agencies has 800 paying customers and is pre-Series A. The CEO's stated priority is 'reduce churn to extend runway.' The product team has one PM, two engineers, and one designer. Analytics are basic: Mixpanel for events, Stripe for revenue.
5% for the past six months. She also finds that churn is concentrated among accounts in their first 60 days: 42% of churned accounts never completed onboarding. She maps the CEO's priority to two candidate metrics: overall monthly churn rate and 60-day onboarding completion rate. She selects the 60-day completion rate as the primary goal because it is more directly influenceable by the product team and likely a leading indicator of churn.
The baseline is 38% of new accounts completing onboarding within 60 days. She sets the target at 55% by end of Q2, which would roughly halve the churn contribution from unactivated accounts. As a guardrail, she adds 'monthly gross churn must not exceed 7%' to ensure that fixing onboarding does not come at the expense of retention for mature accounts. She brainstorms five ideas: a guided setup wizard, an in-app checklist, a 'quick start' template, proactive outreach from support on day 3, and a reduced free trial period to create urgency.
Each is stored in the idea bank with an ICE score for later prioritization. The goal sheet is a single Notion page shared with the CEO and engineering lead.
Example: Mid-stage B2C mobile app (team of 12)
A consumer fitness app with 2 million MAU and a freemium model. The company just raised Series B and the board wants to see 'improvement in monetization.' The product org has three squads. This squad owns the premium upgrade experience. The analytics stack includes Amplitude, RevenueCat, and a data warehouse.
40/month. The board's 'improvement in monetization' maps to multiple candidate metrics, but the PM focuses on what her squad controls: trial start rate and trial-to-paid conversion. She eliminates ARPPU because it depends on pricing changes that the growth team owns. She sets two goals.
' The second goal is a guardrail. She deliberately does not set a combined revenue target because she wants the team thinking about the behavioral funnel, not the revenue number. During stress-testing, the designer flags that the easiest way to increase trial starts is to add dark patterns, like auto-enrolling users in trials. ' She brainstorms eight ideas, including a contextual trial prompt after the user's tenth workout, a comparison screen showing premium vs.
free features, and a social proof banner showing how many users upgraded this week. The goal sheet is published in the squad's Confluence space and reviewed biweekly.
Example: Enterprise platform team (team of 20+)
A large enterprise software company's platform team is responsible for APIs and developer tools that other product teams build on. The company's annual plan calls for 'accelerating time-to-market for new features across all product lines.' The platform team has no direct end-user metrics, which makes goal-setting uniquely challenging.
The platform PM realizes that 'accelerating time-to-market' is a company-level objective, not a platform goal. 2 days integrating with the platform's authentication service every time they build a new feature. She validates this with data from Jira, counting the average number of days spent on auth-related tickets per feature project. ' The metric is measurable (average days per integration project, tracked in Jira), influenceable (the platform team controls the auth SDK), and strategically aligned (fewer integration days equals faster time-to-market).
' She then brainstorms ideas: a self-serve auth SDK with documentation, a pre-configured auth template for the internal framework, and an auth-as-a-service API that eliminates integration entirely. The goal sheet is shared with all product team leads so they understand the platform team's priorities and can plan accordingly. Monthly reviews include pulling integration time data from the three most recent feature projects.
Example: Product manager updating a traditional roadmap (individual contributor)
A product manager at a mid-size company has been asked to present her Q4 product manager roadmap to the leadership team. Her current roadmap is a Gantt-style timeline with feature names and delivery dates. She wants to restructure it using GIST goals to make the roadmap outcome-oriented instead of output-oriented.
She starts by listing the features on her current roadmap: a new dashboard redesign, a Slack integration, and an in-app notification system. ' and traces each answer to a user or business outcome. The dashboard redesign is meant to increase daily active usage. The Slack integration is meant to reduce churn among team accounts.
The notification system is meant to increase feature discovery. 1%/month, and feature discovery rate (percentage of users who try a feature within 30 days of release) is 11%. ' The original features become ideas under these goals, not the goals themselves. This means the Slack integration is no longer a commitment.
It is one hypothesis for reducing team churn, sitting alongside alternatives like an onboarding email series for teams or an admin dashboard showing team engagement. When she presents the updated roadmap to leadership, she leads with the three goals and their baselines, then presents the top-ranked ideas under each goal. Leadership appreciates the clarity because they can now evaluate progress by metric movement, not by whether a feature shipped on time.
Best Practices
Write every goal as a metric plus baseline plus target plus timeframe, with no exceptions. If you cannot fill in all four fields, you do not have a goal yet. You have a wish. Teams that allow incomplete goals inevitably revert to measuring activity (features shipped) instead of outcomes (metrics moved), which undermines the entire GIST hierarchy.
Limit each team to 2-5 goals per planning period. Research on cognitive load and practical experience from companies using OKRs both converge on this range. Teams with more than five goals cannot hold all of them in working memory during daily prioritization decisions, which means extra goals function as decoration rather than decision tools.
Separate outcome metrics from guardrail metrics explicitly. An outcome metric is what you are trying to move. A guardrail metric is what you are trying not to break while moving the outcome. Mixing them into one list of equal weight dilutes focus. Write guardrail metrics in a distinct section of the goal sheet, formatted as 'Do not let [metric] fall below [threshold].'
Include the 'why' sentence for every goal, linking it to the strategic input it serves. This sentence is not for the PM who wrote the goal. It is for the engineer six weeks later who needs to make a tradeoff decision between two tasks and needs to understand why the goal matters. Without the 'why,' goals become arbitrary numbers.
Review goals monthly with actual metric data, not narratives. Pull the number. Compare it to the baseline. Compare it to the target trajectory. If you are behind, discuss what experiments to run. If you are ahead, discuss whether to raise the target or shift effort to a lagging goal. This review should take 15-30 minutes, not an hour.
Use leading indicators alongside lagging indicators when possible. If your quarterly goal is 'increase revenue per user from $12 to $18,' that number might not move visibly for two months. Pair it with a leading indicator like 'percentage of users who encounter the premium feature prompt' so the team gets weekly signal on whether their experiments are reaching the right audience.
Never set a goal you cannot explain to a new team member in under 60 seconds. If the goal requires a five-minute preamble about company history or market dynamics, it is either too complex or too abstract. Simplify until it passes the 60-second test. Complex reasoning belongs in the supporting documentation, not in the goal statement itself.
Avoid setting goals that compete with each other without acknowledging the tension. If one goal is 'increase trial signups by 40%' and another is 'increase trial-to-paid conversion by 20%,' the team needs to know that optimizing hard for signups might dilute conversion quality. Document known tensions between goals so the team can navigate tradeoffs deliberately rather than discovering conflicts mid-quarter.
Common Mistakes
Setting output goals disguised as outcome goals
Correction
This is the most common failure mode. It looks like 'Launch the new onboarding flow by March 15' or 'Ship 3 integrations this quarter.' These sound specific and measurable, but they measure what you ship, not what changes as a result. The diagnostic signal is simple: if the goal can be achieved regardless of whether any user behavior changes, it is an output goal. Rewrite it by asking 'What should happen after we ship this?' The answer is your real goal. 'Launch the new onboarding flow' becomes 'Reduce median time-to-first-value from 14 minutes to 6 minutes by end of Q1.'
Choosing metrics the product team cannot influence
Correction
This often happens when PMs inherit company-level OKRs and adopt them verbatim. A company goal like 'Increase total revenue by 40%' depends on sales capacity, marketing spend, pricing strategy, and product quality. If the product team claims this as their goal, they cannot learn from failure because too many variables are outside their control. The catch-early signal is when the team's proposed ideas feel disconnected from the metric.
If every idea you brainstorm addresses only a small piece of the metric, the metric is too broad.
Setting targets without knowing the baseline
Correction
Teams frequently pick round numbers that sound good, like 'Reach 50% activation rate,' without knowing whether the current rate is 48% or 12%. A target of 50% means completely different things in those two scenarios. This happens because pulling baselines requires analytics access and SQL queries, which feels like grunt work compared to the strategic fun of setting goals. But a goal without a baseline is just a guess.
Before finalizing any target, pull at least three periods of historical data so you can see the current level and the natural trend. If the metric is already growing at 5% per month organically, a target that implies 6% monthly growth is not ambitious.
Creating too many goals to cover every stakeholder's concern
Correction
This is a political failure, not an analytical one. It happens when the PM tries to make every stakeholder happy by including their priority as a goal. The result is a goal sheet with 8-12 items, which effectively means no goals at all because the team cannot focus. The signal to watch for: if the team struggles to recall all goals from memory in a standup, there are too many.
The fix is to have an explicit conversation about what is not a goal this quarter. Write down the deprioritized items and explain why.
Treating goals as immutable commitments rather than directional bets
Correction
Some teams set goals and then refuse to update them even when the strategic context changes dramatically, such as a competitor launching a similar product, a major customer churning, or a pivot in company direction. They treat goal-setting as a contract rather than a planning tool. The GIST framework explicitly encourages updating goals when the information landscape changes. The monthly review is the right venue for this.
If you discover in month two that your most important metric is actually something you did not originally goal on, change the goal. Document why, inform stakeholders, and adjust the idea layer accordingly.
Writing goals that are so narrow they constrain ideation
Correction
An overly narrow goal like 'Increase click-through rate on the pricing page CTA from 4% to 8%' is technically measurable, but it has already prescribed the solution space. The team will only consider ideas that involve changing the pricing page CTA. A broader goal like 'Increase self-serve upgrade rate from 2% to 4%' opens up the idea space to include pricing page changes, in-app upgrade prompts, usage-based nudges, email campaigns, and more. The test: if only one category of idea could plausibly serve the goal, the goal is too narrow.
Widen it until at least three different types of ideas become relevant.
Other Skills in This Method
Designing Step-Projects to Validate Product Ideas
How to break ideas into small, time-boxed experiments (step-projects) of no more than 10 weeks that test assumptions and build evidence iteratively.
Breaking Step-Projects into Actionable Daily Tasks
How to decompose validated step-projects into granular, developer-ready tasks using agile tools like Kanban boards or sprint backlogs.
Presenting GIST Plans in Stakeholder and Interview Settings
How to communicate the GIST planning hierarchy to executives, cross-functional teams, and in product manager interviews to demonstrate strategic thinking.
Replacing Traditional Product Roadmaps with GIST Planning
How to transition a product team from feature-based roadmaps to the GIST framework while maintaining stakeholder alignment and executive buy-in.
Prioritizing Product Ideas Using ICE Confidence Scoring
How to evaluate and rank competing product ideas by scoring them on Impact, Confidence, and Ease to decide which hypotheses to test first.
Managing Different Planning Cadences Across GIST Layers
How to operate goals on quarterly/annual cycles, ideas continuously, step-projects in short sprints, and tasks daily to maintain agile responsiveness.
Building and Managing an Idea Bank for Product Development
How to continuously collect, document, and organize hypothetical solution ideas that map to strategic goals using an always-open idea bank.
Related Skills from Other Methods
Frequently Asked Questions
How many goals should a single product team have per quarter?
Two to five. Fewer than two creates tunnel vision and makes the team fragile if one goal becomes irrelevant mid-quarter. More than five dilutes focus to the point where goals stop guiding daily decisions. Three is the sweet spot for most teams of 5-12 people. If you have more than five candidates, force-rank them and explicitly deprioritize the rest, documenting the reasoning so stakeholders understand.
How do I define measurable goals when my product analytics are immature?
Start with whatever data you have, even if it is manual. You can count activated users by querying the database directly. You can measure onboarding completion by tagging support tickets. The baseline does not need to come from a polished dashboard. It needs to come from a repeatable measurement process. If a metric truly cannot be measured today, make setting up instrumentation your first step-project under that goal, with a deadline of two weeks. Then set the actual target once you have baseline data.
Should I define goals before or after generating ideas?
Before. Goals come first in the GIST hierarchy for a structural reason: they constrain the idea space. If you generate ideas first and then find goals to justify them, you have reversed the logic and your 'goals' are just rationalizations for features you already wanted to build. The one exception is when you are doing a discovery sprint with no existing strategic direction, in which case brainstorming ideas can reveal what outcomes the team implicitly cares about, which you then formalize as goals.
What is the difference between a GIST goal and an OKR?
They are structurally similar. Both express outcomes as measurable targets. The main difference is operational context. An OKR typically has one objective (qualitative) with 2-5 key results (quantitative). A GIST goal combines these into a single statement: the metric is the key result, and the 'why' sentence provides the objective. GIST goals also explicitly connect downward to ideas and step-projects, which most OKR frameworks leave unspecified. If your company already uses OKRs, you can treat your GIST goals as the product team's key results within the company OKR structure.
How do I handle goals that conflict with each other?
Acknowledge the tension explicitly in your goal sheet rather than pretending it does not exist. Write a note like: 'Goals 1 and 2 may compete. Increasing trial signups (Goal 1) could dilute trial-to-paid conversion (Goal 2) if signup quality drops. ' Then, during monthly reviews, monitor both goals together and discuss whether the tension is materializing. If it is, the team decides which goal takes priority for the remainder of the quarter.
Why does my goal progress keep stalling after the first month?
The most common cause is a gap between goal-setting and idea execution. The team sets goals, feels accomplished, and then returns to their existing backlog without actually generating or prioritizing ideas that serve the new goals. The fix is Step 7 in the process: immediately connect each goal to at least three ideas and then run those ideas through ICE scoring within the first week. If no experiment is in flight within two weeks of setting a goal, the goal is decoration. Use the monthly review as a forcing function to ask: 'What experiment ran this month, and what did we learn about this metric?'
How do I set targets when I have no historical data to anchor against?
Use industry benchmarks, analogies from adjacent products, or educated estimates. Document that the target is a hypothesis, not a data-driven projection. Write something like: 'Target is estimated. Industry benchmark for SaaS activation in this category is 40-60%. ' The act of writing the estimate down, along with its uncertainty, is more valuable than waiting until you have perfect data. You will learn from the gap between your estimate and reality.