If your LinkedIn feed looks anything like mine, you’re seeing a lot of posts these days about how “execution is no longer the bottleneck”, as if the difference between an app that works and one that people love was ever about velocity. The “new” bottleneck? Taste. In other words: knowing what to ship and what to leave out, how polished the experience needs to feel, and why. It’s the stuff you can’t delegate effectively to coding agents.
This opens up some questions. Why is taste a bottleneck? What does taste actually mean in mobile product work? Isn’t taste something you either have or you don’t?
Opinions are the experience
Every mobile app is shaped by a product team’s opinions about how it should work. Not Boring’s !Camera app and Halide are great examples. Both apps have die-hard customers, and both reject the default iPhone camera experience. Halide has sharp opinions about how a pro tool should work, whereas Not Boring’s !Camera is opinionated about the joy of photography — it has a bulky 3D UI, fun haptics, and it’s dead simple for point-and-shoot use. These are two apps that essentially do the same thing, but offer vastly different experiences that are shaped by strong opinions.
Opinions matter a lot in mobile development particularly because the constraints are so unforgiving: the user’s attention is scarce, screen space is limited, and the bar for polish is high. To make things even more challenging, when product decisions aren’t backed by clear opinions, the user absorbs a cost. They’re forced to make more assumptions and decisions, and that often leads to hesitation, friction, and churn. A product can be technically functional but still frustrating to use because the opinions behind it are muddled. For example, mobile apps from many major banks tend to dedicate a lot of their experience to seldom-used services rather than focussing on what most people want to accomplish every time they open the app.
All apps are opinionated, some more effectively than others. So how do you know if the opinions behind your product are good?
Taste informs opinions
Taste is a capacity for discernment. It’s an ability to distinguish what’s excellent from what’s mediocre, and to understand why. In mobile apps, it’s what tells you when a transition feels right, when an interaction carries the right weight, or when a recovery state is reassuring enough. Taste is easy to feel but hard to capture in issue tickets.
AI is good at generating plausible composites of existing patterns, which is useful, but that’s not the same thing as product judgment. Considering mobile’s platform constraints, teams need hard-won judgment about polish, custom interactions, performance, and what matters to users in their first session. AI output might look like opinions rooted in conviction, but without expert guidance, those outputs don’t add up to a compelling point of view. So when you combine humans with genuine taste and the efficiency gains of AI-assisted development, you get teams with an even sharper edge than they had before.
But what if you don’t think you have taste? Even more troubling: what if you think you have taste but you actually don’t? Thankfully, taste isn’t a binary either/or. It’s something you can learn and keep getting better at.
Taste is a learnable skill
Most people tend to think of taste as an ineffable je ne sais quoi, but that undersells how trainable it is. A more useful way to think about taste is as a pattern library staffed by an insightful librarian. Like any library, it gets more interesting when you’re deliberate about what you add to it. And a great librarian knows exactly where all the best stuff is kept.
For mobile product teams, building that library means getting better at three things:
1. Study excellent work until you can articulate the decisions. Structured analysis of great work is one of the best ways to develop effective taste. Take an app you love and work through each key interaction until you can identify the specific decisions the team behind it likely made and whether you’d have made the same call. Don’t just admire great apps (or dunk on bad ones). Interrogate their interaction design, pacing, onboarding, notification strategy, and how they convert free users to people who are enthusiastic to pay. Bonus points for making this a group activity: our “Steamclock book club”, where we take a close look at selected Apple Design Award winners, has been informative and a lot of fun.
2. Build a shared vocabulary within your team. A shared vocabulary is how taste becomes organizational. Teams that can articulate what terms like “heavy”, “light”, “fiddly”, and “delightful” mean for a given interaction can hold those opinions consistently across a product and through every stage of the work, from design and development, to testing, and even onboarding. Taste without shared understanding turns into a junk drawer of preferences.
3. Ground the analysis in observed behaviour. Good taste isn’t the same thing as insisting on your own preferences. Take a critical look at your own work, and use key analytics to pressure-test your judgement versus what users are actually doing. Taste gets sharper when it’s informed by behaviour.
The takeaway is to treat taste as a deliberate team practice. It’s also not a hiring problem: if you bring in one person with excellent taste and put them on a team with no shared vocabulary for it, that person’s judgment will get averaged out in no time.
The uncomfortable thing
In practice, teams often feel problems before they can name them. An app ships and it functions, but activation stalls, reviews mention rough edges, or the product simply doesn’t feel coherent enough to earn trust.
This is often a taste problem, but it doesn’t mean the team is doomed. It does mean taste is now a bottleneck, and it needs to be developed on purpose.
