We interview every hire for product sense. Here's why you should too

Everyone on your team is already making product decisions. The question is whether you're hiring people who make good ones.

Last month, we launched a new product Help Centers. This didn't start with perfect redline specs. This started with a rough prototype showing the vision and the scope of Help Center.

What happened next wasn't just implementation. It was dozens of product decisions that shape the customer's experience. And because everyone on our team thinks like product people, these decisions were good ones.

Your product is being built by everyone

Here's what most companies miss: your product isn't just built by your product team. It's built by everyone who touches the customer experience.

Your engineer choosing how to handle loading states. Your customer success manager planning a new customer's onboarding. Your sales team tailoring their demo to a customer. Your marketing team writing guides and docs.

Every touchpoint is a product decision, whether you acknowledge it or not.

No company intentionally creates a Frankenstein product. But that's what happens when decisions at the edges aren't considered part of the whole. Even well-designed, well-intentioned products fail here. You get products that feel cobbled together because the parts weren't designed to work as a system.

The traditional solution? Hire more product managers and designers to coordinate everything. But coordination is slow. Decisions get made at the speed of meetings, not at the speed of execution. You create bottlenecks, miss edge cases because they're often in the category of unknown unknowns, and end up with products that feel over-managed rather than thoughtfully crafted.

We took a different approach: instead of hiring people to coordinate product decisions, we hire people who can make good product decisions themselves.

What we test for

Our product sense interview has three parts. Each one reveals how someone thinks about building exceptional products.

Systems thinking

We show candidates Plain's website and ask a few questions like: "Why do you think we've chosen this group of customers as our audience, what might that make easier or harder for us as we look to scale?" There's no right or wrong answer but there is a weak answer and a strong answer.

A weak answer sounds like this: "Because they'll have an easier time connecting integrations"

A strong answer goes deeper: "I'd expect that modern teams are already looking at ways to better connect customers with the rest of their stack, in the immediate term this might look like additional integrations and building support into the places their customers already are like in Slack and in your product but soon this could be integrating with custom GPTs and home-grown AI agents."

The difference? The strong candidate goes deeper, shares their perspective and time travels, thinking ahead to how this could look in the future too.

Quality obsession

Candidates bring a product feature they admire, and we dig into what makes it work. We're not looking for surface-level observations ("the UI is clean") but fundamental understanding of what pushes something beyond good.

A weak answer: "I like Stripe's checkout because it's fast and has fewer steps."

A strong answer: "Stripe's checkout handles failure without skipping a beat. Watch how it handles declined cards, it doesn't just show an error, it guides you through alternative payment methods while maintaining context about what you were buying. The error states are designed as carefully as the happy path."

###Ownership mindset

The final piece: will they engage with product decisions or just execute tasks? We ask about their experience working with product teams, times they've shaped features, how they've interacted with customers.

We want people who are comfortable owning decisions and being accountable for outcomes. People who speak to customers, challenge assumptions, and see their role as part of a larger customer experience.

##Why this works (and when it doesn't) Let's be honest about where this came from. Plain was founded by two designers who had spent years making product decisions at previous companies. We hired like-minded people who cared deeply about design and product.

This isn't bias we stumbled into. It's a deliberate choice.

Not every company can or should do this. If your competitive advantage lies elsewhere then your mileage may vary.

But for us, it creates something powerful. Instead of buying product expertise through dedicated product roles who become bottlenecks, we build distributed product competence across the team. Decisions get made at the speed of execution rather than the speed of coordination.

Quality comes from everywhere. Our engineering team pushes design to make better decisions. Customer success shapes onboarding based on deep understanding of how our systems work.

This scalability is key. As one designer, I can work across many projects simultaneously, choosing which ones need dedicated time from me versus which ones I trust the team to handle. I can give engineers napkin-quality sketches and trust they'll figure it out. And they do.

How to adapt this to you

You don't need to copy our entire interview. But you can start weaving product thinking into your existing process.

For any role:

"Tell me about a feature you've helped to shape. What was the commercial value of that feature?"

"Can you tell me about a time you built something and it didn't solve the problem for the customer? And get them to tell you why."

For engineers:

"Tell me about a product feature you really admire. What makes it great and how could it be even better?"

For customer-facing roles:

"How would you identify if a feature we built is actually solving customer problems?"

Look for candidates who think beyond their immediate task. Who consider downstream effects. Who ask "why" instead of just "how." Who have opinions about what good looks like and can explain why those opinions matter.

The key is depth, not breadth. You're not looking for people to be product managers. You're looking for people who understand they're building a user experience, not just executing tasks.

##You're already making this choice Here's what we've learned: you're already making this choice, whether you realize it or not.

Your recent hires made dozens of product decisions in their first month. Your engineer decided how to structure that API response. Your CS manager chose which onboarding steps to prioritize. Your salesperson determined how to position features in demos.

The question isn't whether people in non-product roles make product decisions. They do. The question is whether you're selecting for people who make them well.

The result is a team where quality decisions happen everywhere, not just in dedicated product roles. Where customer experience improves through distributed ownership, not coordination and oversight.

Every customer touchpoint becomes an opportunity to exceed expectations rather than just meet requirements. That's not something you can coordinate your way into. It's something you have to hire for.