The Moment
Yandex.Pictures, 2012-2014. I'm the product lead. Yandex's image-search product — closest US analog is Google Images, at Yandex scale, ~30 million monthly users in Russia. We shipped three full redesigns in two years. Two grew the metrics; one tanked them.
The redesign that tanked the dashboard wasn't sloppy. The team had run user research. We'd CustDeved the changes. We'd written hypotheses, predicted lift, picked the launch dates. The inbox after release filled within hours — angry users, lost habit, two literal death threats by Friday, support couldn't recover for days. We rolled back what we could and called the failure an execution problem. Then we picked the next feature off the backlog and started over.
I didn't notice at the time, but the model that was running my work for ten years was the same model that was breaking it. I thought we had a quality control problem — a feature that didn't test enough, a designer who pushed too hard, a stakeholder who overruled research. The pattern said something different. The pattern said: when you start from a feature, you have a one-in-three chance of destroying value, no matter how carefully you ship it. Ronny Kohavi's data at Microsoft — 1,000+ A/B-tested features, roughly one in three actively destroyed value the team was already delivering, one in three was neutral, one in three produced positive lift. The teams shipping those features were not lazy. They were running the standard product process.
I left Yandex and spent the next ten years consulting. Maybe a thousand product meetings across BookScripter, Yango, BioCAD, Plejada, ARTDENT, dozens of B2B SaaS teams in Moscow and abroad — same pattern in every room. A founder or stakeholder or VP arrives with a feature idea. The team CustDevs it. They write metrics. They invest a quarter. They ship. Three months later the metric hasn't moved and nobody quite knows why. The next meeting opens with someone else's feature idea. The cycle continues.
Somewhere along the way I started calling it what it was: the cursed cycle of feature-pushing. A closed loop in which the planning unit, the validation method, the love object, and the success measure all conspire to keep the team busy and the customer indifferent. The teams running the cycle aren't bad. They're working hard. They are running a value-destruction process at a high cadence.
The Wrong Model
Value is created by generating feature ideas. A stakeholder, a founder, or a VP has a brilliant idea. The team CustDevs it to validate. The team writes metrics. The team invests in building it. The team ships. If it doesn't land, the team ships another one. Enough cycles, enough features, and the right ones will compound. That's product.
This is the model running 99% of product teams I've watched from outside. It feels disciplined — there's research, there are metrics, there's a roadmap, there's a backlog. It produces visible motion. It generates artifacts that look like the work. And the brain rewards every cycle of it — there's a meeting, there's a sprint, there's a launch, there's a screenshot to post.
It's also, as a process, a slot machine.
The Insight
The defect isn't the team. The defect isn't the features. The defect is the planning unit is the feature. Once the feature becomes the unit, four failure modes lock in at once, and the cycle is impossible to win from inside.
The unit is wrong. A feature is a delivery format for value — never the value itself. Value, in this methodology, is greater energy efficiency for the brain in performing a Job — relative to its prediction. Less time, less cognitive load, less anxiety, fewer Jobs the customer has to perform, higher probability the Big Job lands at the segment's success criteria. None of that is in the feature itself; the feature is the thing through which it sometimes happens to land. Asking "is this feature valuable?" smuggles the conclusion in the noun. The customer's brain doesn't grade features. It grades the Job — did this Solution perform the Big Job better than the prediction said it would? When the answer is yes, you can call the feature valuable in retrospect. When the answer is no, the feature was a guess, and most guesses miss.
The starting point is wrong. When you start from one feature, you see one mechanic for one Job. The Next Move Theory canon names ~20 foundational value-creation mechanics — climb a level, kill a Job, perform more Jobs in one Solution, reduce time-gaps, eliminate a negative emotion, perform the previous Job in the chain, perform the next Job, guarantee the result, and on. A feature dropped in from a stakeholder meeting tests roughly one of those mechanics against one node in the Job Graph. The other 19 mechanics, applied to the other nodes in the Graph, never enter the room. The team congratulates itself on validating one of fifty possible hypotheses, ranked by which one a senior person happened to think of.
The dynamics are wrong. The moment a person becomes attached to a feature, identity activates. The feature stops being a hypothesis about value and becomes my feature. Criticism reads as personal attack. Contradicting research gets reinterpreted. Kill-the-feature conversations turn into "we need to message it better." Identity scales up the org chart — a VP commits in a public roadmap review; killing means walking back the commitment; the team ships it knowing it's wrong. The most common failure mode isn't "shipped despite the evidence" — it's "evidence never collected." A team in love runs the interview that would validate the feature, not the one that would kill it.
The goal is wrong. Every new feature is a bundle of risky assumptions. Seven independent assumptions at 60% survival each combine to ~3% survival for the feature as a whole. The highest-leverage move on a new feature is not to ship it — it is to remove a risky assumption from the set as cheaply as possible. Feature thinking inverts this. It treats the feature as valid by default and runs post-hoc validation. By then the budget is spent. The Next Move Theory response is "kill the product, don't launch it" — invert the polarity of validation so that every assumption is hunted for the cheapest test that would destroy it.
The four failure modes are different cuts of the same defect. The cycle runs on features and the customer's brain runs on Jobs — the units don't talk to each other, so every loop manufactures noise the team interprets as work.
"We come up with a feature, we CustDev it to check the value, on that basis we decide whether to ship — and that's normal."
— a senior PM in one of my workshops, naming the standard process the way every team I've ever met has naming it.
The honest reply is that the process he named is a value-destruction machine that the industry has agreed to call product management. The reason it survives is that one in three features happens to ship value anyway, the dopamine of shipping is reliable, and the teams running it are too busy shipping the next one to look up.
The alternative is structural and runs in the opposite direction. It starts not with a feature but with the focus segment's Job Graph. Build a hypothesis of the Graph for the segment's Big Jobs — Core Jobs we perform, Big Jobs above us, sibling Small Jobs, Micro Jobs below. Lay the catalog of ~20 mechanics on top and ask, against each node: which mechanic, applied here, could meaningfully raise the segment's energy efficiency on the criteria they actually use? A team doing this for the first time usually finds 30 to 50 candidate value hypotheses, not 1. Then research targeted at testing whether those specific mechanics could land — interviews, support-inbox reads, sales-call mining, expert conversations. Rank the survivors by (probability × reach × impact) / effort. Kill the bottom of the list before any of it gets built. Then invest in the top one or two.
The lift comes from two places at once. You're picking from fifty hypotheses ranked by structure, not validating one hypothesis born in a meeting. And the research is doing diagnostic work — can mechanic X land here? — instead of seeking confirmation for a decision already made. Hit rate doesn't double. It changes character.
Two examples of what value looks like when it's named from the Job side rather than the feature side, both from teams I worked with:
Stanfina is a clinic-finance product Pavel Lizinets built for dental clinics — closest US analog is a vertical-finance tool like Bench or Pilot, but for dental practices specifically. The first version of the product was sold as "an algorithm that helps clinics make correct financial decisions." Sat at the feature level — we have an algorithm. Stalled. The value, named from the Job side, was "you update the price list at target margin without suffering." Same product, the value statement now lives where the customer's brain lives — a Core Job they perform regularly, with a concrete success criterion (at target margin) and a removed negative emotion (without suffering). The product moved.
Finaudit is a financial-audit firm — same shape of business as a mid-sized US accounting firm doing tax and audit work. They differentiated on price and turnaround until somebody on the team noticed the Big Job above the audit Core Job: "don't lose money to fines and tax penalties." The new value statement: "the result of our audit is insured by a major carrier for up to $30M against tax-authority claims for three years." Same Core Job, new link to the Big Job, found by climbing one level in the Job Graph. The feature underneath (the insurance policy) is a delivery format for the value (you sleep at night). Stated as a feature it sells nothing. Stated as the Big-Job-level promise it sells.
Neither of these moves was reachable from inside the cursed cycle. Both became obvious the moment the team stopped asking "which feature should we ship?" and started asking "which Job, of which segment, on which criteria, through which mechanic, with which delivery format?"
The cursed cycle isn't a moral failing. It's the default the industry trained you in. The way out isn't more discipline inside the cycle. It's a different unit of planning.
Wes
Where it leads
The cursed cycle has a name now. What it doesn't have yet — and what no business school, no startup book, no Christensen chapter ever gave me — is an operational answer to "so what is value, really?" For twelve years of shipping product I genuinely did not know. The next chapter is the confession underneath this one, and the place the rest of Part V starts.