Taste
Linear and Jira seem to do the same thing. They track issues. They manage sprints. They let you assign work and move cards across columns. Feature for feature, Jira probably does more. It's been around longer, it has more integrations, more configuration options, more everything.
And yet engineers I know who've used both recoil at the idea of moving back to Jira from Linear. The preference is visceral. It's not because Linear has some killer feature Jira lacks. It's because everything in Linear feels considered. Common interactions feel nearly instantaneous. The keyboard shortcuts work the way you expect. The views load instantly. Creating an issue takes one action, not four clicks through a modal with twelve required fields. Linear feels like it was built by people who really care about their craft.
That gap is taste.
I wrote previously about agency — the ability to take something from zero to one without waiting for permission or instructions. Agency determines whether you can ship at all. But two teams that can both ship will build meaningfully different products. Linear and Jira are proof. The difference is in the thousand small calls made along the way, the ones that are impossible to capture in a product brief or a Figma.
What taste looks like in practice
Taste isn't just an aesthetic sensibility. It's not about having opinions on typography or knowing about Dieter Rams' ten design principles.
Taste shows up in decisions. Specifically, the decisions that live below the resolution of any spec. It's judgment about what matters here, for this user, and what doesn't. The latency requirements of every click and swipe. What the app should do when the API returns an unexpected state. Whether to show the user a confirmation dialog or just let them undo. How an error message reads when someone's credit card gets declined at the worst possible moment.
No product manager or designer can realistically specify each of these things. They get decided by whoever's building the feature, in the moment, dozens of times a day. Taste is what makes those decisions cohere into something that feels like a single mind designed it.
You can usually tell within thirty seconds of using a product whether the team that built it has taste. The transitions don't stutter. The copy doesn't contradict itself. The settings page doesn't have forty toggles when five would do. Things were left out on purpose, and the things that remain feel chosen.
Where taste comes from
Taste comes from shipping things and paying close attention to what happens after you ship. You build a feature, you watch people use it, you notice what confuses them, you notice what they try to do that you didn't anticipate. Then you do it again. Over years, this builds up instincts about how software should behave. You start pattern-matching faster. You start catching problems before they happen because you've seen that shape before in other products.
Reading design systems documentation and studying Apple's HIG can help, but they won't get you there on their own. They teach you the vocabulary of good product design, but vocabulary isn't judgment. The people I've worked with who have the most taste have one thing in common: they've shipped a lot, and they gave a damn about the details of what they shipped even when nobody was checking.
Taste makes you faster
There's a misconception that taste slows you down. In practice, the opposite can be true.
People with taste can make decisions faster because they have strong priors. When you've built fifteen onboarding flows, you don't need a three-week sprint to know that asking for a company name and a work email is enough on the first screen. You just know. When you've seen what happens when you bury an important action in a dropdown menu, you don't need to A/B test it. You put the button where it belongs and move on.
This compounds. A team with taste spends less time in design reviews relitigating familiar decisions. They spend less time fixing predictable UX and edge-case problems after launch because those problems were handled during development. With experienced judgment, speed and quality aren't always in tension. They come into tension when a team has to rely on process to catch mistakes that judgment could have prevented.
Taste vs. perfectionism
These look similar from the outside, but they're completely different.
Taste is knowing when something is good enough. Perfectionism is the inability to stop polishing. Taste is contextual quality judgment — knowing the easing curve matters on the customer-facing checkout flow and doesn't matter on the internal admin tool. The best product engineers I've worked with can oscillate between "this needs to be perfect" and "this needs to be done" within the same afternoon, depending on what they're building and who it's for.
All you need is Agency and Taste
Agency without taste gives you speed without delight. Products that check every box but don't hang together. Taste without agency gives you opinions that live in Slack and Figma comments and never make it into the real world.
The combination is rare, and it's one of the most valuable things a product engineer can bring. Someone who can see the right thing to build, build it end-to-end, and make the hundreds of small calls along the way that turn a working feature into a good one.
AI is making the building part cheaper every week. We use Claude to write code every day at work and it's remarkable how fast we can go from idea to working prototype. But AI can produce options without knowing which prototype is shippable. It may not weigh the long-term package cost of an extra dependency, or recognize that the empty state deserves disproportionate care because it's often what a new user sees first.
As building gets easier, taste matters more, not less. If you're a product engineer, developing it is one of the highest-leverage investments you can make in yourself right now. Not learning a new framework. Not getting faster at prompting. Getting better at knowing what great looks like, and having the discipline to keep pushing until the work gets there.