Interview with Newsletter Glue’s Lesley Sim

I talk with Lesley Sim of Newsletter Glue about open source product management and building a product on Gutenberg.

Lesley Sim avatar

Lesley Sim is the founder of Newsletter Glue, a plugin that allows you to build and send a newsletter from directly inside your WordPress site – and the block editor. She not only understands what it takes to bring a product to market but also has a lot of experience building a platform on top of the Gutenberg project.

Beyond that, however, Lesley is also one of the most interesting people thinking about some of my favorite topics: managing open source software, ideas like the “Tragedy of the Commons” and the “Free Rider Problem”, open source governance, and how we can see WordPress thrive in the face of fresh competition.

I took this opportunity to chat with Lesley about some of these topics and more.

I’ve been exploring some of the community’s ideas for making sure that the WordPress project is as successful in the future as it has been in the past. One of the ideas that stuck out to me is something I’ve heard you say: WordPress needs a ‘product manager’. WP Engine just hired Ezinne Udezue as their Chief Product Officer, so the job position is clearly meaningful at large tech companies. Can you explain what a product manager for WordPress would be?

Crudely, a product manager helps decide what to build and how it should be built.

In many small companies, the role of a PM is undertaken by the CEO who might consider themselves the head of product. But as a company (and a product) expands and matures, the CEO can’t keep track of all their other duties, as well as make every single product decision. Hence, PMs are hired to do the tricky job of prioritising what to build.

A PM’s role is vastly different across companies based on their culture and org structure. Also, the larger the product, the more pieces it can be sliced into and the more PMs are needed.

Broadly, a PM is charged with considering:

  1. How a new feature furthers the goals of the company (and the particular product it sits under). For example, if WordPress decides to build a paid plugin directory, the imaginary PM in charge of this project should consider how it furthers the goals of the WordPress project to democratise publishing. So this PM might have to consider how a paid directory that puts allegorical barriers around plugins might harm the overall goal of WP.
  2. How a new feature works in concert with other existing features. For example, if we had an imaginary PM in charge of the block editor and an imaginary PM in charge of the WordPress admin, they would have to work closely with each other not just to avoid building conflicting features, but to ensure the features they’re building are greater than the sum of their parts, and improve the overall experience of the CMS.
  3. What users want from a feature. For example, if we had an imaginary PM in charge of block themes, they would spend lots of time talking with theme developers (from amateur devs just tinkering on their own site, to professional theme shops, to agencies and freelancers who build themes for clients) to find out what was missing from the old way of building themes, what they want from the new way, and more.
  4. What is feasible based on current resources, constraints, and timelines. For example, if we had an imaginary PM in charge of blocks, they would need to know what  contributors they can rely on for building out new features around blocks, the timelines available, and past experiences in building things for this problem space. If the next release is in a month, and there’s only 1 designer and 1 developer available, then it’s unlikely they can fix 50 bugs and launch 10 new features.

They would likely map all of this out, then spend lots of time convincing and coordinating across the organisation, with external stakeholders, and within their own team, to ensure the right things get built. After a release, it will also be their job to help conduct a review, which helps everyone improve, and in turn, make the next cycle even better.

Realistically, WordPress is not in a position to magically hire a hundred PMs at a super granular feature level because it takes time to train and build up the PM function (although, WP is certainly large enough to need it). However, I do think it would help if there were PMs in charge of:

  1. The block editor
  2. The WP admin
  3. The WordPress repository
  4. The WordPress website
  5. Plugins
  6. Themes

There’s probably a bunch of other obvious stuff I’m missing out on at this level of abstraction. I’d love to have more discussions with people around how they’d slice and dice the WordPress project into PM portfolios.


I remember seeing you talk about this before and I wrongly used the term ‘project manager,’ which is a completely different job. What’s the difference between a ‘project manager’ and ‘product manager’?

Project managers are used in simpler environments where the scope is extremely clear and there are unlikely to be surprises. Hence, the main concern is to get the job done on time. For example, at an agency that builds simple marketing sites for doctors.

Product managers are used for more complex and ambiguous work. Hence, the main concern is making sure the right thing is built given multiple stakeholders and constraints. For example, developing software products where a feature that seemed like a simple 2 week job, might actually end up taking 4 months due to unforeseen dependencies.

There’s some concern about WordPress’s ability to ‘manage’ this entirely new product: Gutenberg, or the block editor. Historically, developers build on top of the WordPress platform because of how easily extensible it is, but Gutenberg has been less popular to build off of for a number of reasons. 

You own a popular plugin that very deeply uses and extends the Gutenberg editor – how has that integration process been for you as a third-party developer?

It has not been straightforward. There’s a huge lack of documentation around the block editor. Having said that, I know this is something that is actively being worked on.

The other issue is big UX/UI changes or big new features that get built that override other things. For example, the reusable blocks UX in 2022 is vastly different to the reusable blocks UX in 2019. Most of the time the changes are good, but they are frustrating to keep up with. I wish Gutenberg would hurry up and become stable.

We’re now 5+ years in, and we’re still nowhere close. I think there’s a 55% chance (I made this number up for drama reasons. Don’t hold me to it.) it might be stable in another 3-5 years’ time. But a 10 year wait for software is not reasonable for consumer software. Not forgetting, just because it’s stable doesn’t mean it’s good yet. And then, once it’s good, you need another 2-5 years for people to adopt it. I worry that 15 years is too long and too many people will have left WordPress by then. 15 years is certainly enough time for a new dominant CMS to arise.

I think significant work has to be done on an organisational level in order to materially change the current trajectory. Hence my suggestion for PMs. Other ideas could work too.

 I’m just projecting forward based on my current experience. I could be completely wrong. That would honestly be great. I’m not trying to be a hater. My livelihood depends on this too, so I’d very much like for WordPress and Gutenberg to be awesome.

