The Product Has Its Own Telos

If you build products, you’ve likely noticed this: nothing stays what you intended. You draw the architecture, define the interfaces, ship the MVP with a clear thesis. Then the product meets the market and becomes something else. Features accumulate in unexpected directions. Users develop rituals around affordances you considered minor. The codebase develops gravitational pulls that make some futures effortless and others prohibitively expensive.

Somewhere between the first commit and the thousandth, the product becomes itself.

Raising a child works the same way. You begin with a vision — values to instil, paths to open, dangers to guard against. You invest enormous energy in shaping conditions. Then they become themselves. Interests emerge that you never modelled. Resistance surfaces where your guidance seemed obvious. Growth happens in directions that surprise you, sometimes delight you, sometimes unsettle you. The child you raise rarely matches the child you imagined, and this reflects how living systems actually work.

Products follow this pattern. The product you launched differs from the product you have. The product you have differs from the product you planned. Between intention and actuality lies something more interesting than execution error or market drift: the product has developed a telos — an inherent direction, a becoming that belongs to it. Not to the founders. Not to the market. To itself.

The Greeks called this self-unfolding physis — the way a seed becomes a tree, following its own nature. They distinguished it from techne, making it according to plan. Software development has long assumed products are pure techne. But products contain physis too.

I. When the Product Speaks First

In 2016, Notion’s team faced a choice. Enterprise customers were requesting role-based permissions and audit logs — standard enterprise features, perfectly aligned with their growth roadmap. But something felt off.

The product kept pulling toward flexibility, toward letting users build their own structures. The enterprise features would impose rigid hierarchies that contradicted this pull. The team noticed something: users weren’t requesting permissions because they wanted control. They were requesting them because they couldn’t yet imagine a system fluid enough not to need them.

Most founders and lead engineers have lived through moments like this, though they rarely have language for it. You review usage data and see behaviour that makes no sense under your current model. Users cluster in a corner of the interface you considered secondary. They build workflows around a capability you added as an afterthought. They have found something in the product that you didn’t consciously put there, or that you put there without understanding what it was.

This is when the telos announces itself. The product speaks.

Most teams ignore it. They stick to the roadmap. They explain away the data. They treat the wrongness as a communication problem — if only they explained better, if only the feature was better designed, users would behave as intended. They keep steering the product toward their vision until something breaks: morale, the architecture, the market fit.

The alternative is learning to listen.

II. Three Kinds of Listening

If the product has its own direction, listening becomes central to engineering practice. Active attunement to what the product is trying to become, rather than passive reception of requirements. Three sources carry signals, and each requires a different ear.

Listening to the Vision

The founders’ vision is a signal — strong, coherent, often beautiful, but partial. It captures what the founders can imagine at the moment of founding. It cannot capture what the product will discover once it meets reality.

The skill is discernment: knowing which parts of the vision are structural and which are ornamental. Structural parts are the ones the product keeps returning to, the ones users adopt even when the implementation is clumsy, the ones that generate energy. Ornamental parts require constant explanation. Users tolerate them. They feel like work to maintain.

Founders who cannot make this distinction become tyrants, imposing ornamental features with the same force as structural ones. The product strains under the weight. Founders who make this distinction well become stewards. They hold the vision lightly enough to let the product reshape it, firmly enough to keep the product from dissolving into pure reactivity.

Listening to the Market

Market demand is noise. This doesn’t mean irrelevant — signal and noise both carry information. But market demand is a statistical aggregate of local optimisations. Each user wants their immediate pain solved. The aggregate is a cacophony, rarely a coherent will.

The skill here is filtering: learning which demands to amplify and which to attenuate. This requires understanding the product’s structural integrity. Some demands fit the product’s emerging character and strengthen it. Others fit the character of a different product entirely, and accepting them creates a kind of possession — the product becomes someone else.

Filtering is fidelity to the product’s telos. The market is a conversation partner, a source of signal about what the product might become. But conversation partners don’t dictate outcomes.

Reading the Signals in Daily Work

Listening to these three sources is a set of habits running underneath normal engineering work, not a quarterly exercise reserved for strategy retreats.

After shipping a major feature, the standard question is “Did it work?” A more revealing question is: what did the product reveal about itself? Did users adopt it in ways that suggest an unmet need deeper than the one you solved? Did it integrate cleanly or fight the architecture? Features are experiments in the product’s becoming. Treating them that way changes how you read the results.

Error spikes deserve the same attention. When error rates rise, the reflex is to fix. But first, map. Where do the errors cluster? What do they have in common? Error spikes often mean the product is being asked to do something against its own grain. Basecamp once saw consistent failures around a notification feature that let users customise alert timing per project. The code was sound — the problem was that users were building increasingly complex notification rules that ran against Basecamp’s core principle of calm, simple project management. Basecamp removed the feature. The decision was about character, not performance.

User interviews surface the same signals differently. Asking users what they want is often the least informative move, because users work from their current mental model and can only request extensions of it. More useful is watching what they do: the Zapier integration they built instead of using your API, the spreadsheet they export to every week, the workaround they invented around a limitation you considered minor. That behaviour is the product’s telos translated into action.

III. The Practice of Listening

Attunement is a practice, a set of habits that develop over time.

