The weakest metric in your SaaS is not automatically your growth bottleneck. This guide shows how to map the path to your goal, compare Growth Movements, investigate competing explanations and identify the constraint that actually deserves attention.
Your SaaS can have a bad activation rate without having an activation problem.
It can have low traffic without having an acquisition problem.
It can have a weak trial-to-paid conversion rate without pricing or sales being the main thing limiting growth.
That is what makes growth diagnosis difficult.
When a number looks bad, it immediately creates a story.
Traffic is flat, so you need SEO.
Signups are low, so you need a new landing page.
Activation is weak, so you redesign onboarding.
Sales conversion dropped, so you change the pitch.
Churn increased, so retention becomes the priority.
Any of those diagnoses might be correct.
The dangerous part is that they can also be completely reasonable explanations for the wrong problem.
And once the diagnosis is wrong, every decision that follows inherits the mistake.
You choose a strategy for the wrong problem.
You prioritize tactics for the wrong strategy.
You spend weeks improving a metric that does not materially change the outcome you actually care about.
The team is busy.
The dashboard may even improve.
Growth remains stuck.
This guide is about preventing that sequence.
By the end, you should be able to produce a concrete Growth Bottleneck Diagnosis for your SaaS:
the outcome you are trying to change;
the path that creates it;
the Growth Movements along that path;
the evidence for each candidate;
the expected downstream impact of improving them;
competing explanations;
the current Limiting Movement;
your confidence in that diagnosis;
and what happens next.
The goal is not to find something wrong.
Most SaaS companies have many things that could be improved.
The goal is to identify what deserves to constrain your attention right now.
A SaaS growth bottleneck is the part of the growth path that currently limits a specific downstream outcome more than the alternatives.
That wording matters.
A bottleneck is not simply:
a low number;
a bad benchmark;
a large drop-off;
an unhappy team;
a recurring customer complaint;
a metric that declined last month.
Those are signals.
They tell you where to investigate.
They do not automatically tell you where the system constraint sits.
The Theory of Constraints uses a similar system-level idea: improving the constraint can improve the performance of the system, while optimizing non-constraints may create local efficiency without increasing overall throughput.
The growth version of that problem looks familiar.
You improve ad CTR but qualified pipeline does not move.
You increase signup conversion but activation quality falls.
You ship onboarding improvements but new customers remain flat.
You generate more leads but Sales cannot process the existing volume.
The local metric changed.
The business outcome did not.
That is why the first question in a growth diagnosis should not be:
Which metric is worst?
It should be:
What outcome are we trying to create, and what currently prevents more of that outcome from happening?
Before diagnosing anything, separate four different concepts.
A symptom is evidence that something may be wrong.
Examples:
traffic stopped growing;
activation declined;
churn increased;
CAC rose;
pipeline is flat.
A symptom is an observation.
It is not yet a diagnosis.
A candidate is a part of the growth system that has enough evidence against it to deserve deeper investigation.
For example:
Signup β Activated User may be limiting customer growth because activation has fallen for three consecutive cohorts and a significant amount of qualified volume is being lost there.
That is a useful hypothesis.
It still needs to survive further analysis.
A Limiting Movement is the transition you currently believe most constrains the specific goal you are trying to achieve.
The diagnosis should be based on evidence, alternatives and expected downstream leverage.
The root cause explains why the Limiting Movement is constrained.
If Signup β Activated User is the Limiting Movement, the root cause could be:
poor onboarding;
bad expectation-setting before signup;
low-fit acquisition;
missing product value;
technical friction;
incorrect activation definition;
the wrong user reaching the product.
The location of the constraint and the cause of the constraint are not necessarily the same thing.
This distinction is also why growth problems are easy to misdiagnose.
A symptom can appear downstream while its cause began several movements earlier.
Several signals regularly create false diagnoses.
Imagine:
Visitor β Signup: 6%
Signup β Activated: 32%
Activated β Customer: 48%
The 6% rate looks worst.
That tells you almost nothing by itself.
Different movements naturally operate at different conversion levels.
What matters is whether the movement is constraining your target outcome and whether meaningful headroom exists.
Losing 10,000 low-intent website visitors might matter less than losing 20 enterprise opportunities.
Absolute loss ignores value and downstream leverage.
You discover that activation is below an industry benchmark.
That makes activation worthy of investigation.
It does not prove activation deserves priority.
A different movement may be limiting far more of your goal.
Customers complain constantly about feature X.
The feature may deserve attention.
But frequency of complaints is not the same thing as impact on the target outcome.
Marketers often see acquisition problems.
Product teams often see onboarding or engagement problems.
Sales teams see lead quality or objection problems.
Technical founders see things that can be fixed by building something.
A diagnosis should survive the expertise of the person looking at it.
Suppose activation is terrible.
That does not mean onboarding caused it.
You may be attracting users with the wrong intent.
The problem becomes visible during activation.
Its cause begins during acquisition.
This is one of the reasons a generic funnel is not enough.
You need to understand the path that creates the outcome.
There is no meaningful bottleneck without a defined outcome.
βGrow the companyβ is not enough.
Neither is:
Improve conversion.
A useful diagnostic goal contains at least:
Metric + baseline + target + time horizon + relevant segment
For example:
Increase new self-serve SMB customers from 60 to 80 per month by the end of Q4.
Now the diagnosis has boundaries.
You are not diagnosing the entire SaaS company.
You are diagnosing:
What currently prevents this system from producing 80 new self-serve SMB customers per month?
That distinction becomes important immediately.
Imagine the company also sells Enterprise.
The Enterprise growth bottleneck may be completely different.
A SaaS does not have one timeless bottleneck for every objective, market and segment.
The useful constraint is goal-specific.
Get more customers.
Increase new customers from 60 to 80 per month.
Increase new self-serve SMB customers from 60 to 80 per month by the end of Q4 while maintaining current 90-day retention.
The last version prevents the team from βsolvingβ acquisition by flooding the product with low-quality customers.
Before continuing, answer:
What exact outcome should increase?
What is the current baseline?
What is the target?
Over what period?
Which segment matters?
What important condition should not deteriorate while the goal improves?
If those answers are unclear, the diagnosis is not ready to move forward.
Now identify the meaningful states someone must move through before your outcome can happen.
A simple product-led path might be:
Website Visitor β Signup β Activated User β Paying Customer
A search-led path might begin earlier:
Search User β Website Visitor β Signup β Activated User β Customer
A sales-assisted path might look like:
Website Visitor β Lead β Qualified Lead β Meeting β Opportunity β Customer
But most real SaaS companies are not one straight funnel.
They look more like this:
That is closer to a growth system.
Different sources can feed the same state.
Different paths can emerge from the same state.
Some paths matter to one goal and not another.
In Hacknator, a meaningful state is represented as a Node.
The transition from one state to another is a Growth Movement.
For example:
Website Visitor β Signup
is one Growth Movement.
Signup β Activated User
is another.
The connected system is the Growth Blueprint.
A metric tells you what happened.
A movement gives that metric causal context.
βActivation rate is 25%β is useful.
But this is more useful:
600 qualified users entered Signup β Activated User, 150 reached activation within seven days, and the movement has declined from 38% to 25% over four cohorts.
Now you have:
source state;
target state;
volume;
conversion;
time;
trend.
That is something you can diagnose.
A common mistake is attempting to model the whole business before doing anything.
Start with the path relevant to the current goal.
If your goal is self-serve acquisition, you probably do not need every enterprise sales state.
If your goal is expansion revenue, Search User β Website Visitor may be irrelevant.
Your Blueprint can be large.
Your diagnosis should be scoped.
Do not compare movements with one metric.
Create the same evidence structure for each.
A useful Movement Evidence Card contains:
DimensionQuestionInput volumeHow many people enter this movement?Output volumeHow many reach the next state?ConversionWhat percentage completes the movement?LatencyHow long does the transition take?QualityWho completes it, and how valuable are they?TrendIs performance stable, improving or deteriorating?Segment varianceDo important cohorts behave differently?Historical potentialHas this movement performed materially better before?Downstream leverageWould improving it meaningfully change the goal?Evidence confidenceHow much do you trust the measurement?
This prevents one impressive-looking chart from becoming the entire diagnosis.
Conversion rate without volume can be misleading.
A 50% improvement to a movement with 20 monthly users may change less than a 5% improvement to one processing 10,000.
Record both.
Two movements with the same conversion rate can behave very differently.
If one converts within five minutes and another takes 45 days, the diagnosis, experiment design and observation window all change.
Funnel tools such as Amplitude explicitly separate conversion, largest drop-off and time-to-convert because they describe different properties of the journey.
Treat them separately.
Not all converted users are equal.
A movement can improve numerically while worsening the composition of the people entering the next state.
This is especially important in acquisition.
More signups do not necessarily mean more growth.
You may simply be sending more low-fit users downstream.
A movement that fell last week after a tracking change is different from one that has constrained the system for six months.
Look for persistence.
Aggregate metrics hide structure.
Break important movements down by dimensions such as:
ICP;
acquisition source;
country;
plan;
company size;
device;
cohort;
use case;
sales motion.
If the diagnosis changes completely when you isolate the segment connected to your goal, the aggregate was not the right unit of analysis.
At this stage, do not choose the winner.
Create a shortlist.
A strong bottleneck candidate usually has several of these properties:
The movement prevents enough users, accounts or revenue from reaching later states to affect the goal.
Something suggests the movement can perform better.dro
That could come from:
historical performance;
a stronger cohort;
a stronger segment;
experiments;
customer evidence;
a known structural issue.
Changing the movement should materially affect the final outcome.
The signal survives more than one anomalous period.
A terrible conversion rate in an irrelevant cohort should not determine your roadmap.
Do not make high-confidence strategic decisions from broken events or poorly defined stages.
You do not need a perfect mathematical score.
The objective is to reduce ten possible problems to the two or three that deserve investigation.
Call them bottleneck candidates.
Not bottlenecks.
That language creates useful discipline.
Now ask a counterfactual question:
If this Movement improved by a plausible amount and the rest of the system remained approximately constant, how much would the goal change?
The word plausible matters.
Do not assume every conversion rate can double.
Use one of three reference points.
How well has this exact Movement performed under comparable conditions before?
Does one relevant segment already demonstrate materially better performance?
If historical evidence is weak, model a modest improvement rather than an imaginary best-in-class benchmark.
Current path:
4,000 Visitors β 400 Signups β 120 Activated Users β 60 Customers
Rates:
Visitor β Signup: 10%
Signup β Activated: 30%
Activated β Customer: 50%
Suppose Signup β Activated historically reached 40%.
Instead of asking:
Is 30% activation bad?
ask:
What happens if this movement returns to a demonstrated 40%?
The calculation becomes:
Current:
Potential downstream delta:
+20 customers/month
Now compare that with another candidate.
If increasing qualified visitor volume by a plausible 10% produces only six additional customers, activation currently has more modeled downstream leverage.
That still does not prove activation is the Limiting Movement.
But you now have a much stronger reason to investigate it.
This step prevents one of the most dangerous false diagnoses.
Imagine:
Signup β Activated = 25%
Looks bad.
Now split the same movement.
250 signups β 120 activated
48% activation.
350 signups β 30 activated
8.6% activation.
The aggregated 25% made activation look like a product problem.
But the product activates nearly half of the ICP users.
The problem may actually be that most signups are low-fit.
That changes the investigation.
Instead of:
How do we redesign onboarding?
you may need to ask:
Why are low-fit users becoming such a large share of signups?
The bottleneck may sit upstream.
Or your path may itself be poorly modeled.
Perhaps βSignupβ hides two states that matter:
Website Visitor β Qualified Signup β Activated User
This is an important diagnostic signal.
Sometimes better diagnosis requires improving the Blueprint before improving the business.
A candidate becomes useful only when you understand what mechanism might be constraining it.
For most Growth Movements, investigate five classes of explanation.
Are the right people entering the movement?
Questions:
Which segments convert best?
Which acquisition sources produce high-quality downstream users?
Are low-fit users distorting the aggregate?
Are we attracting people the product was never designed to serve?
Useful evidence:
cohort analysis;
ICP attributes;
acquisition source;
revenue quality;
retention by source;
win/loss patterns.
Does the person entering the movement expect the right thing to happen next?
For example, a landing page might promise instant value while the product requires setup.
The user βfails activationβ inside the product.
The expectation problem began before signup.
Investigate:
landing-page messaging;
ad and keyword intent;
sales promises;
onboarding expectations;
product positioning;
customer language.
Is something unnecessarily preventing movement?
Examples:
complex forms;
technical bugs;
unclear navigation;
slow response;
excessive required steps;
confusing permissions;
sales handoff delays.
Evidence might include:
funnel drop-offs;
session recordings;
error events;
support tickets;
sales-call notes;
time-to-convert analysis.
Can the user understand or experience enough value to want to move forward?
A perfectly frictionless experience can still fail if the next state is not desirable.
Investigate:
activation behaviors;
time-to-value;
feature usage;
retention patterns;
interviews;
reasons for abandoning the journey.
Sometimes users want to move and the product works.
The organization cannot process the flow.
Examples:
Sales cannot respond fast enough;
implementation capacity is full;
support backlog slows activation;
approval rules create delays;
pricing policy blocks deals;
internal prioritization starves a critical path.
This matters because not every growth bottleneck is a UX or marketing problem.
Before declaring a Limiting Movement, force yourself to write at least one plausible alternative explanation.
Suppose the candidate is:
Signup β Activated User
Your primary hypothesis:
Onboarding complexity prevents otherwise qualified users from reaching value.
Competing hypothesis:
Low-fit acquisition is sending users into the product who were unlikely to activate regardless of onboarding.
Those hypotheses predict different evidence.
You would expect:
similar activation weakness across qualified segments;
concentrated drop-off around specific product steps;
session recordings showing friction;
successful users navigating around those problems;
improvements to the flow changing activation.
You would expect:
large activation differences by source or ICP;
high-fit users activating relatively well;
weak cohorts sharing acquisition characteristics;
downstream retention also varying by source;
onboarding changes having limited impact on low-fit users.
This is better than asking:
What do we think the problem is?
You are asking:
What would need to be true for this explanation to be correct?
That makes the diagnosis falsifiable.
Growth diagnosis is rarely certainty.
Do not hide that.
Assign a confidence level.
You have a plausible idea but:
instrumentation is weak;
the sample is small;
stages are poorly defined;
competing explanations remain equally plausible.
The next action should usually generate evidence.
Multiple signals support the diagnosis, but an important competing hypothesis remains unresolved.
The next action should test the diagnosis with limited exposure or cost.
Quantitative and qualitative evidence converge, competing hypotheses are materially weaker and a plausible mechanism connects the Movement to the target outcome.
The next action can justify stronger execution.
Confidence changes what kind of tactic is appropriate.
A low-confidence diagnosis should not immediately produce a six-month roadmap.
Do not write:
Activation is bad.
Use a diagnosis statement.
Template:
For the goal of [goal], [source state β target state] is the current Limiting Movement because [evidence]. Improving it from [current] toward [plausible state] is expected to change [downstream outcome] by approximately [impact]. The strongest competing hypothesis is [alternative]. Confidence: [level].
Example:
For the goal of increasing self-serve SMB customers from 60 to 80 per month, Qualified Signup β Activated User is the current Limiting Movement. Activation is 29% overall, has declined across four cohorts and historically reached 41% for comparable users. Returning to 38% would produce approximately 18 additional customers per month at current downstream conversion. Low-fit acquisition remains the strongest alternative explanation. Confidence: medium.
Now you have something that can be challenged.
That is what makes it useful.
Diagnosis tells you where to work.
Root-cause investigation narrows why the movement is constrained.
Strategy defines how you intend to change it.
If the Limiting Movement is:
Signup β Activated User
and the evidence points to excessive time-to-value, possible strategies include:
reduce setup before first value;
guide users toward one activation path;
remove non-essential onboarding decisions;
personalize onboarding by use case.
Those are strategies.
They operate the movement.
Only after selecting one should you choose a tactic.
For example:
Strategy: Reduce time-to-value.
Tactic:
Test a guided first-session flow that takes new project-management users directly from signup to creating their first live project.
This is fundamentally different from starting with:
We should redesign onboarding.
The work now has a reason to exist.
If you want the deeper prioritization logic after identifying the constraint, continue with the guide on deciding what your SaaS should focus on next.
Your first tactic should do one of two things:
improve the Limiting Movement;
increase confidence that the diagnosis is correct.
That distinction matters.
With high confidence, optimize.
With low confidence, learn.
Example:
You know a mandatory setup step creates major activation friction.
Tactic:
Remove or postpone the step for 50% of eligible new users and compare activation.
You suspect acquisition quality is driving weak activation.
Tactic:
Compare activation, retention and customer conversion across the three largest acquisition-intent cohorts before redesigning onboarding.
The second tactic might not change a customer-facing experience at all.
It still moves the growth system forward by resolving the diagnosis.
Consider a fictional SaaS called MetricFlow.
Its goal is:
Increase new self-serve SMB customers from 60 to 80 per month.
Current monthly flow:
Rates:
Website Visitor β Signup: 7.5%
Signup β Activated User: 25%
Activated User β Customer: 40%
Activation immediately attracts attention.
The team proposes:
Redesign onboarding.
Before doing that, they build the Movement Evidence Card.
Input: 600 signups.
Output: 150 activated.
Conversion: 25%.
Historical range: 24% to 31%.
Best recent cohort: 48%.
Trend: broadly stable.
Potential impact: high.
The 48% cohort is interesting.
They segment by ICP.
250 β 120 activated.
Activation:
48%.
350 β 30 activated.
Activation:
8.6%.
Now the diagnosis changes.
The product is capable of activating nearly half of the users it was built for.
Most signups are simply not those users.
The aggregate activation rate created the appearance of an onboarding constraint.
The team investigates further.
High-fit signups come disproportionately from:
specific search queries;
founder communities;
comparison pages;
referrals.
Low-fit signups arrive primarily from broad informational traffic.
They also retain worse after activation.
Now the competing hypotheses look like this.
Onboarding is broken.
Acquisition and qualification are sending too many low-fit users into signup.
Hypothesis B explains more of the evidence.
The Blueprint is updated.
Instead of:
Website Visitor β Signup β Activated User
the relevant path becomes:
Website Visitor β Qualified Signup β Activated User
The missing concept was not another onboarding screen.
It was qualification.
The Limiting Movement becomes:
Website Visitor β Qualified Signup
The next Strategy is not βImprove onboarding.β
It is:
Increase the share of high-intent, ICP-fit visitors and signups.
Possible tactics now include:
build content around high-intent problem queries;
remove broad low-intent positioning;
create use-case-specific landing paths;
tighten paid keyword targeting;
improve qualification before signup.
The same dashboard produced two radically different roadmaps depending on how the problem was modeled.
That is why bottleneck diagnosis comes before tactic prioritization.
The complete method can be summarized as:
Goal β Path β Growth Movements β Evidence β Candidates β Downstream Impact β Root Causes β Competing Hypotheses β Limiting Movement β Strategy β Tactic β Re-diagnose
Define the concrete outcome.
Map the states required to produce it.
Treat each transition between states as something that can be measured and improved.
Build a comparable evidence set for the relevant Movements.
Shortlist the Movements that have meaningful signs of constraint.
Estimate what a plausible improvement would do to the final outcome.
Investigate why each strong candidate is constrained.
Try to disprove your preferred explanation.
Document the strongest current diagnosis with a confidence level.
Choose how you intend to change that Movement.
Execute the smallest useful improvement or test.
Observe what changed in the system and identify the next constraint.
You can run the framework manually.
Use this template.
Outcome:[What are you trying to change?]
Baseline:[Current result]
Target:[Desired result]
Time horizon:[By when?]
Segment:[For whom?]
Guardrail:[What should not deteriorate?]
Source β target:[...]
Input volume:[...]
Output volume:[...]
Conversion:[...]
Latency:[...]
Trend:[...]
Relevant segments:[...]
Historical potential:[...]
Downstream impact:[...]
Evidence confidence:[...]
Repeat for every relevant Movement.
Movement:[...]
Why it may constrain the goal:[...]
Plausible improvement:[...]
Expected downstream delta:[...]
Movement:[...]
Why it may constrain the goal:[...]
Plausible improvement:[...]
Expected downstream delta:[...]
Candidate Limiting Movement:[...]
Root-cause hypothesis:[...]
Supporting evidence:[...]
Alternative explanation:[...]
What would be true if this explanation were correct?[...]
Evidence needed to resolve it:[...]
Limiting Movement:[...]
Reasoning:[...]
Confidence:Low / Medium / High
Main uncertainty:[...]
Strategy:[...]
First tactic:[...]
Expected signal:[...]
Review point:[...]
Do not replace missing evidence with certainty.
Reduce the confidence of the diagnosis.
Start with what exists.
Useful inputs can include:
CRM stages;
billing records;
GA4;
product analytics;
Search Console;
sales calls;
support tickets;
onboarding conversations;
session recordings;
manually counted cohorts;
founder knowledge.
Then identify which missing evidence creates the most uncertainty.
That itself can become the next task.
For example:
We cannot distinguish qualified from unqualified signups.
Your next piece of growth work might be:
Define qualification and instrument Signup β Qualified Signup.
That is a better action than redesigning onboarding based on an aggregate number you do not trust.
A SaaS can have many problems.
It can also have several constrained movements.
For execution, however, the useful question is narrower:
Which constraint most limits the current goal?
That creates focus.
Once you improve it, the system changes.
Another Movement may become limiting.
This is expected.
The goal is not to βsolve growth.β
The goal is to continuously improve the constraint that matters next.
Re-diagnose when:
the Limiting Movement improves materially;
the target goal changes;
the relevant ICP changes;
a new channel becomes significant;
pricing changes;
the product changes the user journey;
a strategy fails despite apparently successful tactics;
the target outcome does not move as expected.
The final case is especially important.
Imagine activation increases from 30% to 42%, exactly as planned.
But customer growth barely changes.
That is evidence.
Possible explanations include:
activation was not the real constraint;
your activation definition is weak;
downstream conversion became limiting;
the new activated users are lower quality;
another path now dominates the system.
The correct response is not automatically another activation experiment.
Re-diagnose.
Start with the outcome, not the dashboard.
Map the path required to create that outcome.
Treat the transitions between meaningful states as Growth Movements.
For each relevant Movement, compare volume, conversion, latency, quality, trends, segments, historical potential and downstream leverage.
Turn the strongest signals into bottleneck candidates.
Estimate what plausible improvements would do to the goal.
Investigate root causes.
Challenge your preferred explanation with competing hypotheses.
Then document the current Limiting Movement, including the evidence, uncertainty and confidence behind the decision.
Only then choose a Strategy.
Only then create Tactics.
And once the system changes, diagnose it again.
The goal is not just better analysis.
It is to make one relationship explicit:
Why is this the work we are doing now?
If you cannot connect a Tactic to a Strategy, a Strategy to a Growth Movement, and that Movement to the goal it is supposed to change, there is probably still a missing decision somewhere upstream.
Nothing in this framework requires Hacknator.
You can build the path in a whiteboard.
Track the evidence in spreadsheets.
Write competing hypotheses in documents.
Maintain strategies in one tool and tactics in another.
That works.
The difficulty appears as the system changes.
The goal changes.
A new segment becomes important.
The bottleneck moves.
A Strategy that made sense last month no longer operates the Limiting Movement.
New Tactics are added without the original reasoning.
A team member sees a task but cannot tell which growth problem it exists to solve.
Eventually the diagnosis becomes separated from execution.
Hacknator is built around keeping those relationships together.
Your business becomes a Growth Blueprint of states and Growth Movements.
The diagnosis identifies which Movement deserves attention.
Strategies operate those Movements.
Tactics execute the Strategies.
Tasks execute the Tactics.
And when evidence changes, the path back from execution to the original growth reasoning is still visible.
The objective is not to give you more growth ideas.
It is to make it harder to work on something without knowing why it should matter.
Start my diagnosis
A SaaS growth bottleneck is the part of the path to a specific business outcome that currently constrains that outcome more than the alternatives.
It is not automatically the metric with the worst percentage.
Not necessarily.
Largest drop-off is useful diagnostic evidence, but volume loss alone ignores user quality, expected conversion, downstream value, headroom and the specific business goal.
Use it to generate candidates, not to declare the diagnosis.
The bottleneck identifies where the system is constrained.
The root cause explains why that Movement is constrained.
For example, Signup β Activated User could be the Limiting Movement while low-fit acquisition is one of the causes.
Yes.
A downstream movement can reveal a problem created earlier in the path.
Poor activation, for example, can result from acquiring users whose intent does not match the product.
That is why segment and cohort analysis are critical.
Benchmarks can help identify unusual performance and generate hypotheses.
They should not determine the diagnosis alone.
Your own goal, historical performance, segments, unit economics and downstream leverage are more important to the final decision.
Keep the shortlist small enough to compare seriously.
The purpose of candidate generation is to eliminate weak explanations and concentrate investigation on the few Movements with the strongest evidence and leverage.
Treat the diagnosis as uncertain.
Compare plausible downstream impact, investigate the competing mechanisms and choose a tactic designed to generate evidence rather than committing to a large optimization program.
Reassess whenever the constraint changes materially, the target outcome changes, the path changes or the outcome fails to respond to the improvement you expected.
A growth constraint is a current property of the system, not a permanent label.
Hacknator
Create pages, reports and playbooks with a system designed to turn traffic into movement.
Join HacknatorRead more
More editorial notes, tactical breakdowns and operating perspectives from the Hacknator team.