A validated insight derived from an experiment, user research, or real-world observation. Learnings capture what the team now knows to be true.
A learning is a validated change in what the team believes to be true, earned by testing a belief against reality. Shipping featuresFeatureProduct SpecificationA product capability or featureView reference → feels like progress and burns real money, yet a team can ship for a year and learn nothing about whether anyone wants what it builds. The point of treating learning as a first-class object is to measure progress by what the team now knows for certain, not by what it has produced.
Eric Ries named the idea validated learning in The Lean Startup (2011), defining it as the unit of progress for a startup: a rigorous way to show advancement under extreme uncertainty. His argument was that the usual signals of progress, lines of code or features delivered, can all be motion with no forward movement if the underlying assumptionsAssumptionStrategyA belief taken as true that underpins a strategyView reference → are wrong. Learning becomes valid when a belief about customers or the market has been confirmed or refuted by their actual behaviour.
The engine for producing it is the build-measure-learn loop: build the smallest thing that tests a belief, measure how real users respond, and learn whether the belief holds. Ries pressed teams to shrink batch size so they could complete the loop faster than competitorsCompetitorMarket IntelligenceA competing product or companyView reference →, because the rate of validated learning, not the rate of output, is what compounds. The loop runs in reverse when planned: you decide what you needNeedUserA user need, pain, desire, or constraintView reference → to learn, work back to the metricsMetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → that would show it, then build only enough to generate those metrics.
The idea drew fair criticism. Lean methods can bias teams toward learnings that are easy to measure, nudging product work into a string of small optimisations while the larger bet goes untested. The mature reading treats validated learning as a discipline for retiring riskRiskComplianceA risk to the product or businessView reference → in order of severity, spending the cheapest possible experimentExperimentValidationA test designed to validate a hypothesisView reference → on the assumption that would hurt most if wrong.
A team believes that solo consultants will pay for an automated invoiceInvoiceSales & RevenueAn invoice for billingView reference → chaser. Rather than build the integration, which is several weeks of work, they run a smaller test: a landing page describing the feature, a price, and a waitlist button, driven by a modest ad spend. Of 600 visitors, 9 join the waitlist and 2 reply offering to pay immediately. The learning is not "the feature failed." It is specific: at this price and this message, demand among cold traffic is weak, but the two who replied unprompted both manage more than thirty clients, which points at a narrower, higher-intent segment. That learning updates the original belief and redirects the next experiment, all before a line of integration code is written.
In the Unified Product Graph, a learning sits in the Validation region as the output of disciplined testing. It enters through Experiment RunproducesLearningcausal, which binds every learning to the specific run that earned it, so no claim floats free of its evidenceEvidenceValidationData supporting or refuting a hypothesisView reference →. It then closes the loop through experiment_run_produces_learningLearningupdatesHypothesiscausal, recording how a prior belief moved. A learning can also arrive from the market through learning_updates_hypothesisCompetitoryieldsLearningcross-domain, capturing what a rival's move taught the team without a formal experiment. When a learning confirms that a bet is worth making, competitor_yields_learningLearningvalidatesOpportunitycross-domain connects it to the chosen opportunityOpportunityDiscoveryA validated gap worth solvingView reference →, so the roadmapRoadmapProduct SpecificationA strategic plan of features and milestonesView reference → can show which bets rest on tested belief and which still rest on assumption.learning_validates_opportunity
Type-specific fields on BaseNode
resultstringSummary
result_valuenumberMeasured value of the result
result_unitstringUnit (e.g. "%" or "ms")
result_directionstringDirection relative to the parent hypothesis. Canonical direction axis. BREAKING in v0.4.0: legacy `'positive'`, `'negative'`, `'neutral'` are replaced by `'supports'`, `'refutes'`, `'neutral'` to align with `Evidence.direction` and `HypothesisEvidence.direction`. Migration: `positive → supports`, `negative → refutes`, `neutral → neutral`.
confidence_impactstringConfidence impact on the parent hypothesis
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
13 edge types connected to this entity.
experiment_produces_learningexperiment_run_produces_learninglearning_updates_hypothesiscompetitor_yields_learninglearning_validates_opportunitylearning_validates_solutionlearning_refines_hypothesislearning_validates_needlearning_validates_joblearning_informs_featurelearning_observed_on_metricevidence_interpreted_as_learninglearning_informs_decision3 frameworks use this entity type.