What we mean when we hire for product taste

When I joined Wispr in January 2024 as our second engineer, I had finished MIT's Integrated Design and Management program three years earlier. I had been trained to start with research: watch how people behave, turn that into a set of needs, and then build. Wispr didn’t work that way.

We tested constantly. We shipped builds to each other and to anyone willing to try one. But we never ran research on whether typing was painful or whether dictation was the right answer. The company started from a conviction that we knew what a better way to interact with a computer could feel like. I found that jarring.

Nine months later, Flow had found product-market fit. The lazy conclusion would have been that user research was overrated and our instincts were unusually good. I don't believe that. We later spent four months on a second product you have never used, because we never shipped it. That one taught me the difference.

The harder question is not whether to trust your intuition or listen to users. It is when your intuition is good enough to act on, and when confidence is hiding what you don't know.

That distinction is a big part of why we hire for product taste.

Where the speed comes from

When we were building Flow, every other dictation product streamed words onto the screen as they were recognized. People were used to it. When we asked, they told us they wanted it.

We didn't build it.

Watch someone dictate into a streaming interface and you can see the cost. Their eyes leave whatever they were trying to say and move to the transcript. They see a mistake and stop halfway through a sentence to correct it, even when the model might have fixed the mistake with more context. The interface pulls their attention into managing the transcription.

We wanted Flow to disappear while you spoke. So we showed almost nothing, waited until the thought was finished, and pasted the correctly formatted final text directly into the app where the person was already working.

That choice created a hard engineering constraint: the result had to arrive fast enough that waiting did not register. A product intuition about attention became a latency budget of under a second.

This is why product judgment is part of the engineering job here. The product decision and the engineering decision were the same decision. You could not hand one to a designer and the other to an engineer without losing something important in between.

The same thing happens in smaller ways all day. How should this fail? What deserves space on the Flow bar? Is this delay acceptable? Should a control be visible, or should the product be smart enough not to need it? If every question needs a PM, a designer, and an engineer in a room, the team moves at the speed of that meeting.

Good taste lets more of those decisions happen with one person in the room.

That does not mean everyone has identical taste. I care a lot about user attention and will argue against one more button or keyboard shortcut. Dillon, a Design Engineer, catches animation problems I would walk past. Tanay (Wispr’s CEO) treats data loss as a metric that should always be zero. The point is not that one person has the complete answer. It is that the bar is held by everyone, from different angles, while the work is happening.

That is where the speed comes from. Not from engineers typing faster. From fewer decisions waiting to be routed through somebody else.

The one we got wrong

In April 2025, we started building Wispr Lens. You held a shortcut, asked a question about whatever was on your screen, and got an answer.

Nobody had asked us for it. It seemed obviously useful, and it felt good when we used it ourselves. Those facts had also been true of Flow, so we trusted the pattern.

In August, we sat down and watched other people use it.

They did not know when to reach for it. "Ask anything" sounded expansive, but no particular moment in their day called for it. Without a trigger, there was no habit.

They could not tell what Lens could see. People knew what they were referring to but did not know whether the machine shared that context.

Then we saw the thing that should have stopped us much earlier. Everyone gave an AI context first and asked a question second. Take a screenshot, then write the prompt. Paste something, then ask about it. Lens reversed the order.

That behavior was not latent. It was not part of some new paradigm we had to invent from scratch. We could have watched it in any coffee shop.

The mistake was not in having a strong point of view. The mistake was relying on our own reaction in a design space we did not understand well enough. We confused being able to imagine the product with knowing that people would understand when and how to use it.

User research caught the mistake four months and a partially shipped feature later.

With Flow, we challenged what people said they wanted because we could see the cost of the existing behavior and had a specific alternative. With Lens, we ignored existing behavior that would have challenged our idea. The difference was not whether we had intuition. It was whether we had good judgment about when to trust it.

A company that moves this way will be wrong. The model only works if most mistakes are cheap, if reality reaches us quickly, and if we change our minds when it does. There are also places where learning by shipping is unacceptable. Anything involving someone's audio, data privacy, security, or ability to rely on us gets a different level of care because the mistake is not easily reversible.

What I mean by taste

Taste is close to product intuition: a working sense of what good looks and feels like before you have complete evidence.

The first part is paying attention to your own reaction. Does the thing feel calm or distracting? Obvious or confusing? Are you proud of it because it is good, or because you made it? You have to notice small reactions and be honest about them. It is easy to see what you hoped to build instead of what is actually on the screen.

The second part is calibration. Your intuition is only useful if it has something to compare against. You build taste by spending time with products in the same space, including the mediocre ones. You learn which choices are conventions for a reason, which ones are historical accidents, and where the best products have already set the bar. Without that immersion, taste is mostly preference.

The third part is understanding the design space. Every product has constraints. Some are technical, some come from user expectations, and some come from the basic shape of the problem. Taste includes knowing where those constraints are real, where they can be bent, and where a different idea might raise the ceiling entirely.

None of this makes someone reliably right. It gives them a useful first answer.

Taste is not the whole job

Taste tells you what feels right. Good product judgment is knowing how much to trust that intuition in the decision in front of you. Then data is one of the things that keeps you honest and calibrated.

Sometimes the design space is familiar, the choice is easy to reverse, and the fastest way to learn is to make the call and ship it. The moment it is live, you no longer have to argue from instinct. You can measure what actually happened. Are people using it? Do they come back? Where do they stop? How often does the failure you were worried about actually occur? Data cannot tell you what the product should be, but it is very good at telling you when the story you are telling yourself is wrong.

That feedback also improves your taste. The next instinct is informed by what happened to the last one.

Other times, shipping is an expensive way to learn something you could have learned first. Your mental model is thin. The behavior already exists. The people you are building for are different from you. Or the mistake would cost months instead of days. That is when you should watch people, talk to them, or look at the data you already have before letting conviction carry the decision.

Quantitative data and user research answer different questions. Data is good at telling you what is happening, how often, and for whom. Research helps explain why. Taste helps you imagine what could be better. Product judgment is deciding which of those you are missing.

There is no perfect framework for this. Mostly, it requires being honest about how much you actually know, then being rigorous about checking. Familiarity can look a lot like certainty from the inside.

Why we hire engineers this way

At Wispr, engineers are not handed a complete product spec and asked to implement it. The decision continues inside the implementation. We want the person closest to the work to be able to notice what feels wrong, understand the alternatives, see the limits of the current design, and make it better.

We also expect that person to recognize when their intuition has run out.

That is the distinction I care about.

Taste is knowing what you think good looks like. Good product judgment is knowing how much to trust that belief.

PMs and designers are essential here, but their job is not to adjudicate every local decision. They should be spending time on the questions where our intuition is weakest, the consequences are largest, or the product needs one coherent direction across many parts of the company. Hiring engineers with taste makes that division of work possible.

If you work here, you will not need three people in a room to change something. You will be expected to care enough to have a point of view, to explain what you are seeing, and to look again when reality disagrees.

The point is not to be right alone. It is to be trusted with the decision.