Hey there, Rian here (Head of Product at Postmark). We definitely understand the "mixed feelings" response for an acquisition like this. A couple things I want to reiterate:
* The entire Postmark team is joining ActiveCampaign, and we are going to continue to operate the way we have always operated for the foreseeable future. That includes the support team you love!
* We definitely don't plan to change any of the things we do to ensure the highest deliverability in the industry. We are not, for example, making any changes to the manual approval process—that will definitely continue.
> The entire Postmark team is joining ActiveCampaign, and we are going to continue to operate the way we have always operated for the foreseeable future. That includes the support team you love!
While I appreciate you saying this, you have to have in mind that just some 6 months down the line it won't be you calling the shots. The business priorities will be determined by other people and they can and will command you to shift your policies as they see fit.
I want to believe but history has shown, time and again, that these pledges never materialize.
It's OK, you are feeling relief because you likely received a huge sum of money. Who wouldn't be happy!
There's a proverb: "Never promise anything when you are feeling happy".
Oh I am sure they 100% believe it. I wonder why people always forget about the power structures. I guess that's what happens when people work what they love and money is just a positive side effect... as opposed to this being exactly the opposite for 99% of the other population.
I think you often forget about this because promises are made that they won't touch anything. So you're being genuine when you say "nothing is going to change" because that's what leadership promised.
Trying to maintain this is a major fight that generally gets you fired or you end up leaving out of frustration.
It's hard to see if when you come in with business like Postmark that is loved by its customers because you think "We're a great business and we know how to do things, why would you want to blow that up?" but you need to remember that the acquirer (ActiveCampaign) is looking out for themselves (ActiveCampaign) first.
Postmark product manager here, so I'm a little biased but... yes we are! You can see our Time To Inbox stats on our status page: https://status.postmarkapp.com/
Thanks for the heads up. You guys do a good job on documentation. A little redundant on the marketing side, but overall very clear. That migration guide is very well-done/thorough.
> On the other hand, postmark is a bit more flaky - I track delivery RTT and had had a few cases in my first year with them where Postmark had > 30m delays
Postmark product manager here... I'd love to know more about this. We publish our Time To Inbox on our status page: https://status.postmarkapp.com/
The only time emails might sit for longer than a few seconds is if there is some issue with the account (such a accidental spam being sent due to form abuse). If you have specific examples, can you please email support@postmarkapp.com and we'll look into it for you?
> although I find their API a little too slow to move everything over to them
Postmark product manager here... I'd love to know more about this. We publish our API response times on our status page (https://status.postmarkapp.com/), so this is a surprising comment. Can you email support@postmarkapp.com with your account details and we'll look into this for you?
To clarify for the benefit of any onlookers, I do not mean to say that Postmark's API is slow absolutely, but that it is slow(er) for how we use an email sending API relative to SG.
Our email system is custom and does all of its own merging on a per subscriber basis, so we send a distinct request for every email, so even an otherwise minor difference between a 30ms and 85ms round trip "feels" slow at scale. I believe PM has a "batch" call available, but this requires some extra dev time at our end if it would resolve our issues (and it may!)
I will get in touch, though, in case there are ways to help mitigate this problem or if the batch mechanism will solve it all. We have previously encountered similar performance issues with SG from time to time due to DNS sending us to unsuitable endpoints, etc. so it can be a universal problem to some extent based on how we've approached the problem.
(Edit: Actually, that status page maybe demonstrates what I'm talking about, since the average API response time shown is 437ms. Even with 5 concurrent threads that would take 2.42 hrs to send 100,000 emails - so I am guessing the batch API is the way to go with PM :-))
Hey everyone, I'm the product manager at Postmark, and it's great to see all these stories. I'd love to find out a bit more about how y'all use the product. I can definitely send some T-shirts and other swag your way as well. If you're interested in telling your story, reach out to support and tell them you came from this thread! https://postmarkapp.com/support
Hi, I'm the product manager on Postmark, and wanted to chime in with a bit more of our rationale for mostly using shared IPs. With our exclusive focus on transactional email and high deliverability, an existing reputation is extremely important. By using shared IPs customers can leverage our reputation, which we police and protect heavily. And since transactional email has better engagement overall, it increases our deliverability even more. Most senders don't need dedicated IPs since an IP with no reputation is worse, so we believe it's better for the majority of our customers and their deliverability to use shared IPs.
That said, there is a case to be made for very large senders to have their own IPs. We agree with that. Our point is mainly that the vast majority of senders don't need it, and should rather use the stellar reputation of our shared IPs to ensure good deliverability.
The "as well off" phrase refers to "being equally compensated". So the absolute utility "number" remains the same. In order for that to happen, a decrease in the contribution that commute has on utility, needs to be compensated for by an increase in the contribution that one of the other factors (salary or rent) has.
