Snippets

Here’s my hot take: European teams that set up in SF probably work harder than anyone (in August, at that! 😱)

Why?

On one hand, it feels like starting the company all over again. You’re rebuilding everything from scratch - finding an office, hiring, selling, marketing, building a presence.

On the other hand, you’re doing it while your entire company is already up and running 8 hours ahead of you. Every morning, you wake up feeling like you're showing up late to 5 meetings at the same time. Everyone else has already done their work.

The result is days that start at 6am and run flat-out with calls - pipeline reviews, demo calls, candidate interviews - until 3 or 4pm. By the time I finally sit at my desk in the late afternoon, there's a long list of emails and Slack messages to catch up on. Evenings often end with me doing the deep work I've been wanting to do, and chatting to the team in Europe at 10pm as folks come online.

And on top of that, you’re setting up your personal life from scratch too - finding a place to live, getting a bank account, and figuring out life in a new country.

It won't always be like this - in fact, it can't and shouldn't be. But in those initial weeks, that's what it's like for most European founders I've spoken to.

In my case, I stay sane and clear my head with a daily run. SF makes that very easy and rewarding. Here's my new favourite spot from yesterday!

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.

Someone once told me, “Your greatest success metric is that your work continues to thrive when you’re not in the room.”

As Plain scales rapidly, I’ve been reflecting on how true that is and how rarely we talk about it when it comes to scaling a startup.

Every early-stage operator knows how to move fast, break things, and plug holes later. This is more true now than ever, when people are vibe coding in a weekend what would have once taken years to build.

The ability to plug multiple holes simultaneously is the superpower of an early-stage operator. But it can quickly become the company’s biggest bottleneck.

The Founding Ops Dilemma

As momentum builds, the intensity multiplies and there is no time to think about what comes after zero.

It’s only when working with newer team members that I’ve realized just how much knowledge I’ve accumulated — about customers, product quirks, or internal processes.

Things that feel “obvious” to me aren’t obvious to anyone else, especially newer team members. The workaround for a tricky feature? The gut instinct of whether a deal is qualified? The Stripe hack I put in 12 months ago to make billing easier? None of it is captured in writing.

And because the pace of growth is moving so quickly, some of the most critical information about the company only lives in my head.

I don't think I'm alone in feeling this way.

Operations is where everything in the company connects: customer feedback to product decisions, sales conversations to marketing material, onboarding questions to new processes.

My instinct has always been to jump in and fix things myself. Customer issue? I’ll handle it. New way to configure a workspace? I’ll figure it out. It's felt faster, more efficient, and more comfortable to do things this way.

But I’m quickly realizing that the “I’ll just do it” reflex is my biggest enemy as we're scaling. In order to distribute knowledge more easily across the company, I’m forcing myself to shift from asking “How do I fix this?” to “How do I help others to fix this?”

It feels slower and more uncomfortable. But I know it's the most important skillset I can build to help the company scale.

It’s worth the extra 15 min

In a day filled with back-to-back calls and competing Slack DMs, spending time on projects that don't have an immediate deadline feels impossible.

But realistically, great knowledge transfer is the most important thing on the to-do list.

The time spent upfront ripples outward to make others more autonomous and it frees you to focus on other work. It’s how you scale yourself and the company simultaneously.

AI makes it easier than ever

Over the weekend, I built a GPT to help newer team members learn how to answer common questions from our customers. I fed it scrubbed call transcripts, help center docs, and various notes from conversations with customers. Basically, everything I could find.

Now, every team member can query the GPT. We all become more efficient and better able to respond to customer with more detail and personalization. Our newest AE can ramp up faster on product quirks, and our incoming support hire will start with context that would have taken months to absorb.

This is just one experiment. But it’s one of countless ways that AI makes knowledge transfer lighter, faster and far more scalable.

Your job is also to make your team stronger

Being a great operator isn’t about doing great work alone. It’s about building the systems so that your whole team is consistently improving.

I’m not spending enough time on this yet. Most start-up operators aren’t. But now, AI gives us the ability to invest less time upfront and deliver more impact downstream.

The real question isn’t whether you have time to transfer knowledge to others. It’s whether your company can afford for you not to.

At Plain, new starters talk to a customer within their first hour of joining.

Talking to customers is the most important thing during the onboarding process – really, everything else can be stripped away in favor of talking to customers. A great onboarding process is both underrated and incredibly important, and the first days and weeks set the tone for everything that follows.

