Product Thinking in Practice: The Choices Behind Synced Pattern Popups

Every time I want a popup in WordPress, I run into the same fork in the road.

On one side, I can vibe-code a bespoke solution. It’s fast and works for this site and this exact context. On the other side, I can install a large popup plugin that brings along a custom UI, its own mental model, and a lot more machinery than I actually need.

Both options technically solve the problem, but neither feels quite right.

This article starts with that tension and ends with a small plugin called Synced Pattern Popups. But what I really want to share is the thinking that happened in between, because that’s where the difference between “a solution” and “a product” shows up.

Synced Pattern Popups

Author(s): Matt Cromwell

Current Version: 1.3.1

Last Updated: January 29, 2026

Direct Download

100%Ratings 10+Installs WP 5.8+Requires

The plugin owner’s journey

If you build plugins, this is a journey through the small but significant decisions I made to turn a utility into something closer to a product. The choices I made once I stopped treating a popup as a quick website feature and started treating it like something other people might rely on.

This isn’t a product launch post so much as a decision log. I’ll show you how each choice forced me to think one step past “does this work?” and toward “will this help someone else succeed?”

Choosing a third path instead of two familiar ones

I didn’t start out wanting to build a popup plugin.

I wanted a simple modal to be triggered by a text link on the WP Product Talk site. Ideally it should be built with blocks I already use. No new builder to learn or custom popup blocks. No separate UI to wrestle through. No abstraction layer that pulls me out of WordPress.

I could have vibe-coded that in an afternoon. I’ve done it many times before, and I’ve written about how effective that approach can be when paired with modern AI tools.

That approach is great for momentum, but it doesn’t age well.

The second I imagined someone else using this, updating it, or depending on it six months later, it changed my perspective and goals. I decided I didn’t want to only solve my problem, I needed to solve the problem the way a product creator would – holistically and with mass distribution in mind.

I decided to ship a product to the Plugin Directory. Again. I hadn’t done that in years and years on my own. But truthfully, considering the stage of my current pivot in my career it felt like perfect time.

Let me tell you how it went.

Using WordPress primitives on purpose, not by accident

I had already decided that I just wanted a group of blocks to appear in a modal. But how? Should I create a hidden block on the page? That would lead to orphaned blocks all over a website that needed to be updated one at a time. That sounded terrible.

But once I thought about a centralized place where a group of blocks could be listed and managed and edited the answer became clear: Synced Patterns.

Synced Patterns already exist in WordPress core and are pretty amazing, honestly. They centralize content, keep it in sync across a site, and let you edit once without hunting down every instance later. Core has been deliberately expanding patterns from layout helpers into real content primitives.

If you haven’t followed that evolution closely, these posts explain both the why and the direction clearly:

• Synced Patterns: The evolution of reusable blocks
• Advancing the power of patterns

There’s also a really great and growing public Pattern Library on WordPress.org that is a great resource for creating compelling modal content.

For popups, synced patterns are ideal. They already solve the hardest part of the problem: a single source of truth for content that appears in many places.

Choosing to leverage Synced Patterns made all the next decisions more clear and straight-forward. Product thinking often looks like demonstrating restraint, choosing what already exists instead of making users learn something new or foreign to their experience.

Making core features easier to use without replacing them

The problem with synced patterns, though, is that they’re powerful, but they’re not easy to find.

Depending on your theme setup, synced patterns live in different places, behind different URLs, and sometimes behind entirely different concepts. Even in full site editing, there’s no obvious place that says “these are your synced patterns.”

At this point, I could have built a custom editor and fixed the UX completely. Many plugins do exactly that. Instead, I decided to try and make what’s already there easier to reach without inventing something new.

The result was a simple custom settings page under Appearance → Synced Patterns. That page lists the existing Synced Patterns but also became my hub for all my settings. When you click on a Pattern, you go straight into the Core experience, editing your Pattern in the block editor. Editing stays core so the mental model stays intact.

The exit path mattered too. Leaving the pattern editor drops you into a generic list table screen of your Patterns that feels disconnected from the rest of the admin. So I added a clear way back.

These are small decisions, but they shape whether something feels thoughtful or sloppy over time.

