Snippets

If you're not doing support, you don't actually know your product.

Support isn't just about fixing bugs. In my experience at least it's *the* best way for myself and the whole engineering team to stay close to the product and our customers:

* You build product intuition by seeing what users struggle with, where they get stuck, and what they keep asking for. That context feeds directly into better decision making, prioritisation and feature work

* Gaps in observability become painfully clear when you have to debug an issue yourself. You spot what's missing fast, and you can't just throw it over the fence to the next person. This week I learnt how hard it is to debug email deliverability issues (I'm not sure there's a solution for this one yet)

* You naturally build better systems. When you've been the one chasing down flaky behaviour with no logs, you start writing code that's easier to debug

* You learn how much tribal knowledge is buried in long lost Slack threads and engineer's heads. Support shifts are forcing us all to write better documentation and pay it forward. I've merged about 5 pull requests in the last week titled something along the lines of "being a better citizen"

* You get better at knowing what matters. Support gives you a sense of frequency and impact that's hard to get from metrics. It's one thing to read a roadmap, it's another to help shape it

From my experience, this feedback loop is pretty much impossible to achieve if you're not talking to customers on a weekly basis, or knee-deep in Cloudwatch logs debugging cryptic issues.

If your teams aren't doing this.. the genuine question is: why not?

After 4 different interview styles in only 2 years, we finally found a frontend interview style that's been working for us. The frontend 'system design' interview. Here's my blog post on why it works and how we got there.

Reflecting on three highlights from a great first week @ Plain!

🎯 Interview vibes confirmed → The authenticity I felt during my remote interviews has carried through in to the day-to-day here at Plain. High expectations not just met, but genuinely exceeded.

🔧 Developer experience, front and centre → Joining a team that genuinely values DX as a competitive advantage feels great. With Alex Barlow dedicated to improvements and the openness to feedback, it's clear it is core to our culture (check out Matt Vagni's post on plans for DX).

⚡ The "Aha!" moment → By the start of day 2, my dev up was fully up and running, allowing me to jump straight into meaningful work on the upcoming release of Help Centers, thanks to great onboarding from Andrew Blaney, genuine trust, and clear code patterns.

Despite proudly positioning myself as the office filter coffee nerd, I quickly revealed myself to be a total espresso noob when pulling a shot in front of Simon Rohrbach → a post for another day, here's to week 2!

Not to brag, but... At Plain, our hit rate for the features we’ve shipped actually delivering value to customers has been higher than anywhere else I’ve worked.

I’ve worked at a lot of startups but they've all approached how they 📐 shape, 🔭 scope and 🧱 build in much the same way. At Plain, we've been doing things a little different. Here's how:

Your team ships features fast, but customers aren't biting. You add a product manager to coordinate better, prioritize smarter, move faster. Six months later, you're shipping even faster - and customers still aren't excited.

Here's what's happening: you're optimizing for delivery when you should be optimizing for signal.

The traditional Design ↔ Engineering ↔ Product Manager triangle was built for coordination but this isn't where early-stage teams lose speed. They need something different to move quickly: direct customer signal flowing to the people building the product. In my experience, real momentum comes from a different triangle: Design ↔ Engineering ↔ Customer Success or Sales. Here momentum doesn’t come from managing work. It comes from understanding who you’re building for, why it matters and then making decisions together, fast.

The wrong tool for the right job

In the classic triangle Product managers would set the strategy, manage stakeholders and coordinate the work both across teams and between disciplines within the same team trying to keep everything on track. But more than that, they act as a filter becoming a sort of switchboard, the person you’d route all questions, context, and decisions through.

Sometimes that’s helpful. But it does take away autonomy and agency from people who are already capable of doing much of this for themselves. In a world of increasingly product minded Designers and Engineers, they don’t need a filter. They need clear, direct signal from customers to make will informed decisions. That's how good teams move fast.

The alternative

The work doesn't disappear when you remove the PM from the triangle, it gets distributed differently. Design and Engineering teams are more than capable of roadmapping, prioritization, and defining success. In early-stage teams, these decisions don't need a dedicated coordinator; they can live where the work happens.

But capability alone isn't enough. The bottleneck isn't capability. It's distance from the problem. When teams get direct customer signal, the thinking and doing happen in the same place. Decisions move from guesswork to conviction.

Design and Engineering can and should bring themselves closer to customers, spend time run customer research calls, join a sales or onboarding call, giving customer support for a week but they can't do that all the time so...

You need someone whose full-time job is being close to customers: Sales, Success, or in the earliest stages a founder doing founder-led sales. These are the people having real conversations with customers all day, every day. They know what customers are asking for, what they’re trying to achieve, what’s working, and what’s hurting.

Importantly, they're not responsible for delivery and they're not there to run the project - that still sits with design and engineering. Their value is in bringing continuous customer signal directly to the team building the product. They act as a real-time sounding board, pressure-testing ideas, validating assumptions, and ensuring the work actually addresses customer needs.

How this can fail (and how to make sure it doesn't)

This is how we run product at Plain and we've seen it work but when you remove the traditional coordination layer, new failure modes emerge. Here's the mistakes we've made and how to address them so you can avoid them for yourselves:

1️⃣ You lose the signal

Design and engineering start to rely on instinct (or it's evil twin, ego). You ship fast, but the work doesn't land. Your hit rate drops. Customers aren’t excited.

The fix: Make signal a habit, not a project. Shadow calls. Share work early and often both with Sales & Success and directly with customers and refine it together.

2️⃣ Your customer voice gets stuck in the corner

You have someone talking to customers but their insight never makes it into the Product. There's frequent things being shared in Slack but there's no action taken on them in the moment. Maybe no one knows what to do with the feedback, maybe it just came at the wrong time. Whatever the reason, the signal doesn’t flow and the product team flies blind.

The fix: Customer success or Sales needs to be present where decisions are made. That's in standup, at project kick-off, in the doc where design and engineering are shaping a project and setting the scope. Make sure they see your prototypes and v0's before you send the work out to customers.

3️⃣ Nobody’s bringing it over the line

The team knows the problem. The solution is scoped. But things aren't shipping. Everyone’s doing their part, but no one’s making sure the parts come together. Without someone accountable for momentum, good ideas stay half-built

The fix: Make ownership explicit, someone from engineering or design needs to set clear, deliberate scope and do the work a PM would traditionally do to keep things on track. This model spreads product thinking, but it still needs people to lead and push the project through.

A new shape for product teams

Removing the PM from the triangle doesn't eliminate structure - it redistributes it. Design and engineering handle the coordination work, while customer-facing roles amplify the signal that helps them make sharper decisions and move faster.

Customer signal flows from everywhere - Sales calls, Success conversations, founder-led sales, support tickets. But having someone whose full-time job is being close to customers helps separate signal from noise and brings the most important insights directly to the team building the product.

In this model, everyone builds, everyone listens, and everyone owns the outcome. Customer-facing roles don't manage the process, they supercharge it