Here’s how we do it for Sales:

Day 1 starts with an introduction to our company vision, mission, history, and performance. Immediately after, new starters join their first demo with a customer, and join several more throughout the day. At the end of the day, they take over their first deal, and learn our sales process.

For the remainder of Week 1, they'll meet the rest of the team, watch recordings of our best sales calls, speak to more customers and shadow more calls, and finally deliver a mock pitch back to the team.

Week 2 is all about support: New starters spend the week working in Plain to support our customers, answering product queries and working with our team, capped off with another mock pitch.

Week 3, new starters start sourcing their own accounts, and doing another mock pitch.

Week 4, they close their first deals and present an account list of new opportunities they think we should go after based on everything they have learned.

This process means 1) learn by doing; 2) get continuous feedback to be able to refine their pitch; and importantly 3) develop a deep understanding of the language of our customers and the problems they face, quickly.

Every few weeks, I'm on support at Plain. We always rota one technical person + one non-technical person. We answer questions, help people get unstuck, deal with bugs. But more than that, we're actually using the product we built. Not just testing it, but living in it like real users.

And with that comes spotting all the tiny papercuts: UI nits, copy that feels off, workflow gaps, oversights where we just missed something.

Here's what usually happens: I'd create a ticket in Linear or drop a message in Slack, hoping someone from engineering would pick it up. Most never get fixed. Not because we don't care, we do, a lot. But, because bigger work always wins the prioritization fight.

This week, I tried something different: What if I just fixed them instead of logging them?

The experiment

I fired up Cursor and started working through issues as I found them:

• Added a keyboard shortcut to Escalations (and updated our shortcuts cheat sheet).

• Made our links actually look like links.

• Added the Teams icon as an option for Views. Something we'd simply missed.

• Adjusted main nav items so they feel like main navigation.

• Fixed inline code blocks so the monospace font aligns nicely with our body text.

• Updated icons and copy to make settings easier to navigate.

• Fixed cursor types that were just wrong for the content you were interacting with.

None would survive a prioritization matrix or even a luke warm discussion about what we should work on. But done in the moment? Quick, painless wins that made the product immediately better.

The real problem isn't capability

Here's my take: Most people are underselling themselves.

You don't need to be "technical" to fix most quality issues. Tools like Cursor mean almost anyone can jump in and handle small improvements. The barrier isn't skill, it's habit.

We've trained ourselves to be problem reporters instead of problem solvers. See an issue? Log it. Hope someone else fixes it. Move on. But that someone else is drowning in bigger priorities, so your small fix dies in a backlog somewhere.

Quality isn't a just design problem or an engineering problem. It's a complacency problem.

Everyone using the product sees the rough edges. Some even raise them. Almost nobody fixes them. We've created a culture where logging problems feels like solving them.

Making it a habit

This isn't about shipping features during support rotations. It's about tiny, obvious improvements that compound over time. Each fix is maybe 1% better. Done consistently over a year, they raise baseline quality in ways no roadmap item ever could.

Here's what worked:

1. Fix in the moment. When you spot something that bugs you, don't log it. Fix it if you can. The context switch of "I'll do this later" means most small items often never get logged let alone fixed.

2. Keep a running list. Not for planning meetings, but for focus. When you have 20 minutes between what you're doing, having fixes ready means you'll actually use that time.

3. Stay small. The moment you're building new features instead of polishing existing ones, you've probably gone too far.

4. 
   

The compound effect of everyone who regularly uses the product actually fixing what they find? That's how you build something that feels great, not just functional.

For a few months our whole team was heads down on one big project: Plain's Help Center.

It was really fun for the whole team to be building together, but with everyone on one feature the rest of the product moved more slowly.

Now that our help center is live, we’ve split engineering into three streams: core, insights, and AI. Each has a roadmap that will take them through the quarter.

This is exciting for a few reasons:
- We’re shipping regularly again. Features our customers have asked for, plus ideas we believe will take the product forward. (Two changelogs already this week.)
- We can show real product velocity in deals. Not by chasing feature parity with anyone else, but features that we really believe are expanding the capabilities just matching what’s out there, but building features that expand what B2B support teams can do.
- We can jump on small fixes daily that our customers love us for

Feels good to be back in the rhythm. 💪