I use it I am pretty happy with its. Of course in theory no company need to exist, but what do you propose people use instead?
Example: Go to the homepage and see how many clicks it takes to find out the simle question of "When am I on call next?"
I’ll mention to our AWS and Azure TAMs.
(Thesis: it’s a supporting product not a whole company)
Scheduling is more complex than just an IAM list: there are escalation policies, the actual phase of the schedule, dealing with additions/removals, overrides, and not to mention the entirety of routing pages for which PD's solution isn't even powerful enough for our needs … because the problem is more complex than they bargained for! Not to mention the telephony & mobile integrations, which are still lackluster, the desire to be able to have some things not page on weekends, etc.
I sort of do acknowledge that, yeah, this does seem like a place where AWS could easily kill PD by just offering their own version and leveraging their weight as a cloud provider. But they haven't, so that doesn't really matter to the person you've replied to.
Open source for some, reasonable alternatives of a commodity product for others.
Putting strawmen in people's mouths doesn't make for a good argument.
That is HN's version of "No wireless. Less space than a Nomad. Lame."
But ask yourself this: PD has competitors that provide messaging and schedules and cost less than PD. So even if they aren't free, why are customers paying more for PD? It's not like they don't evaluate 2-3 products before choosing PD. They are choosing to pay more, so there's more to their decision than just "What's the cheapest way to notify people when we get a signal from monitoring that something's amiss."
PD is an enterprise-grade process augmentation and automation tool wrapped around notifying responders about incidents. And wrapped around that are layers of what pg called "muck," functionality that accommodates the needs of enterprise-grade customers like permissions, integrations, teams, analytics, AIOps for filtering noise and resolving things that don't require human intervention and so on.
That's not special, it's how all "Enterprise" software works. At its core is something that people on HN will regularly boast they could code up in a weekend, a long weekend at most, and they're not wrong. But wrapped around that simple core are layers of functionality that accommodate how large companies manage the activity mediated by that core.
I don't want to spark a long debate about PD's value, I urge you to see this as a pattern that applies to a lot of software that is sold B2B: The value is in the stuff around what appears to be the primary value proposition.
If HN readers want to get into the Enterprise software business, embracing that pattern is mandatory: You will generate most of your economic value by taking an idea that at its core isn't that hard to duplicate, but wrapping it in accommodations for the baroque and sometimes-dystopian org structures you sell into.
> PD is an enterprise-grade process augmentation and automation tool wrapped around notifying responders about incidents.
This is a good argument.
> But ask yourself this: PD has competitors that provide messaging and schedules and cost less than PD. So even if they aren't free, why are customers paying more for PD?
This is not a good argument. Businesses make tons of non-optimal purchases. Research is hard, and salespeople are convincing (and might be talking to a different group than the actual users).
At some point, you look at a company with a couple of hundred million or billion or couple of hundred billion in annual revenues, and you can't dismiss all of that revenue as "non-optimal." A better characterization is that "optimal" often looks different for an enterprise than it does for an SMB than it does for a startup than it does for a consumer, and within each of these segments there are sub-segments with different definitions of "optimal."
I am not saying that buying PD or any other enterprise product is always optimal, but at the same time, I am saying that it cannot be dismissed as some kind of reality-distortion field that mesmerizes customers into overpaying.
---
But again, whether PD is overpriced or not is far less interesting on HN than understanding what goes into a successful "enterprise" SaaS product for those startups who are directly pursing enterprise customers or may need to pivot from another market to enterprise.
It's not just hiring convincing salespeople to sell the easily replicable obvious value proposition, it's actually all that stuff wrapped around it.
Sure I can. Oracle is awful.
Yes … when the sales are wheeled and dealed there's enough Enterprise-grade bullshit shoveled about for me to start a fertilizer business. But that's not a.) what I care about as an engineer who has to use PagerDuty, and b.) time and again, I think we see upstart competitors whose products is actually better than the dominant player finally get enough mindshare among actual users that the tide turns against the incumbent and "everybody uses $X" stops working.
I don't have to "embrace the pattern" to understand how the game is played, and thus be able to successfully navigate the space. But boy oh boy would it be nice if that weren't necessary.
It would be a better advertisement for PagerDuty if you were concerned about improving the product. (Or, at least feigned such, which is what many businesses seem to do.)
And absolutely things are chosen by dart toss. PD has inertia: it's well known, and the product isn't terrible. And I don't know anything better yet — so I'd choose you again, but that "yet" is key to any future competitor. But people believe the marketing, and nobody does the research necessary prior to adoption: the research is, for these things, equal to the work of actually migrating onto the platform: it is only by migrating that you find out where you've made assumptions about how paging works that don't match PD's. Marketing pages are too shallow to discover such things.
At the risk of an appeal to authority, I have been in the enterprise technology business since the late 1980s. I have held position in sales and marketing before my current career in engineering. In engineering I have had roles on both the IC ladder (I am currently a Principal Engineer) and the management ladder (topping out as a Director of Engineering).
I don't regard this as a game we play for the purpose of bamboozling stupid customers into overpaying for software. I think that's a remarkably poor perspective on how business works, very similar in my mind to calling all Apple users "fanbois." It's a way of dismissing a large and complex equation that encompasses complex organizations, individuals within those organizations, various tradeoffs and aggregations of value, and so on and so forth.
Reducing it to a simplistic take that it's all about marketing bullshit is low-effort and contributes nothing to anyone who wants to enter this space or survive if the economics of what they build indicates--as it did with companies like DropBox and 1Password--that they need to pivot to enterprise.
Everything you are saying that drips with contempt for enterprise SaaS business, is also expressing contempt for their customers. I do not hold our customers or those who buy from our competitors in contempt, I admire them all: They have built businesses that advance technology, grow our economies, and employ people (modulo the current climate for employment).
If you want to model the world as companies picking products with a dart toss, that's your business. But I'm not dignifying your position, I think it is absolutely not a foundation for success selling into these markets.
Their examples of follow the sun model seems pretty straight forward to me.
https://support.pagerduty.com/docs/schedule-examples#:~:text....