Thinking like a Support Technician

Taking a support technician’s perspective forces you to consider all the ways a product can go wrong. That mindset is a huge asset to product creation because it pushes you to design escape hatches before users need them.

Caching is a good example. Transients are fast, private, and a solid fit for modal content. They also guarantee confusion eventually if you don’t plan for failure.

So I treated cache failure as inevitable.

When a pattern updates, its transient clears automatically. There’s also a way to clear a single popup cache or all of them manually. No mystery states. No “try disabling everything.”

Script loading followed the same thinking. Ideally, scripts load only when needed. In reality, AJAX content, embeds, and unusual rendering paths break assumptions. So there’s a per-post setting to force loading, plus a filter for cases where that still isn’t enough.

This is what support-driven product thinking in the WordPress environment looks like in practice. You assume something will break and make sure the user isn’t trapped when it does.

Building like a developer who cares about UX outcomes

This project was also a chance for me to learn.

I wanted hands-on experience with the new Abilities API, to leverage WP-CLI in ways I hadn’t before, and modern extensibility patterns. Learning is part of the job, and I feel like I’m learning with playback set at 2.5x with AI. It’s been amazing to accomplish and learn so much in so little time!

But product thinking means learning without making users pay the cost.

One fun optional I feature I baked in is an AI-powered TLDR that depends on the AI Experiments plugin. The moment I introduced that dependency, I knew I’d have to own the experience of requiring another plugin; which can be cumbersome for users. Instead of a dead toggle or an error message, I guide the user visually through installing, activating, and configuring what’s required. Only then does the feature unlock.

That flow took longer to build than the feature itself. But I think it was 100% the right move for end-users of this plugin. Users shouldn’t need to understand your architecture to benefit from your ideas.

Thinking like a website visitor, not an admin

Accessibility shaped a lot of decisions here. Focus management, keyboard navigation, screen readers. Making sure closing a modal returns you exactly where you were. Popups don’t just affect admins. They affect real people reading real pages.

I won’t claim perfection, but every choice was made with the assumption that someone else’s experience mattered more than the elegance of the code.

If a popup disrupts someone’s flow or traps them, the product failed, regardless of how clever the implementation is.

Acting like a Product Owner, not a guest

Product owners aren’t just thinking about UX, code architecture, or avoiding support tickets. They think about adoption, growth, and net promoter scores. How is this product going to become something that puts food on the dinner table?

A small part of that is engaging with users. So I knew I should launch with at least one way for users to engage with me; but I wasn’t going to build a whole website for this product.

That reminded me of an old piece of code I built a long time ago: Delayed Admin Notice. It’s a way to create a customize admin notice encouraging users to give your plugin a positive review, ideally after they’ve had time to use it and decide they love it.

Context matters. Timing matters. Opt-outs matter. This is where many “simple” plugins quietly fail their users. Not because they’re malicious, but because no one thought past the launch moment. This code snippet helps make all those “admin nag” questions more principled and user-focused. But it needed a ton of re-writing – so I did that too! And a fun post about that experience is coming soon too.

Product ownership means assuming you’ll still be accountable to these users a long while after your first release; so put intention into how you engage with them positively.

Are you a vibe coder, or a product creator?

This plugin could have been smaller. Faster. Easier to ship.

But every time I considered a shortcut, I asked the same question: does this make it easier for someone else to succeed?

That’s the question that changes your whole approach. When you think about your code making someone elses life easier, your litmus for “good enough” changes completely.

Vibe coding is about solving a problem quickly. It optimizes for momentum and personal satisfaction. It’s useful, and I still use it often.

Product creation is different. It’s the discipline of making smart, scalable decisions at every level of the user experience, with a constant focus on ease of use and helping users achieve their goals.

That mindset shaped every decision for Synced Pattern Popups. Choosing synced patterns instead of inventing a new system. Making core features easier to find instead of replacing them. Designing caching, script loading, onboarding, and in-plugin asks as if someone else had to live with them long-term. Individually, these choices are unremarkable. Together, they’re what shaped the whole product experience.

That’s the difference between vibe coding and creating tools that people trust and will open their wallets for.