Product strategy
A good objective can still be built on a weak explanation.
One product objective from the FlowDesk demo workspace, followed from the first assumption through evidence, experiments, delivery and the final result.
For months, the team had treated onboarding as the cause of churn without evidence.
Step 01 · July
The explanation came from one comment in a March meeting.
FlowDesk sells shift-scheduling software to mid-sized logistics operators. It has 400 customers, mostly in the Benelux, all signed within the last three years.
The VP of Product opened Q4 planning with a problem the team had been watching since spring: 22% of new accounts were gone within 90 days.
The team set a clear objective: reduce early churn. They also wrote down what everyone already believed was causing it: onboarding was too difficult, so onboarding needed to be improved.
Shorter Loop marked the explanation as assumed because no evidence was attached. The team then had to answer a specific question: what showed that onboarding was where these accounts were being lost?
The only source they could find was a comment from a sales engineer in a March meeting. It had been repeated often enough that the team had stopped questioning it.
The ASSUMED badge tells anyone looking at the objective that this claim still needs evidence.
Steps 02–03 · two weeks
Putting the evidence together changed the team's explanation.
FlowDesk already had the information it needed: support conversations, sales notes, churn interviews and customer usage data.
Reviewing the sources together showed that customers who churned had usually completed onboarding. They imported their rosters, published a first schedule, and then stopped.
The strongest difference was whether a second person used the product during the first week. The person who mattered was often the dispatcher, even though the contract had been signed by the operations manager.
The team kept the churn objective and changed its working explanation: early churn appeared to be linked to whether a second user adopted the product.
Step 04
Each solution rested on a different assumption.
Writing those assumptions down gave the team something they could test.
The CEO preferred a done-for-you import service, with someone from FlowDesk helping each new customer set up the product. It was the most expensive option, and the one with the strongest executive support.
A support engineer suggested something much simpler: let customers share a schedule through a link that did not require an account.
Each option rested on a different belief about the cause of churn. The team could test one of those beliefs quickly and cheaply.
Done-for-you import service
Assumes the blocker is effort.
Invitation prompts inside onboarding
Assumes the ops manager knows who to invite.
Shared schedule link, no account needed
Assumes dispatchers want the schedule and the account wall keeps them out.
Step 05
The team wrote down what would count as failure before running the test
That made the result useful: the team had already decided what evidence would cause them to abandon the idea.
The import-service idea remained visible as a parked option, together with its still-unproven assumption and the evidence attached to it.
When the CEO asked about it again in November, the team could see immediately why it had not been pursued. Nobody had to reconstruct the decision from memory.
Written before the test · falsifiable
If fewer than half the accounts share the link within a week, the assumption is wrong and the solution dies.
Step 06 · six weeks
Engineering kept delivery status in its existing tracker, while Shorter Loop kept the work connected to the evidence and objective.
The integration avoided duplicate status updates and kept engineering work in the system the team already used.
The validated solution became an epic and then four features. Delivery status stayed in the tracker the engineering team already used. In Shorter Loop, that work remained linked to the opportunity, the objective, the 41 pieces of evidence and the experiment result.
The release shipped on 14 November. At that point, the team still did not know whether it had reduced churn, so the objective remained under assessment.
NINETY DAYS LATER
22% → 15%
The target was 12%, so the objective remained open.
Seven points, attributable
The same cohort analysis that found the pattern showed which accounts gained a second user and what happened to those accounts afterwards.
Three points, still open
The remaining three percentage points became the next question to investigate.
January
For the board review, the VP of Product could open the objective and show the complete chain: the original assumption, the evidence that changed it, the options considered, the experiment, the work that shipped and the resulting change in churn.
Before you worry about the whole tree
FlowDesk's rollout began with one objective.
The rollout began with one important objective and one question about its cause. The team added more structure only when the work required it.
One objective, marked assumed
Start with one important objective. If the explanation behind it is not supported yet, mark it as an assumption.
One opportunity, evidenced
Bring in the evidence you already have. For many teams, this is where the original explanation of the problem starts to change.
The rest of the portfolio
Expand to more teams and objectives when the first chain is useful. You do not need to model the whole organisation before you can start.
The reasoning was already there when the board asked for it.
The VP of Product could show the objective, the original assumption, the evidence that changed it, the alternatives considered, the experiment, the work that shipped and the metric that moved — without rebuilding the story in a presentation.
Fair questions
What people ask before they commit a team
- We already have OKRs. Does this replace them?
No. Keep your existing objectives and key results. Shorter Loop adds the evidence, assumptions, opportunities, options and experiments that explain how you expect to achieve them.
- Do we need all the levels?
No. Use only the levels you need. The FlowDesk example starts with one objective, one opportunity and one experiment. Add more structure only when the decision requires it.
- Will my PMs actually maintain it?
Only if it is useful for planning. Delivery status should remain in the tools your teams already use. Shorter Loop is intended to hold the reasoning behind the work, not become another place to copy status updates.
- Do engineers have to move tools?
No. Engineering continues to use its existing tracker. Shorter Loop links that work to the product reasoning behind it.
- What happens when an objective doesn't close?
It stays open. In the FlowDesk example, churn improved from 22% to 15%, but the target was 12%. The team could explain seven percentage points of improvement and treat the remaining three as the next question to investigate.
- How long before we see anything?
It depends on how quickly you can connect the evidence you already have. For a ten-person team, that has typically taken about five days. The first useful result is often finding that an assumption the team has been planning around is not supported by the evidence.
Start with one objective you are already working on.
Bring the evidence you already have. Shorter Loop helps you connect it to the objective, distinguish evidence from assumptions, and see what needs to be tested next.
FlowDesk is the Shorter Loop demo workspace. You can open it to inspect the example used throughout this page.