I feel the same way about the overall timeline- even when I’m criticizing Gutenberg it’s because I want it to succeed faster, I want to be able to justify using it on projects. As it is, I definitely do a lot of website ‘cleanups’ where a previous developer went all in on Gutenberg, but now nothing works and visual changes take a lot longer.

Let me share this tweet (please ignore Allie Nimmon’s original tweet. My tweet has nothing to do with hers.)

But I do want to bring people’s attention to this. Instead of constantly trying to give problems an economic label, can we just shift the focus to how best we can solve it? Spending so damn much time giving it a name is just a distraction.

In my mind, here’s what we need to do:

1. Build an epic contributors job board
1b. That has ways for any company to just pick a position and sponsor it
2. Make it a GAZILLION times easier to contribute

And here’s what we never need to do:

  1. Talk about tragedy of the commons
  2. Talk about free riders

I agree completely and just wrote that conversations about the “Free Rider Problem” are just not helpful.


Switching gears: You recently removed your free plugin from the WordPress Plugins repository. There’s a great twitter thread here that I recommend people read. So, if you were starting now – would you still do the free plugin to get off the ground or skip it entirely?

I don’t think I made a mistake by listing the plugin on the repo. My mistake was the way we architected the plugin and what features we put in pro/free.

If I were starting today, I would skip it entirely to begin with, but architect the plugin so that it’s possible to list it if we ever wanted to.

If I were talking to a friend going through this,  I would encourage them to list their plugin on the repo as a default. But ultimately, I think you have to look at each case (the plugin, the market they’re in, their target customer, and so forth), and then have a more in depth conversation with them around:

  1. What they want to get out of the repo
  2. Make sure they understand how the freemium model works so they’re getting the most out of it (no point in buying a kettle if you just want to use it as a pitcher).
  3. Make sure they have a clear plan for what goes into free vs paid
  4. Make sure they have a clear upgrade path
  5. Make sure they have a go to market plan

I’ve definitely seen that idea come up a lot recently- that many developers have cool ideas for plugins, but don’t have a “go to market plan” when they want to start making money from it.

Along the lines of making money- and to reference something you brought up earlier- if WordPress offered an official, managed app store (similar to iOS) for premium plugins where they took maybe 15-30% of the money but handled all of the transactions and license keys and you were more ‘discoverable’- would you be interested or skeptical (or both)?

Definitely interested. The current plugin biz model and infrastructure isn’t great. It seems like super ambitious people who want to build billion dollar companies in the WP space should become hosts, not build plugins. And for less ambitious people looking for the most direct and least risky path to becoming a multi- millionaire, building a high end dev agency is a surer and simpler way to achieve that. I’d even go so far as to say building an affiliate site is a less risky way to become a millionaire than building plugins.

People should only build plugins if they genuinely love building plugins more than building a hosting company or agency (which is a hard and very specific thing to know). And if they’re willing to play a long term game with high risks and fairly high rewards. These are generalisations, of course…

I don’t think an open source project as big as WP should take 30%, ever. Full stop. Where on earth would all that money be going to?!

I would be upset if WP took 15% in its current organisational structure. I think there is significant responsibility when that amount of money is involved. I’d want to see clear governance, roles, responsibilities, and how that money is distributed. I’d want quarterly reports. There needs to be a way to regulate the regulators. For example, if a plugin reviewer kicked me off the paid repo, my income crashes  overnight. If I want to dispute this, I need to be able to point to regulations and say this reviewer was in violation of it and that I did nothing wrong.

I’d be okay if WP took 1-3% in a slightly improved organisational structure, and did a hand wavey “this is 5 for the future” and 100% of the money earned from the paid repo goes directly to contributors who build and maintain it. There would still need to be governance, documentation, and a way to manage and distribute the money. But I would be significantly less upset with the messiness because I’d be able to see that none of the volunteers are earning that much from this.

Side note: I don’t think “discoverability” is something that will improve just because the directory is now paid. If anything, they will probably try to focus the conversation around monetisable.

I like your idea of an app store also raising money towards 5ftF. I could see an 8% fee – 5% for WordPress plus the transaction fees- being more reasonable. The 30% number came from the iOS App Store, which I don’t think anyone considers a reasonable number.

But your larger point about where that money goes is important. We just don’t have the transparency and governance in place, which is already something that deters a lot of people from contributing anyway.

In a completely opposite direction- did you consider offering Newsletter Glue as a SaaS option- something that’s fully hosted and positioned more as maybe a direct Substack competitor?

A SaaS option? – Somewhat… We’ve been thinking about this almost from day 1. It is tricky to balance ambition with resources and ability. And also there’s testing in the market, which takes time.

Yeah I think there’s more to dive into there, so hopefully we’ll have a chance to chat again.

I recommend readers follow Lesley on Twitter @lesley_pizza to learn more about her work over at Newsletter Glue.

Author Profile Image

Brian is the Technology Director at Understrap and Howard Development & Consulting. Located in Southern California, Brian is a former college instructor and full-stack developer who brings his unique academic perspective to Understrap Academy. Brian is a graduate of California State Polytechnic University Pomona and California State University Fullerton. His work has included projects for Harvard University, The World Bank, and the Colorado Department of Public Health and Environment.

Subscribe & Share

If you liked this article, join the conversation on Twitter and subscribe to our free weekly newsletter for more 🙂

MasterWP contains no affiliate links. We’re entirely funded by the sponsors highlighted on each article. In addition to MasterWP, we own EveryAlt, WP Wallet, Understrap and Howard Development & Consulting.

Latest Posts