Post-mortems as diagnostics of character. After shipping a major feature, the standard question is “Did it work?” A more revealing question: “What did the product reveal about itself?” Did users adopt it in ways that suggest an unmet need? Did it integrate cleanly or fight the existing architecture? Did it generate energy in the team or drain it? These questions treat the feature as an experiment in the product’s becoming.

Error spikes as structural stress. When error rates rise, the reflex is to fix. But first, map. Where do the errors cluster? What do they have in common? Error spikes often indicate the product being asked to do something against its nature — a feature that conflicts with the core architecture, a user flow that contradicts the dominant mental model. The bugs are symptoms. The underlying condition is telos conflict.

User interviews for affordance discovery. The standard approach asks users what they want. But users often cannot articulate this. A more useful approach: observe what they do. The Zapier integration they built instead of using your API. The spreadsheet they export to every week. The workaround they invented for a limitation you considered minor. These aren’t complaints. They’re messages from the product’s telos, translated into user behaviour.

Retrospectives as pattern recognition. The standard retrospective asks “What went wrong and how do we fix it?” A more strategic question: “What problems did we solve, what problems did we create, and are we satisfied with that exchange?” This shifts energy from blame and repair toward strategic choice. Over time, teams develop taste — for solutions, yes, but also for the quality of problems they’re willing to live with.

IV. When the Product and the Business Disagree

The override path. Sometimes you must override the product. You take the funding round, you ship the feature the enterprise client demands, you pivot to the adjacent market that pays the bills. Products don’t exist in vacuums. Survival enables becoming.

Override with awareness, though. Every forced feature generates technical debt that shapes future possibility. Every pivot requires unlearning that costs morale and expertise. Document the override. Return to the product’s telos when conditions permit. The danger is letting the temporary become permanent through inertia.

In 2010, Instagram was called Burbn — a location check-in app with game mechanics that wasn’t finding its footing. The founders looked at the data and saw that people used one feature: photo sharing with filters. Following that signal meant abandoning the original vision, confusing existing users, and making a difficult admission to investors. They did it anyway, and Burbn gave way to Instagram.

The trust path. Sometimes you must hold course and accept the risk. The market doesn’t yet understand what the product is becoming. Investors want a category you don’t fit. The team is restless because they sense the divergence. The founders who listen through that uncertainty and hold their line often build the most distinctive products.

Figma launched in 2016 as a browser-based design tool into a market that ran entirely on native desktop apps — Sketch, Adobe, all of it. The professional consensus was that browsers were too slow, cloud storage was untrustworthy, offline mode was non-negotiable. Figma’s direction required real-time sync, which required the web, so they stayed with it through years of slow growth. When remote collaboration became essential, Figma was already built for it. The telos was ahead of the market, and patience was the work.

The synthesis path. Sometimes you find a way to honour both. When Slack users requested project management features, the product faced a genuine tension: absorbing those features would have changed what Slack was, but the underlying need — coordinating work — was real. Slack became a platform instead, letting project management tools integrate around it. The synthesis held both the user’s need and the product’s nature.

The art is knowing which moment is which. There is no algorithm. Only judgement, accumulated through experience.

V. The Ethics of Cultivation

A product’s telos can run in a direction that consumes its host — users, employees, society — optimising for growth or attention or monetisation until the system it depends on degrades. That is a direction, and it has its own coherence. It just tends to be self-terminating.

The deeper possibility is a telos that creates value for all participants in the system: feedback loops that reward healthy behaviour, architectures that don’t scale through exploitation, business models that align company success with user flourishing. Getting there requires deliberate choices early, before the architecture has calcified.

The technical decisions made in year one — the data collected, the relationships modelled, the incentives encoded — become the moral structure of year five. Wikipedia’s founders understood this. The architecture made editing easy and reverting equally easy. Edit history was permanent and public. The infrastructure was built to be replicated and forked. None of these were neutral technical choices; they were ethical commitments written into the material, and they made Wikipedia’s collaborative, non-commercial character sustainable at scale. A proprietary, opaque, irreversible architecture would have made a different character inevitable, regardless of the stated mission.

The question worth asking, before building, is not whether something can be built, but what kind of product will emerge from building it this way — and what that product will want to do once it has users, momentum, and a character of its own.

VI. The Humility of Cultivation

We need a better metaphor for what we do. Construction assumes passive matter and sovereign plans. Science assumes we stand apart from the system we study. Both have limits when applied to products.

The metaphor we need is cultivation. The gardener doesn’t build the tree. The gardener creates conditions — soil, water, light, space — and the tree becomes itself. The gardener must know the tree’s nature. Some trees want sun; some want shade. Some want to spread; some want to climb. The gardener who tries to force all trees into one form loses most of them.

But the gardener isn’t passive. They prune. They trellis. They protect from pests. They make judgements about what serves the plant’s flourishing and what harms it. They work with the tree’s nature, not as mere spectators.

This is product engineering. We cultivate systems that are becoming themselves. We cannot know in advance what they will become. We can know whether the becoming is healthy — whether the system is developing coherence, resilience, the capacity for further growth.

And we accept the humility of it. The product will outlast our tenure, our understanding, perhaps our company. It will become things we never imagined. Users will use it in ways that surprise us. The code we wrote in a late-night sprint, barely remembered, will become a load-bearing structure for features we never conceived.

The product has its own telos. Our work is recognising it, respecting it, and helping it become what it is trying to be — something that, if we are skilled and fortunate and good, might turn out to be worth the becoming.