💜 The 23 Minutes That Never Were: On Asynchronous Communication, the Productivity Myth, and What Research Actually Shows (by Łukasz Domagała)
💜 Dear UX Designer, the Tool is not the Thought (guest article by Michał Kosecki)
💪 Interesting opportunities to work in product management
🍪 Product Bites - small portions of product knowledge
🔥 MLA week#54
Join Premium to get access to all content.
It will take you almost an hour to read this issue. Lots of content (or meat)! (For vegans - lots of tofu!).
Grab a notebook 📰 and your favorite beverage 🍵☕.
Prompt engineering. Context engineering. Agent harnessing. The whole lineage is one word in a new costume — control. And the thing it’s chasing needs the control to switch off.
There’s a new craze in product and AI, and it’s called agent harnessing.
Before that it was context engineering. Before that, prompt engineering. Somewhere in the middle, vibe coding had its summer. Different words, same project: grip the machine harder, get the output faster, squeeze more from every hour. Tighter control, better results. That’s the whole promise of the genre.
I should be the patron saint of it. I’m High D — I run toward control the way other people run from it. I use AI more hours of the day than I’d put in writing. And for years I tried to strap my own brain into a schedule: time blocks, daily targets, the entire productivity catalogue, convinced the problem was my discipline. So I’m not writing this from a hammock. I’m writing it from inside the harness, where I live.
Here’s the part nobody selling the harness wants to hear.
The thing all that control is for — the good idea, the new angle, the breakthrough that makes the work worth doing — runs on a system you cannot grip. You can’t optimise your way to an insight. The harder you squeeze, the more reliably you strangle the exact machinery that makes the thing you’re squeezing for.
Start with flow, because it’s the most misunderstood word in this entire conversation.
Flow is not drifting. It’s the opposite of drifting. The psychologist who named it, Csikszentmihalyi, described total absorption — focus so complete the self disappears and time stops behaving. So far this sounds like the optimiser’s dream: maximum concentration, maximum output. But then Arne Dietrich went looking for what flow actually does inside the head, and he found something switching off. Not on. Off.
The prefrontal cortex — the part that plans, judges, monitors, second-guesses, the inner manager that narrates your performance while you’re trying to perform — quiets down. He called it transient hypofrontality. It’s a theory, not gospel, and worth holding as one. But the picture keeps surviving contact with the scanner. Put six jazz pianists in an fMRI machine and tell them to improvise, and the self-monitoring regions go dark. The musician stops managing and starts playing. The slow, explicit, supervising system steps out, and the fast, automatic one takes the wheel. That’s why flow feels effortless. The effort was the manager, and the manager left the room.
So even flow — the most focused state we have — runs on the controller standing down.
The other state is the one people mean when they say their best thinking happens in the shower. And it isn’t flow at all. It’s the opposite of focus.
When you stop working a problem — when you walk, shower, stare at the ceiling, nap through a heatwave — a different network comes online. The default mode network. For a long time we called it the brain’s idle state, which is precisely backwards. It is not idle. It’s the brain’s great connector: the thing that reaches across everything you know and starts wiring distant, unrelated ideas to each other while you’re not looking. This is where incubation lives. It’s why the answer arrives in the bath and never at the desk. Archimedes wasn’t at the office.
And it isn’t woo. Disrupt that network directly — and researchers have now done exactly that, with electrodes inside the brain — and originality drops while the rest of thinking carries on untouched. The connector goes down, the new ideas stop, and the competent-but-obvious ones keep right on coming. Which, if you think about it, is a perfect description of a very productive day in which nothing interesting happens.
There’s one detail I can’t stop turning over. In the lab you can see an insight coming roughly a second and a half before the person knows they have it — a burst of alpha activity, the brain briefly damping its own visual input, almost looking away from the problem, right before the answer surfaces. The “aha” is preceded by a blink. The mind glances away, and that’s the moment it finds the thing.
So here is the shape of it. Both of the states that actually produce something — flow and insight — require the manager to step back. The planner. The monitor. The optimiser. The exact faculty that every productivity craze of the last three years has trained you to crank to maximum.
Now look at what the lineage is actually teaching, in order.
Prompt engineering: control the input. Context engineering: control the surrounding information. Agent harnessing: control the machine’s entire loop. The word gives the whole game away. A harness is tack. It’s what you strap onto a draft animal so it pulls in the direction you’ve chosen and can’t wander off. We’ve gone from talking to the machine to putting it in a harness — and we ran the same cable straight back to our own heads.
The carousel promising the seven-layer prompt architecture. The guy who rebuilt his entire context stack over the weekend and live-tweeted each layer. The dashboard tracking personal cognitive throughput by the hour, so no minute escapes unaccounted for. All of it aimed at one outcome: never let a moment go unmanaged.
Congratulations. You’ve optimised the daydream out of your day. The last room without a screen was the shower, and somebody’s already selling you a waterproof notepad for it.
It was never only about the machine.
The same grip shows up everywhere a person who optimises can get her hands. Managing the AI. Managing the team — every variable accounted for, every interaction quietly steered. Managing yourself — the schedule, the streak, the metrics on your own behaviour, the running internal audit of whether this hour was used well.
And it is exhausting in a way that never lands on any dashboard, because the cost of running the controller is paid in the one resource the controller cannot see. You can be the hypervigilant manager of everything, or you can be the loose, drifting, wired-across-everything mind that makes the connections — but you cannot be both at once. The brain doesn’t run both networks at the same time. You’re choosing, every hour, whether you notice it or not. And the optimiser always votes for more control, because control is the only move it has.
That’s the trap. The faculty most proud of itself is the one quietly costing you the most.
Which brings me to the heat.
It’s the kind of week where the air refuses to move and the brain refuses to cooperate. Where the to-do list reads like a joke written by someone who has never been this warm. The optimiser hates it. Nothing is efficient. Everything is slow and sticky and three steps behind.
Good. Use it.
Let the heat be the excuse you’d never otherwise give yourself. You were going to lose the productivity anyway — so lose it on purpose. Don’t fill the slowness with a podcast and a protein target. Leave it empty. Drift. Stare at the wall. Let the connector do the one thing it can only do when you stop standing over it with a clipboard.
Po prostu bądź.
Just be. Exist. For an afternoon, be a body in the heat instead of a process to be improved.
Stop controlling everything. Yourself. The people around you. The machine. Not because control is evil — I haven’t found god in a hammock and I’m not going to pretend otherwise — but because it’s counterproductive, and the part of you most proud of the grip is the part charging the highest rent.
Loosen the harness. On the agent. On your team. On your own head.
Do small fuckup. Let go.
There’s a conference happening 270 kilometers from my desk in September, and most of the product people I know in Poland still book flights to London or Lisbon to see the same speakers. I want to fix that.
WaysConf is in Kraków on 16–17 September, with a separate workshop day on the 15th. Marty Cagan and Brad Frost are keynoting. Debbie Levitt and Petra Wille are running workshops. Then it goes deep on working practitioners rather than circuit speakers — staff designers from Meta and Shopify, research leadership from Wise, a Principal AI Designer from Intercom, product leaders from Kraken and IKEA.
Here’s my one piece of unsolicited advice, and it’s the contrarian one: do not build your two days around the keynotes. You can watch Cagan on YouTube tonight, in your pajamas, for free. What you cannot get on YouTube is the case study about what actually broke, the roundtable where people who run research orgs argue about maturity, or the speaker who contradicts the one you heard ninety minutes earlier. Conferences that only platform one worldview are just expensive newsletters read aloud. WaysConf isn’t that. The speakers counter-argue each other, and that’s the point.
The theme this year is “Building What Matters” — good decisions under real constraints, in an AI-accelerated, ship-faster world. I spend most of my time on the gap between what the AI-product discourse claims is happening to teams and what is actually happening to teams. A room full of practitioners presenting real case studies, in our region, is exactly where that gap gets argued out by people living it rather than people monetizing the narrative about it.
And the unglamorous part: if you run a small studio or sit on a Polish team budget, a Kraków train ticket and a conference pass is a different financial event than flying a team to San Francisco. Same caliber of speaker, fraction of the friction. The room is people you’ll keep running into for the rest of your career, mostly within a few hours of where you already work.
So go. Block the 16th and 17th, decide whether the workshop day is worth the extra ticket, and spend your time in the case-study rooms and the hallway — not the front row of every keynote.
The keynotes will be on the internet by October. The conversations won’t.
WaysConf 2026 · 16–17 September (workshops 15 Sept) · EXPO Kraków + online · waysconf.com
Web Summer Camp 2025 — and Alex will be there
Web Summer Camp is a three-day, hands-on event for Europe’s web professionals — workshops, small group sessions, and real conversations, taking place July 3–5 in Opatija, Croatia. Not the kind of conference where you collect slides and forget about it by Monday. The kind where you actually work through problems with people who build digital products for a living.
This year they added an AI track — not because everyone else is doing it, but because they wanted to do it right. There’s also a dedicated Founders program and tracks for JavaScript, PHP, UX, and product.
Alex will be joining as a speaker. If you’re heading to Opatija this summer — or considering it — this is where to find her in person.
More about the conference: [LINK]
Ready to grab a ticket? [TICKETS]
Do you need support with recruitment, career change, or building your career? Schedule a free coffee chat to talk things over :)
Junior Product Manager - Ten Square Games
Digital Product Manager - Luxmed
Digital Product Manager - Luxmed
Product Manager - IBM
Product Lead - Orange Polska
King Solomon was legendary for his wisdom. He resolved impossible disputes, navigated complex moral dilemmas, and gave counsel that people traveled from distant lands to receive. He was also, by most accounts, spectacularly poor at managing his own life. He accumulated hundreds of wives and concubines despite his own warnings about the dangers of such arrangements, made political alliances he advised others against, and let his personal relationships create the very instabilities he counseled neighboring rulers to avoid.
Igor Grossmann, a psychological scientist at the University of Waterloo, named a cognitive phenomenon after him. Solomon’s Paradox describes the robust asymmetry between how wisely people reason about other people’s problems versus their own — and the specific mechanism that produces it. For product teams, the paradox is not a curiosity about ancient kings. It is a description of a daily failure mode that shapes roadmap decisions, competitive assessments, and organizational self-awareness in ways most teams never examine.
A PM at a SaaS company listens to a competitor’s product announcement and immediately sees the strategic error. The competitor is chasing enterprise too early, before their SMB base is stable. The feature they’re announcing is expensive to build and serves a segment that won’t generate meaningful revenue for three years. The PM discusses this confidently with their team. The analysis is lucid, balanced, and probably correct.
Six months later, the same PM’s team is in a planning session discussing a feature to serve their largest enterprise prospect. The feature is expensive to build and serves a segment that won’t generate meaningful revenue for three years. Nobody in the room makes the connection. The PM who saw the competitor’s error clearly cannot see the same pattern in their own team’s decision.
This is Solomon’s Paradox. The reasoning was the same quality of reasoning. The subject was different. And the difference in subject produced a difference in quality that the PM experienced as a difference in clarity.
Solomon’s Paradox describes the asymmetry by which people reason more wisely about other people’s problems than about their own — recognizing the limits of their knowledge, considering multiple perspectives, and acknowledging uncertainty more readily when the problem belongs to someone else.
The phenomenon was formally identified and named by Igor Grossmann and Ethan Kross in a 2014 paper in Psychological Science, titled “Exploring Solomon’s Paradox: Self-Distancing Eliminates the Self-Other Asymmetry in Wise Reasoning About Close Relationships.” Their experiments involved 693 participants reasoning about relationship conflicts — some their own, some belonging to a friend. Across multiple studies, participants displayed systematically wiser reasoning when the problem belonged to someone else: they were more likely to acknowledge the limits of their knowledge, more likely to consider multiple perspectives, more likely to recognize the possibility of future change, and more likely to see room for compromise.
The mechanism Grossmann and Kross identified was psychological distance. When reasoning about another person’s problem, people naturally adopt a more distanced perspective — what they called the third-person view — which activates more deliberate, less emotionally reactive processing. When reasoning about their own problems, people self-immerse — adopting the first-person view, which is emotionally hot and cognitively narrow. The third-person view accesses more balanced reasoning. The first-person view accesses more motivated reasoning.
Critically, the researchers found that the asymmetry could be eliminated. When participants were instructed to self-distance — to reason about their own problem as if they were observing it from the outside, or as if it were happening to someone else — their wise reasoning about their own problems became indistinguishable from their wise reasoning about others’. The paradox is not fixed. It is a product of a perspective that can be shifted.
The core mechanism of Solomon’s Paradox is a difference in the cognitive processing mode activated by different perspectives. First-person reasoning about personal problems tends to be what psychologists call experiential or self-immersed: emotionally engaged, focused on the specific details of the immediate situation, and driven by motivated reasoning — the tendency to reach conclusions that protect the self, justify prior decisions, and preserve existing commitments. Third-person reasoning tends to be more distanced, more abstract, and more capable of holding multiple interpretations simultaneously.
The difference is not a difference in intelligence or analytical capacity. The same person who reasons poorly about their own strategic situation can reason excellently about an equivalent situation faced by a competitor or colleague. The capacity is there. The perspective is not.
Underlying the first-person processing mode is motivated reasoning: the tendency to reason toward conclusions that protect existing commitments, prior decisions, and self-concept. In product organizations, motivated reasoning operates systematically in favor of the current roadmap, the current strategy, and the current team’s past choices. Evidence that challenges these commitments is processed differently from evidence that supports them — less charitably, more skeptically, with a higher evidentiary bar.
This asymmetry is not primarily conscious. The PM reviewing a competitor’s strategy does not choose to be more objective. They are more objective because they have no stake in the competitor’s success. The PM reviewing their own team’s strategy is less objective not because they are biased in a conscious sense but because the emotional and professional stakes of the evaluation activate a different processing mode that is systematically less balanced.
Solomon’s Paradox has a particularly acute form in expert organizations. Teams with deep expertise in their product, their market, and their users have accumulated significant knowledge and experience that is genuine and valuable. They also have significant accumulated commitment — to their analysis, their past decisions, and their mental model of how their product and market work. The same expertise that produces accurate pattern recognition also produces motivated resistance to disconfirming information.
This is why external observers — consultants, advisors, new hires in their first few weeks — often see problems with clarity that the expert team cannot access. The clarity is not a product of superior expertise. It is a product of the third-person perspective that comes with low stakes and no prior commitment. The insight is real. The perspective is temporary. And most organizations do not build structures that preserve the distanced view once the observer becomes embedded.
Netflix’s culture of competitive analysis illustrates the paradox in a context where its effects are most visible. Reed Hastings and product leadership have been extensively documented discussing competitors’ strategic errors with analytical clarity in the same periods when their own strategic decisions were later revealed to have the same structural flaws. Netflix’s response to the DVD-to-streaming transition — which they eventually executed well — was preceded by a period in which the same leadership team that could clearly see incumbents’ reluctance to cannibalize their core business was exhibiting equivalent reluctance to cannibalize their own DVD business. The asymmetry was not a product of poor analysis. It was a product of the perspective from which the analysis was conducted.
Amazon’s writing culture serves, among other functions, as a partial antidote to Solomon’s Paradox. The requirement to write a press release and FAQ before building anything forces teams to articulate their product’s logic from the perspective of an external user who has never heard of the product and has no stake in its success. This perspective shift is a deliberate form of self-distancing: the team is being asked to reason about their own product as if it were someone else’s. The exercise does not eliminate motivated reasoning, but it creates a structured moment of third-person evaluation that the default planning process — which is entirely internal and first-person — does not provide.
The product retrospective format used by teams at companies including Spotify and Atlassian explicitly tries to create psychological distance from recent decisions by asking teams to evaluate past choices from a distanced frame: “What would we think of this decision if we had seen another team make it?” The question is designed to activate the third-person processing mode for first-person decisions. Teams that use it consistently report that it surfaces insights about their own decision quality that the standard retrospective format — which reviews decisions from the first-person perspective of the people who made them — does not.
Solomon’s Paradox matters for product teams because it describes a systematic asymmetry in the quality of reasoning that is entirely invisible to the people experiencing it. The PM who sees a competitor’s error clearly does not feel less analytical when reviewing their own team’s strategy. The motivated reasoning that drives the asymmetry produces confident conclusions that feel just as grounded as the distanced analysis of the competitor’s situation.
This invisibility makes the paradox particularly insidious in product organizations. Teams that believe they are applying rigorous analysis to their own strategy are often applying motivated analysis — analysis that is sophisticated in form but oriented toward validating existing commitments rather than genuinely evaluating them. The rigor is real. The objectivity is not.
The research implications are direct. Grossmann and Kross’s finding that self-distancing eliminates the paradox means that the asymmetry is not fixed. It is a product of a perspective that can be intentionally shifted. Product teams that build deliberate distancing practices into their planning and review processes can access the quality of reasoning that they routinely apply to competitors, and apply it to themselves.
Apply the competitor frame to your own decisions. When evaluating a significant product decision, ask explicitly: if a competitor were making this decision, what would we say about it? The exercise activates the third-person processing mode for a first-person decision. The resulting analysis is often more balanced, more aware of its own limitations, and more capable of identifying the ways the decision could fail than the standard internal evaluation. The answer to the competitor-frame question should be compared directly with the conclusions of the internal evaluation. Significant divergences deserve examination.
Use external advisors at moments of high commitment. Solomon’s Paradox is most acute when emotional and professional stakes are highest — when the team has already invested significantly in a direction, when a major decision has already been made, or when the strategy is closely identified with specific individuals. These are exactly the moments when external perspectives — from advisors, from peers at other companies, from recently hired team members who have not yet accumulated commitment — are most valuable. The external perspective is not more expert. It is more distanced. The distance is the value.
Build third-person frames into retrospectives. Standard retrospective formats ask teams to evaluate their own decisions from the first-person perspective of the people who made them. Adding a structured third-person frame — “what would we think if another team had made this choice?” — activates a qualitatively different processing mode. The exercise is brief. The shift in perspective it produces is meaningful.
Create a structured “outside view” process for major strategic decisions. Before committing to a significant strategic direction, deliberately construct the case against it from the perspective of an informed external observer. This is not devil’s advocacy — it is an attempt to reason about the decision as if it belonged to someone else. The exercise surfaces the considerations that motivated reasoning suppresses and provides a more balanced foundation for the final decision.
Grossmann and Kross’s research produced a finding that is both humbling and practical. The wise reasoning that people display when advising others is not a different capacity from the reasoning they apply to their own problems. It is the same capacity, expressed through a different perspective. The gap between the quality of advice people give and the quality of decisions they make about their own lives is not a gap in wisdom. It is a gap in distance.
For product teams, the practical translation is precise. The team that sees competitors’ errors clearly is not more capable of clear analysis than the team that cannot see its own errors. They are the same team, looking at different subjects. The analytical capacity that produces the competitor assessment is available for the self-assessment. It requires a deliberate shift in perspective to access it.
Solomon was wise. He was wise for other people. Building structures that apply the same quality of reasoning to your own decisions that you naturally apply to others’ is not a philosophical exercise. It is a practical intervention that improves the quality of the decisions that matter most — the ones you are already committed to making.
Reason about your own product the way you reason about your competitor’s. The analysis you apply to them is available to you. It just requires seeing yourself from the outside.
Two engineering teams each spend a month improving their product’s loading time. The first team reduces load time from 10 seconds to 9 seconds — a one-second improvement, roughly 10 percent faster. The second team reduces load time from 2 seconds to 1 second — also a one-second improvement, a full 50 percent faster. Leadership praises both teams equally for delivering a one-second improvement.
Users do not respond equally. The second improvement is experienced as dramatic — a transformation of how the product feels. The first is nearly imperceptible. The engineering effort was identical. The objective improvement was identical. The user experience was not.
This asymmetry is not random, and it is not noise. It follows a law that has been known since the 19th century and applies to nearly every dimension of human perception. Understanding it changes how product teams prioritize performance work, communicate improvement, and set thresholds for changes that users will actually notice.
In the 1830s, German physiologist Ernst Heinrich Weber was studying how people detect differences between stimuli — weights, lengths, sounds, light intensities. He made a discovery that seemed paradoxical: the smallest difference a person could reliably detect between two stimuli was not a fixed amount. It was a fixed proportion of the original stimulus. If you could just barely tell the difference between a 100-gram weight and a 102-gram weight, you could just barely tell the difference between a 200-gram weight and a 204-gram weight. The threshold was always approximately 2 percent of the base stimulus, regardless of the base.
Decades later, physicist and philosopher Gustav Fechner extended this finding into a mathematical relationship. If the threshold for detection is proportional, then perception itself must be logarithmic: equal steps in perceived intensity correspond to exponential steps in actual intensity. Fechner’s law states that perceived sensation is proportional to the logarithm of the physical stimulus. The relationship has since been called the Weber-Fechner Law, and its implications reach from psychophysics into economics, audio engineering, visual design, and product management.
The Weber-Fechner Law describes the relationship between the physical magnitude of a stimulus and its perceived intensity: perceived sensation increases proportionally with the logarithm of the physical stimulus, not with its absolute value.
The core implication is that human perception is not linear. The difference between 1 and 2 feels the same as the difference between 100 and 200 — which feels the same as the difference between 1,000 and 2,000. Each doubling is perceived as the same step. Conversely, the difference between 100 and 101 feels the same as the difference between 1 and 1.01: nearly imperceptible. Our sensory systems compress large absolute differences and amplify small proportional ones.
The Just Noticeable Difference — the smallest change in a stimulus that a person can reliably detect — is typically expressed as a percentage of the base value. Research by SitePoint and other web performance specialists, applying Weber-Fechner principles to load time perception, has established that the just noticeable difference for load times is approximately 20 percent of the current duration. A page that loads in 5 seconds must be improved to 4 seconds or less before users reliably perceive a difference. A 200-millisecond improvement on a 5-second load time is functionally imperceptible. A 200-millisecond improvement on a 500-millisecond load time is substantial.
This proportionality is not limited to load times. It applies to every dimension of product experience that users evaluate: price changes, feature counts, notification frequency, content density, and animation smoothness all follow logarithmic perception curves. The law is a description of human sensory architecture. It is not overridable by design or communication.
The most direct product application of the Weber-Fechner Law is in performance work prioritization. Teams optimizing for load time, response latency, or frame rate face a counterintuitive reality: the faster the product already is, the less users will notice further improvements of the same absolute magnitude. A product that loads in 8 seconds can be dramatically improved by shaving 2 seconds — users will clearly notice the transition to 6 seconds. The same 2-second improvement on a product that already loads in 3 seconds may produce a barely perceptible difference.
This creates a threshold effect in performance optimization. Improvements that cross the proportionality threshold — reducing load time by 20 percent or more — produce user-perceptible changes. Improvements that fall below the threshold may be real improvements that users will never consciously register. The engineering effort is the same either way. The user experience impact is not.
The implication for prioritization is direct: when a product’s performance is already within the range users find acceptable, further absolute improvements require proportionally more work to achieve the same perceptual gain. At some point, performance optimization delivers real improvements that are functionally invisible to users — and the engineering time might produce more user-perceived value invested elsewhere.
Pricing decisions follow Weber-Fechner dynamics with directly commercial consequences. A $10 price increase on a $20 product — a 50 percent increase — is highly salient to users. A $10 price increase on a $200 product — a 5 percent increase — may pass unnoticed by many users even though the absolute dollar change is identical. This is why small pricing adjustments on high-priced products are a common strategy for SaaS companies managing cost increases: the proportional change is small enough to fall below the just noticeable difference threshold.
The inverse is equally important. Pricing anchors work through Weber-Fechner dynamics: a product priced at $150 per year feels substantially different from one priced at $200 per year even though the absolute difference is $50 per month — less than $5 per month. The proportional difference (25 percent) triggers the perception of meaningful difference. Many pricing decisions that look arbitrary are actually calibrated around proportional perception thresholds.
Product teams face a specific Weber-Fechner failure mode when improving existing features. A feature that works adequately but not excellently is typically in what might be called the middle zone: users have calibrated their expectations to the current performance level, and improvements of similar magnitude to what got the feature to “adequate” will produce much less perceived improvement. The law predicts that doubling effort to move from 50 percent adequate to 75 percent adequate will produce a smaller perceived improvement than the initial effort that moved from 0 to 50 percent.
This is one reason why iterative improvements to existing features often receive less user recognition than their engineering cost would predict. The feature was impactful when it first solved a problem users were experiencing acutely. Additional investment delivers real improvement at a level of perceived baseline that is much higher — and the logarithmic perception curve compresses the perceived gain accordingly.
The just noticeable difference threshold — approximately 20 percent for most performance dimensions — provides a practical standard for evaluating whether proposed improvements are likely to be user-perceptible. Before committing engineering resources to a performance improvement, the proportional magnitude can be evaluated against this threshold. A proposed improvement that reduces load time from 4 seconds to 3.5 seconds — a 12.5 percent improvement — falls below the perceptual threshold. Users will not reliably notice it without prompting. A proposed improvement that reduces load time from 4 seconds to 3 seconds — a 25 percent improvement — crosses the threshold and is likely to produce a perceptible change in user experience.
This does not mean sub-threshold improvements are worthless — cumulative sub-threshold improvements can cross thresholds, and performance improvements have compounding technical benefits independent of user perception. But it does mean that positioning sub-threshold improvements as user-facing improvements is misleading, and that prioritization decisions based on absolute improvement magnitude rather than proportional magnitude will systematically misallocate engineering effort.
Google’s approach to search result latency improvements illustrates the law applied at the scale where proportional thinking matters most. Google has documented extensive research showing that user behavior — click-through rates, query refinement, session length — is measurable affected by latency differences at the scale of 100-200 milliseconds when baseline latency is already sub-second. At sub-second baseline, 100 milliseconds represents a substantial proportion of the total. The same 100-millisecond improvement on a 5-second baseline would be barely detectable. Google’s performance investment is calibrated to the proportional sensitivity curve of its users at its operating speed, not to absolute millisecond counts.
Spotify’s pricing architecture across markets demonstrates Weber-Fechner principles applied to cross-market pricing strategy. The company’s pricing in different markets is not set by converting dollar prices to local currencies — it is calibrated to local income levels and local price reference points, which are the relevant baseline against which proportional sensitivity is measured. A premium tier priced at the equivalent of 5 percent of monthly income in one market and 15 percent in another produces dramatically different perceived value propositions even if the feature set is identical, because the proportional relationship to the user’s baseline is different.
Apple’s annual pricing adjustments to its hardware line follow a consistent pattern that reflects Weber-Fechner awareness at a product strategy level. Price increases are typically in the range of 3-5 percent on premium hardware — below the perceptual threshold for a high-priced item — and are often accompanied by feature additions that provide a positive reference point. The pricing adjustment strategy is not designed to obscure increases — they are public — but to position them proportionally within a range that users are less likely to experience as shocking.
The Weber-Fechner Law matters for product teams because it describes a systematic relationship between physical reality and perceived experience that most product decisions ignore. Teams that evaluate improvements by absolute magnitude rather than proportional magnitude will systematically misjudge which improvements users will notice, misallocate engineering resources toward sub-threshold work, and incorrectly communicate the user impact of performance investments.
The law also has implications for how teams communicate improvements to users. Absolute improvement claims — “we made the product 200 milliseconds faster” — may be technically accurate but perceptually misleading if the baseline is slow enough that 200 milliseconds is sub-threshold. Proportional claims — “we made the product 25 percent faster” — communicate the perceptually relevant information. Teams that routinely communicate in absolute rather than proportional terms are producing communications that do not match the user’s actual experience of the improvement.
There is also a planning implication. Weber-Fechner dynamics predict that as a product matures and performance improves, the engineering investment required to produce user-perceptible improvements increases exponentially. A team that expects linear returns on performance investment will be consistently surprised by the diminishing perceptual returns of work that is objectively as good as or better than earlier work. The expectation calibration issue is avoidable with an understanding of the law.
Evaluate proposed improvements by proportional magnitude, not absolute magnitude. For any performance improvement being considered, calculate the proportional change relative to the current baseline. Apply the 20 percent just noticeable difference threshold as a first filter: is this improvement large enough that users are likely to notice it? If not, the improvement may still be valuable for technical reasons, but it should not be positioned or communicated as a user experience improvement.
Calibrate performance targets to perceptual thresholds, not engineering convenience. Rather than setting performance targets at round numbers or technically convenient milestones, set them at proportional thresholds. If current load time is 4 seconds, the next perceptually meaningful target is 3.2 seconds or less. A target of 3.5 seconds is a real improvement that users will not perceive. A target of 3 seconds is a real improvement that users will.
Communicate improvements proportionally. When reporting performance improvements to users, leadership, or the public, use proportional language that reflects perceptual reality. An improvement from 4 seconds to 3 seconds is a “25 percent improvement” that is perceptually significant. An improvement from 10 seconds to 9 seconds is a “10 percent improvement” that is perceptually marginal. The proportional framing matches user perception in a way that absolute framing does not.
Apply Weber-Fechner thinking to pricing decisions. Before introducing a price change, evaluate it proportionally against the current price and against comparable reference points in the user’s mental model. A change that is proportionally above the just noticeable difference threshold will be perceived as meaningful. A change that falls below it may pass without the user consciously registering a change. This asymmetry has direct implications for how and when price changes should be introduced.
Ernst Weber’s discovery in the 1830s was not a finding about weights and sounds. It was a finding about the architecture of human perception: that we are built to detect proportional differences, not absolute ones. Fechner’s mathematical formulation of the same insight — that perception scales logarithmically with stimulus intensity — established that this architecture is systematic, measurable, and predictable.
For product teams, the law provides a reliable map of where improvements will be felt and where they will be invisible. The map does not make engineering decisions for you. But it ensures that the decisions you make are calibrated to the sensory reality of the people who use what you build — not to the linear intuitions of the people who build it.
The same improvement feels completely different depending on where you start. Know your baseline. Calculate proportionally. Design for the threshold that matters.
One second removed from ten barely registers. One second removed from two transforms the experience. The physics is the same. The perception is not.
Fred Brooks had a gift for naming things precisely. In 1975, in The Mythical Man-Month, he introduced a phrase for a failure pattern he had watched repeat across projects at IBM: the second-system effect. The name is simple. The observation behind it is unsparing.
“An architect’s first work is apt to be spare and clean,” Brooks wrote. “He knows he doesn’t know what he’s doing, so he does it carefully and with great restraint. As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used ‘next time.’ Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system. This second is the most dangerous system a man ever designs.”
Brooks was writing about software architects. The pattern he described applies with equal force to product managers, product teams, and product companies. The second product, the second feature set, the second version — built after a first success, by people who now believe they understand the space — is the one that most reliably overreaches.
A two-person team builds a file sharing tool. It is minimal, fast, and solves one problem precisely. They did not know enough to build anything ambitious. They shipped what they could manage. Users respond enthusiastically. The team raises a seed round.
Now they have time, resources, and an expanded team. They also have a backlog of features they had to defer during the first build: user permissions, version history, team workspaces, activity feeds, integrations with five external services. They build version 2 to include all of it. The architecture is rebuilt from scratch to support the scale they now believe is coming.
Version 2 takes eleven months. It ships with significant performance regressions relative to version 1. The interface is substantially more complex. The features users loved about the original — the speed, the simplicity, the directness — have been designed away in service of capabilities that most users were not asking for. Churn increases. The team does not immediately understand why. The second system is the explanation.
The second-system effect is the tendency for a first successful system — often small, spare, and constrained — to be followed by a second system that is overengineered, over-featured, and bloated, driven by the accumulated ambitions that were deferred during the first build and by the confidence that success produces.
Brooks identified two contributing mechanisms. The first is deferred embellishments: during the first build, the architect accumulates ideas — features, capabilities, architectural improvements — that cannot be included due to constraints of time, scope, or technical knowledge. These ideas are stored for “next time.” When next time arrives, they are all added at once, without the filtering constraint that made the first system coherent. The second mechanism is overconfidence: the success of the first system produces a belief that the team has mastered the problem space, which reduces the caution and restraint that made the first system successful. The discipline that produced the first system’s quality is attributed to capability. In fact, it was largely produced by constraint.
The effect is not limited to technical systems. It appears in product design, in startup product strategies, in feature development cycles, and in organizational design. Wherever a first successful creation is followed by a second with fewer external constraints and more accumulated ambition, the conditions for the second-system effect are present.
The most counterintuitive aspect of the second-system effect is that the constraints which felt like limitations during the first build are the primary drivers of its quality. A team building a minimal product under severe resource constraints is forced to make hard choices about what matters most. Every feature must justify its inclusion against competing uses of the same limited time. The filtering process this produces is brutal and effective. What survives is essential.
When those constraints are removed by success — by funding, by time, by expanded team size — the filtering process loses its authority. Features that would have been cut under constraint can now be included. The team has the resources to build them and the confidence that they know which ones are worth building. Both beliefs are partly false. The resources enable scope creep. The confidence enables overreach. The combination produces the second system.
Brooks’s prescription was explicit: the discipline that constraint produced must be replaced by explicit self-discipline when constraints are removed. Resisting “functional ornamentation” — features added not because they solve problems but because they can be added — requires deliberate organizational commitment when the external pressure to resist them is gone.
Every constrained first build produces a backlog of deferred ideas. These ideas are real, and many of them have genuine value. The problem is not the ideas themselves but the manner in which they tend to be included in second systems: all at once, without the sequential prioritization that would have filtered them through the first system’s development process.
A feature that would have competed for inclusion and been cut during the first build — because something more important needed the same time — enters the second build as a given. It is already on the list. It has been promised. The new team member sees it on the backlog and assumes it must be important. Nobody questions it because it has been waiting for two years. The feature ships. Users do not use it.
This dynamic compounds across the entire deferred backlog. Second systems do not include one or two deferred features. They include all of them, because all of them survived the wait. The discipline that determines what belongs in the first system is absent from the second system’s backlog by construction.
The success of a first system produces confidence, and confidence produces a specific kind of miscalibration. Teams that have succeeded once believe they understand the problem space better than they do. They have mastered the problem as it appeared at the beginning — the problem they had to solve to ship the first version. The problem as it exists at the beginning of the second system is different: larger, more complex, more ambitious. The confidence that the team developed through solving the first problem is applied to the second problem, which the team does not yet understand at the same depth.
Brooks described the result as “functional ornamentation” — features and capabilities added not because users need them but because the team now believes it understands what users will want in the future. The prediction is made from a position of demonstrated competence at a different scale. The belief that competence at one scale transfers to competence at the next is the confidence miscalibration.
Netscape Navigator’s development history is the canonical second-system example in software. The first version of Navigator was built under severe constraints — a small team, limited time, and an entirely new problem space. The result was spare, fast, and commercially transformative. The second-generation rewrite, initiated in 1998 and eventually released as Netscape 6.0, accumulated every architectural ambition, every deferred feature, and every technical improvement the team had deferred during the first build. The project took nearly three years. The released product was slower than its predecessor, more complex, and less stable. Joel Spolsky’s 2000 essay “Things You Should Never Do” described the rewrite as among the worst strategic decisions in software history. Netscape’s market share collapsed during the development period. The second system handed the browser market to Internet Explorer not by being inferior — it arguably was — but by taking so long to arrive that the competitive window closed while it was being built.
Apple’s product history contains deliberate attempts to avoid second-system dynamics through product discipline. The original iPod was a minimal device designed to do one thing — play music from a library — with exceptional execution of that one capability. The subsequent iPod generations added functionality incrementally rather than comprehensively, each addition tested against the product’s core value proposition rather than included because it was technically possible. The discipline is most visible in what was not added: features that later appeared in competitors’ devices were evaluated and declined throughout the iPod’s commercial lifespan. The product’s long commercial success relative to competitors who rapidly added features reflects the constraint that the team maintained against the pull of accumulated ambition.
The Basecamp story of iterating on their own product across multiple versions illustrates a company that navigated the second-system effect by maintaining strong constraint discipline even after commercial success had removed the external pressures that originally imposed constraint. Jason Fried and David Heinemeier Hansson have described their approach as deliberately treating each new version of Basecamp as a product that must make its own case for every feature, rather than inheriting a feature set from the previous version. Basecamp 3 did not include Basecamp 2’s full feature set — features were re-evaluated for inclusion rather than automatically carried forward. The decision to maintain separate products rather than forcing all users onto a single upgraded version is itself a mechanism for avoiding the deferred backlog problem: the second version does not have to carry the accumulated ambitions of the first.
The second-system effect matters for product teams because it describes the failure mode that is most likely to follow first success — and because the conditions that produce first success actively create the conditions for second-system failure. The resources, confidence, and accumulated ideas that success generates are exactly the inputs that the effect requires. Managing a product through a successful first release without falling into the second-system trap is a specific organizational discipline, not a natural consequence of doing good product work.
The effect also explains a persistent mystery in product development: why products that users loved in their early forms frequently disappoint when they are rebuilt “properly.” The early form was produced under constraint. The rebuilt version was produced under confidence and abundance. The constraint produced quality through forced simplicity. The abundance produced complexity that users experience as a regression even when each individual feature added is, in isolation, valuable.
Research on creative output across domains — from architecture to product development to academic writing — consistently finds that early work produced under resource constraint is frequently evaluated as more aesthetically coherent than later work produced under abundance. Brooks’s second-system effect is a specific case of a more general principle: constraint is a creative force, and its removal requires deliberate replacement with explicit discipline to preserve the quality it produced.
Audit the deferred backlog before beginning the second build. Before committing to any feature for the second system, evaluate each item as if it were a new proposal competing for inclusion in a constrained first build. Ask the filtering questions: what specific user problem does this solve? How many users have this problem? What is the cost of not including it? Features that survive this evaluation belong in the second system. Features that rely on their deferred status for inclusion do not.
Maintain explicit scope constraint on the second build. The absence of external resource constraints on the second build must be replaced by explicit internal scope constraints. Establish a hard scope limit for the initial release of the second system — a number of features, a complexity budget, or a time-box — and enforce it against the accumulated ambitions in the backlog. The constraint will feel artificial. It is. It is also necessary to reproduce the filtering that produced the first system’s coherence.
Treat second-system confidence as a warning signal. When team members express high confidence in the design of the second system based on their experience with the first, treat that confidence as evidence that the second-system dynamics are active. The confidence is partly real — experience is genuinely informative — and partly produced by the mechanism Brooks identified: mastery of one problem applied to a different, larger problem. Calibrate confidence to the specific problem being solved, not to the general category of problems the first system addressed.
Preserve the first system’s core value proposition explicitly. The features that made the first system successful should be written down and protected as a constraint on the second. Any second-system feature that would degrade the performance, simplicity, or directness of the core value proposition should require explicit justification, not just inclusion by default. The users who loved the first system loved it for specific reasons. The second system should honor those reasons, not design around them.
Brooks’s observation about second systems was not a counsel of pessimism. It was a description of a specific and avoidable failure mode, along with the conditions required to avoid it. The second system is not dangerous because ambition is wrong or because learning from the first system is wrong. It is dangerous because ambition without constraint produces incoherence, and because learning from success produces a specific form of overconfidence that makes the incoherence invisible until users experience it.
The teams that navigate second-system dynamics successfully share a common discipline: they preserve the constraining function of the first system’s development environment even when the external constraints have been removed. They continue to ask which features justify their inclusion as if resources were still scarce. They continue to maintain the simplicity of the core value proposition as if scope were still limited. They continue to treat the space as incompletely understood even after a first success.
The first system is spare and clean because it has to be. The second system is spare and clean if the team is good enough.
Brooks called the second system the most dangerous a person ever designs. He was not exaggerating. He was describing the exact moment when experience, confidence, and resources come together — and the discipline required to prevent them from producing the most ambitious failure in a product’s history.
Build the second system like you built the first. With restraint. With ruthless prioritization. As if you do not have the luxury of being wrong.
The Minimum Lovable Action (MLA) is a tiny, actionable step you can take this week to move your product team forward—no overhauls, no waiting for perfect conditions. Fix a bug, tweak a survey, or act on one piece of feedback.
Why it matters? Culture isn’t built overnight. It’s the sum of consistent, small actions. MLA creates momentum—one small win at a time—and turns those wins into lasting change. Small actions, big impact
Every product manager has stakeholders they enjoy working with and stakeholders they dread. The ones they dread usually share a pattern: conversations feel transactional, alignment is fragile, feedback comes late or not at all, and decisions that should be straightforward become unexpectedly difficult. Most PMs explain this as a personality clash or a structural problem — this person is hard to work with, or this relationship is just complicated by nature of the org.
Rarely do they diagnose it as a trust problem. And even more rarely do they treat it as something they can actively change.
In 2000, David Maister, Charles Green, and Robert Galford published a model that made trust measurable in a way it hadn’t been before. Their Trust Equation defines trustworthiness as a formula: Credibility plus Reliability plus Intimacy, divided by Self-Orientation. The numerators — credibility, reliability, intimacy — all increase trust when they go up. The denominator — self-orientation, the degree to which someone seems focused on their own agenda rather than yours — destroys trust when it goes up, regardless of how credible or reliable that person appears to be.
What makes this model useful isn’t the equation itself. It’s the diagnostic precision it offers. A person can trust someone’s expertise but distrust their motives. A stakeholder might find you entirely credible — they believe what you say — and still not trust you, because you’ve been unreliable on follow-through, or because every interaction feels like you’re managing them toward a conclusion you’ve already reached. Each dimension of trust can fail independently, and each failure requires a different response. “Build more trust” isn’t actionable. “Your self-orientation is reading high in this relationship” is.
Most people tend to rely on credibility and reliability to build trusting relationships — these elements are more tangible and easier to measure. But intimacy and especially self-orientation are the most impactful factors to shift when wanting to improve trustworthiness. The PM who walks into every stakeholder conversation with a clear agenda is communicating, however subtly, that the conversation is about getting to their answer — not about genuinely engaging with the other person’s perspective. That signal is perceived. It accumulates. And over time, it makes alignment harder, not easier.
This MLA is a structured look at where you actually stand — not how you intend to show up, but how five key relationships are likely experiencing you right now.
Step 1: Choose five stakeholder relationships
Not the five easiest. Not the five hardest. Choose a representative range — someone you work with smoothly, someone where collaboration feels effortful, someone new, someone you’ve worked with for years, and one whose role is adjacent enough that you interact only occasionally. The variation is what makes the audit useful.
Step 2: Score each relationship across the four dimensions
For each person, rate yourself on a scale of 1–5 on each dimension. Be honest — score how you think they’d describe the relationship, not how you’d like them to.
Credibility (1–5): Does this person trust what I say? Do they believe I understand the domain, the users, the product well enough for my perspective to carry weight? Have I ever been wrong about something I stated confidently — and how did I handle it?
Reliability (1–5): Do I follow through on what I commit to with this person? Do I close loops, send the update I said I’d send, come back with the answer I promised? Or do things fall through the cracks in this relationship more than in others?
Intimacy (1–5): Does this person feel they can be candid with me — and do I create the conditions for that? Do they share concerns before they become problems, or do I only hear about issues when they’ve already escalated? Is our relationship transactional or does it have some genuine human texture?
Self-Orientation (1–5, lower is better): In interactions with this person, how often am I listening to understand versus listening to respond? Do I enter conversations with a conclusion I’m steering toward? When they push back, do I get curious or defensive? Would they say I’m genuinely trying to help them, or trying to get them to agree with me?
Step 3: Calculate a rough trust score for each relationship
Add your credibility, reliability, and intimacy scores, then divide by your self-orientation score. This is a diagnostic tool, not a precise measurement — don’t optimize for the number. What you’re looking for is pattern, not precision.
A relationship where you score 4+4+4 on the numerators but a 4 on self-orientation will score the same as one where you score 3+3+3 with a self-orientation of 2.25. The math surfaces where the constraint is.
Step 4: Identify your lowest-scoring relationship and your most common failure mode
Two questions worth sitting with:
Which relationship has the most room for improvement — and which dimension is most responsible for that gap? A reliability gap is addressable through different behavior than a self-orientation gap. A credibility gap might mean you need to do more preparatory work before certain conversations. An intimacy gap might mean you need to invest more in the human side of a relationship that has become purely transactional.
Is there a pattern across relationships? If your self-orientation score is consistently above 3, that’s not a relationship problem — that’s a listening problem. If reliability is consistently your weakest dimension, the issue isn’t any particular stakeholder — it’s how you manage your commitments.
Step 5: Choose one relationship and one action this week
Not five relationships. One. And not a vague intention — a specific action tied to the dimension that’s weakest. If the gap is intimacy, schedule a conversation with no agenda other than understanding how that person is thinking about their current priorities. If the gap is reliability, send the update you’ve been meaning to send. If the gap is self-orientation, go into your next meeting with that person and commit to asking twice as many questions as you answer.
The action doesn’t need to fix the relationship. It needs to create one new data point — one interaction that goes differently than the pattern has been.
Step 6: Revisit in two weeks
Trust changes slowly. But it does change. Two weeks of different behavior in one relationship is enough to notice whether the dynamic is shifting. The audit is useful once. The habit of running it periodically — and noticing when a relationship’s score has changed — is what builds sustained stakeholder effectiveness over time.
For you: The most immediate benefit of this exercise is the replacement of vague unease with specific diagnosis. Knowing that a particular relationship is low-trust is uncomfortable but not actionable. Knowing that it’s low specifically on intimacy — that the person doesn’t feel safe being candid with you — tells you exactly what to work on. PMs who develop the habit of diagnosing trust at this level of granularity navigate stakeholder complexity faster, surface resistance earlier, and spend less time in alignment conversations that feel productive but aren’t.
For your team: Trust between a PM and key stakeholders doesn’t stay contained to those relationships. It radiates. A PM who is genuinely trusted by engineering leadership creates more latitude for the team to take risks, surface problems, and push back on direction without fear. A PM who is trusted by customer success hears about user problems before they become escalations. The relational infrastructure a PM builds — or fails to build — shapes what information the team has access to and what decisions become possible.
For your organization: Trust is the real currency in business, and it forms the base of team performance. If there’s no trust, forget about all the tools and tactics — address trust first. Most organizations invest heavily in process, tooling, and structure, and almost nothing in explicit development of the relational skills that determine whether any of those systems actually function. A product manager who treats trust as a skill — something that can be diagnosed, measured, and improved — is a different kind of organizational actor than one who treats it as a personality trait. That difference compounds.
Score five relationships this week. Find your most common failure mode.
Then do one thing differently in one relationship — this week, not eventually.
Doing this challenge? Share what you found on LinkedIn or X and tag it #MLAChallenge. The dimension that showed up as your weakest across multiple relationships is usually the most worth naming out loud.
At some point in the early 2010s, the industry decided the answer to every question about the future of design lived in one sentence: “Designers should code.” That sentence spread across conferences, LinkedIn, and bootcamp curricula like an oil slick. Some defended it with apostolic conviction. Others pushed back with equal force. The debate is still running today, and I got tired of it a while ago.
Not because the question is wrong, but because it’s wrong-headed.
Alan Cooper – the man who built some of the first commercial software for personal computers and wrote “The Inmates Are Running the Asylum” – said something about this debate that should have ended it a decade ago: “Performing a task does not automatically teach you the implications of performing it.” The fact that you write code doesn’t mean you understand what your code does to the user, to the team, to the product. And the reverse is equally true – not being able to write code doesn’t mean you don’t understand the system you’re designing.
Cooper named the debate for what it is: a matter of personal taste being presented as universal truth. Like insisting that because you don’t like avocado, avocado is objectively a terrible food.
The real question, the one this debate never actually asked, is different. Not “should designers code?” But: what order do you think in?
An architect doesn’t lay bricks. But an architect who doesn’t understand how bricks stack designs things that can’t be built, or that cost three times what they should. The difference between “I can lay bricks” and “I understand how bricks work” is the difference between craft and thinking through the material. Nobody argues that architects should become bricklayers. Everyone agrees they need to understand the material they’re designing for.
The design version of this should be obvious by now. It isn’t – and we’ve had twenty years to figure it out.
Karl Koch, a design engineer at DuckDuckGo, described his team’s process: they never open a design file before writing the decision down in words. Not a shorthand note, not a Slack message, not “let’s talk about it on a call” – a literal written document that says: we believe this change will produce this outcome, because of this reason. Only then, Figma.
Why? Because – as Koch puts it – “a mockup is a persuasive object. It looks resolved even when the thinking underneath it is not.” A written sentence can’t hide. You can challenge every word – and that’s the point. You want the argument exposed while the change is still cheap.
I know this from both sides of the table. As a designer, I’ve been in reviews where a wireframe looked great and then it turned out nobody thought through what happens when the user has no data yet, or when the text is twice as long as in the example, or when the connection is slow. As someone evaluating other people’s work – I’ve seen portfolios full of beautiful screens without a single sentence about what those screens were supposed to solve.
A mockup is a tool. The tool doesn’t think for you.
For years, the “designers should code” argument had at least one practical justification: designing in the browser, in live code, gets you to the truth of how something actually works faster. Figma is great, but it’s not a browser. A pixel in Figma is not a pixel on an Android phone with system fonts and touch gestures.
That argument is still true – but it stopped being sufficient.
Jakub Krehel, a design engineer at Interfere, describes this precisely through animations. Today anyone can animate an interface. An AI agent will do it in a few seconds. But does the animation make sense? Krehel gives a simple example: a context menu. You can animate it on open and on close. On paper that sounds fine. In practice – if a user opens that menu 200 times a day and the animation runs 300 milliseconds, those animations eat over six hours a year. Per person. Watching a menu appear.
The decision to not animate something requires understanding – not the ability to animate, but the ability to think about why animation exists at all. Krehel says it plainly: “Animating something and animating something well are two very different things.” AI agents are excellent at executing. They don’t yet have the capacity for understanding and judgment.
Figma just announced Figma Motion – animation native to the canvas, with an agent that generates keyframes from a text description. The Lead Motion Designer at Atlassian commented that the tool will “help people develop taste faster.” Access to the tool speeds up exposure. Taste – knowing when movement helps and when it gets in the way – is still something you build yourself. Access to a faster brush doesn’t make you a better painter.
The temptation, when a machine can execute faster than you can think, is to let it. Not out of laziness – out of pressure, out of the reasonable desire to keep up. But execution that outruns thinking doesn’t produce better work. It produces more work that looks finished. And in a world where the output is indistinguishable, the thinking is the only thing left that’s yours.
TJ Pitre put it most sharply: “A prototype that looks finished but uses none of your real components is not progress. It is a liability with good lighting.” A prototype built outside the design system, outside real components, outside the constraints of the actual framework – that’s an illusion of progress, and it costs three months when engineering has to rebuild it from scratch.
The problem isn’t the tool. The problem is reaching for the tool before you know what you want to say.
Code is a material – the same way brick is for an architect, or a lens is for a director. You don’t have to manufacture the brick to understand how load travels through a wall. You don’t have to grind the glass to know what a 35mm frame does to a face. Most directors don’t operate the camera. That’s what the DP is for. What they do instead is understand the camera well enough to know exactly what they’re asking for.
Designers who understand code design differently. They know that “let’s just add a hover animation” is easy in Figma and complicated in CSS on touch devices, where hover doesn’t exist. A component looking like one element in Figma might be eight elements in the DOM, each with its own state – and horizontal scrolling requires separate mobile logic that nobody will think to mention until the prototype is already in engineering. Designers who know this raise those questions before anyone opens a ticket, not after.
None of that knowledge requires writing production code. It comes from talking to engineers enough times that you start hearing the patterns. From reading code without having to ship it. From asking “how does this actually work under the hood” until the answer stops surprising you.
The best example I have isn’t theoretical. A checkout redesign – the kind with serious internal complexity, business validation logic, backend connections checking order integrity and customer credibility at every step. The design system for that project wasn’t built in Figma (well, that’s where it started – until our engineers started asking the right questions about frontend constraints and API communication, and we moved the real work somewhere it could actually answer them). It was built in code, collaboratively, with designers, developers, and business stakeholders in the room together. Frontend work that had been planned for six weeks was done on day one. Engineers had finished components in hand and spent the day assembling views. Nobody built anything from scratch. The thinking had already happened – it was encoded in the system.
The business went into a mild panic. Frontend developers who weren’t building anything felt like a waste of money. That’s the part I still find funny. The work was so well thought through in advance that the execution looked like nothing was happening.
That’s the distinction that code literacy actually gives you. Not the ability to ship a pull request. The ability to feel the resistance of the material while you’re still designing – to know when you’re designing something that can be built with care, and when you’re designing something that will be rebuilt from scratch by someone who has to guess at your intention.
Before you open Figma – do you know what you’re trying to say? Did you read the documentation? Do you have HIG on your resume because it looks fancy, or did you actually read it? Have you talked to the engineer who’ll build this before you made anything that looks like a proposal? Do you know what happens in the error states, the empty states, on a slow connection?
If not, you have a mockup that looks like thinking but isn’t.
Every tool available to you right now is powerful enough to generate something that looks like a finished product – quickly, convincingly, with good lighting. None of them replaces the question you should ask yourself before the first click.
Understand code well enough to think alongside an engineer. Not well enough to replace an engineer – that’s a different job, with its own craft and its own depth. Well enough to know what questions to ask. Well enough to feel the resistance of the material while you’re designing. Well enough that your prototype is evidence of thinking, not a substitute for it.
The debate about whether designers should code has no answer because it asks the wrong question. The right question is whether you think before you build.
Some designers do. That’s why their work ships the way it was designed.
A Scrum Master’s Perspective
Iwona had been a Scrum Master at a mid-sized Polish product company for three years. Three Scrum teams under her coordination, about twenty people total, all remote since the pandemic. The teams were functioning well, though each in a different rhythm — one more synchronous, the other two more time-distributed.
In January, a new engineering director, fresh off reading Cal Newport’s A World Without Email, announced an initiative titled “Async First.” Main slogans: Slack instead of meetings, documentation instead of Daily, “deep work hours” as protected blocks without notifications, decisions exclusively in written threads. The arguments were familiar to anyone reading contemporary productivity literature. Every work interruption costs twenty-three minutes and fifteen seconds of regaining attention. Interruptions kill productivity. Async teams work more deeply. Meetings are a tax on work.
Iwona accepted the initiative with openness. She herself enjoyed deep work. She knew Daily sometimes turned into a status report. She knew an excess of meetings in some teams was a real problem. The first two months went well. People praised the new approach. Slack got deeper, threads more detailed, documentation more regular. Iwona wrote a report for the director describing successes.
In March, things started happening that no one had expected. Two critical production bugs turned out to have been known to team members — but the information “sat” in one Slack thread that none of the people with decision authority read in time. Three architectural decisions made asynchronously were challenged a month later when it turned out two different people had understood them differently — because no one had asked the question that would have required actually checking that everyone was talking about the same thing. The new junior developer who joined the team in February twice asked Iwona off-record whether “people actually work with people here,” because for six weeks no one had invited him to a conversation outside a thread in a work tool.
Iwona looked at the statistics from those two months. Meeting time had indeed
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.