Comment by billyhoffman | Hacker News Reader

Comment by billyhoffman | Hacker News Reader

Nice job getting to launch. However I'm really confused about the value prop.

> There's no point competing in that noisy market, so we're undercutting it instead, by treating developers as first-class citizens.

Who is the target market for this? who are the users and what is the job function in their company?

The vast majority of CMS use is by Marketing departments building the public web presence of their company. Marketing doesn't care about building or maintaining their own CMS, or making it easy for developers. In fact, those are costs they want to minimize and externalize.

Speed of creating, editing, reviewing, and publishing content is the most important thing. Integrating the site into the hundreds of mar-tech tools is also important (e.g. gating content for sales leads, funnel analytics, mailing list signup and validation, A/B testing, etc)

Large CMSs are pretty optimized for the create-review-publish flow, and I don't see you explain any advantage you provide here. Mar-tech companies live or die on adoption, so they invest heavily in making plugins for CMSs. Something they are not going to do for Payload. Why would marketing pay for internal developers to do this integration (regardless of how easy it is) when they get that for free with plugins to existing systems, written by the engineers of those systems?

In short, none of the benefits you cite at all align with the KPIs of a marketing department using a CMS (typical engagement numbers like time-on-site or page views, but also marketing-generated or marketing-influenced leads and opportunities)

And as an engineer who has built multiple SaaS apps, I've never needed CMS capabilities built into those apps. The closest need would be the help/documentation/API spec, which we've traditionally addressed using another site or SaaS app (e.g. a third party helpdesk or knowledge base SaaS).

Hence why I'm a little confused, but do want to be positive. Who is your ideal customer, why, what business problems do they have, and why is Payload the best option to those problems?

Hey, great question. Our target market is enterprise uses of Payload, where we can power critical content-based infrastructure, but that does not solely mean marketing websites.

I think that your comment is pointing at one of the areas that traditional CMS -do not successfully address- in that CMS is typically only thought of as a means to manage website content. But content is much more broad. Think of Spotify (managing album art, playlists, artist descriptions) but using that content through native apps, smart TV apps, web apps, etc.

For example, some of our current enterprise clients are using Payload to deliver _their_ clients with a customized copy of Payload to manage their own virtual events (attendees, webinar links, landing page content, post-webinar video recordings, etc). Or to manage a "broadcast platform" where their client can publish their own Roku channel (episodes, series, seasons, playlists, etc). This is all content, yet it's not marketing page content.

One of the bigger uses of Payload so far has actually been to power the entire backend for an Uber-like snow plow service, where the business side can log in and provide customer support, manage requests, approve service providers, and more. The devs were able to leverage Payload's auth, access control, hooks for Stripe integration, and last but not least - the entirety of its admin UI.

That's not to say that we -can't- power marketing websites. Of course Payload can do that in spades. But that is only one small aspect of our target market and we make the most sense for enterprise content needs, where dev teams may need to manage more than just marketing pages. Maybe they also need to manage customer support resources or more intense content needs (like Klarna).

In my experience implementing enterprise websites for large companies, the buying process usually goes like this:

- Director or VP of Marketing says we need to modernize and move to a better web stack, let's go headless

- They start to evaluate options, but need engineering backup because headless CMS is a tech decision

- They tell their engineering team to go find the best headless CMS

- Devs do the recon, then report upward

Our strategy is to appeal straight to devs, and by being a solid product that they can advocate for, they will. This is actually how Klarna found my agency when we were hired to build their enterprise site - by the engineers. Decision to go headless came from the top, but then engineers found me and selected tech. Same with a few of Payload's bigger inbound enterprise opportunities in the pipeline right now.

Long story short, I fully understand your question and in all reality our messaging is nowhere near sharp / completed. We've seen a lot of growth over the past few months and are about to the point where we can take a breath, revisit some of this, and razor-sharpen our positioning!

This guy CMSes.

I worked in consulting for many years doing a lot of CMS projects for Fortune 500s. They always bought their CMS products based on the marketing pitch to marketers. It was mostly bs, but the pitch was always focussed on engagement, testing, analytics, funnels, acquisition. I always came with the perspective that your CMS need not and usually should not be responsible for any of that and you can manage all of that in the application tier via a tag manager product or the like. The current kind of this space is Adobe. They built up their "Marketing Cloud" vis a series of acquisitions and sell it as a fully-baked product that does everything you'd ever need and then attach an 8-figure price tag and hand you off to integrators (like the companies I worked for) to do the (also very costly) implementation. And it's really very hit and miss to get adoption after you've delivered them such an ornery beast to manage 30 pages of brocureware.

We managed to push a few clients towards Contentful which is headless and a lot more dev friendly but they also are pretty sneaky with pricing and get fairly expensive with anything beyond basic usage. I actually begged their sales team to do a better job selling to marketers because their pitch was too tech focussed. I think the sweet spot is to not just say "developers like it" but rather "it will require far fewer developer hours to implement" which will resonate a lot more with budget holders. Also, my firm belief that building a suite of marketing tools by picking and mixing the best products is likely still easier and cheaper than buying any all-in-one tool that isn't great at anything.

I resonate a lot with what you're saying.

> I always came with the perspective that your CMS need not and usually should not be responsible for any of that and you can manage all of that in the application tier via a tag manager product or the like

Totally agreed. A CMS should stick to managing content. And its flexibility should allow it to integrate with services that are purpose-built. In addition to those that you mentioned, a good example of this would be Algolia for search experiences.

> "it will require far fewer developer hours to implement" which will resonate a lot more with budget holders.

I also resonate with this, and I think this needs to be worked into our positioning more, because that, at its core, is what Payload tries to do -through- its developer friendliness. When you don't have to fight your software, you save an incredible amount of time. At the core of any larger content infrastructure is code, and the more efficiently you can implement it, let alone maintain it, the more time / money you can save.

Inbound developer interest = company intent (and segment intent).

Just make sure your growth motion doesn’t stop there and layers in a way to nab the buyer.

Standard way is to outright ask for introduction or outbound, but there’s usually a clever referral mechanism you can discover somewhere.

e.g. “Ask your marketer for demo content” prompt, but with better copy.

100%.

This is very good insight and I will take it to heart.

Hacker News is amazing because there are so many confidently wrong people.

Ever hear of contentful? https://www.crunchbase.com/organization/contentful

Or the entire category of headless CMS (A $600m/yr market growing at 20%+/year), for which eng is a primary stakeholder in the buying decision?

Agreed! Do you have a favorite CMS?

(offtopic side note in case anyone is confused: I edited out that line you quoted. launching these guys was a last-minute thing this morning so I've been editing their blurb on the fly, from airplane wifi no less. I hope it worked!)

(this does not affect your question)

Reply on news.ycombinator.com