timfalls

I completely agree that the magic exists in the real, genuine human connections, the satisfaction and impact of selflessly helping others, and the act of inspiring someone to further reach toward their full creative potential. (see: http://timgrid.com/fuck-leads-generate-relationships/)

After five years of doing the community/evangelism thing, and much resistance to tracking/measuring my/our team's activities, I'm finally /gradually coming around to appreciating the concept of collecting data and performing analytics on community efforts.

The key, IMHO, is to focus on metrics that really matter, as opposed to devoting resources to surfacing meaningless ("vanity") numbers for the sake of having numbers. (see: video of a talk I gave on this topic here: http://devguild.heavybit.com/developer-evangelism/)

I believe that it's up to us to figure out how to measure the impact we have as evangelists/community professionals, because other people (coworkers, investors, partners, etc) will always demand some insight. And if we don't figure it out for ourselves, they'll try to figure it out for us (and, logically, we're better positioned in this regard than those who don't spend their time doing this stuff.)

So, in light of that, we're catalyzing a collaborative project to help figure it out together: https://github.com/keen/dashboards-dot-community.

Since we'd been working on the concept presented in the Github repo linked above, I was super excited to find Jonas's project (hence my share here on HN.)

I'd love to continue the conversation! @panbanda, maybe you'll join us on Github to provide your additional perspective?

If you're in to learning from the best, you've come to the right place - really helpful/valuable/legit insight from folks who are really good at this stuff.

Enjoy!

super stoked for this team. trajectory: upwards and onwards.

@rdl our blog isn't really where we'd like it to be right now, in terms of theme, performance optimization, etc. we're actively working on an improvement there. thanks for sharing this additional data point (ie, poor experience on ipad 3). stay tuned for an improved experience in the future!

thanks to @getsat and @potyl for providing some insight to their experience with SendGrid. we appreciate the testimonials!

the discussion around managing email in-house vs. paying a 3rd party to do it for you, is of significant complexity, as is evidenced by the length of the original 37sig post and this comment thread.

i think it's important for each and every company to evaluate their own unique situation - the needs of their product, the resources at their disposal, the role email plays in their overall business model, their relative experience/expertise in email vs. other elements of the customer experience they are building, the maturity of the company/product, etc. it would be very unwise to make a decision on this type of matter, based solely (or predominately) on factors like "successful company X does it this way", or "successful company Y does it that way."

every company is different, and they often face this specific decision at different junctures in their life cycle.

the most useful lesson that can be gleaned from this conversation (which i've really enjoyed following), is this: as a business leader, entrepreneur, developer, etc, you have options! if you want to do it yourself, it's possible -- if 37signals can do it, so can you. but if you don't want to do it yourself, or aren't confident in your ability (for whatever reason), then there are several awesome companies out there to choose from, each of which has its own strengths and weaknesses, which puts you in the position to select the most ideal solution for your unique circumstances.

that's all :)

couldn't agree more with the other comments: awesome promo video. awesome event. one of the few conferences i attended last year from which i walked away thinking, "i am definitely coming back next year."

thanks to @raghus @KenCochrane and @SePP for sharing their experiences with sendgrid. just wanted to chime in and point out 2 things: we offer an inbound Parse API for receiving email into your app (http://bit.ly/oA2GA7) and offer pay-as-you-go pricing similar to SES and a free plan that allows 200 email/day (http://send.gd/o1fNtT). for what it's worth, based on my discussions with developers around the world, postmark and mailgun are solid solutions that would likely fit the needs described in the original post here.

thanks,

tim

We believe in our service and the premium value it provides over competing services. We have our sights set on long term success and plan to continue our leadership in the industry. Your comments here are awesome, and we welcome further feedback at any time - on these topics and any others you want to bring up. We appreciate the supporters and detractors, because all perspectives must be taken into consideration in our efforts to continually improve. Contact us directly (email, chat, phone, twitter) or just keep on having your discussions here on Hacker News - we're listening ;)

--Tim Falls, SendGrid

You're dead on with that interpretation :)

What bothers us is that you are "not a really happy [customer]", yet your reasoning is understandable. Your website issue is covered above in our response to @krobertson. With regards to Email Activity Search: we’re working on making this feature more stable (we’ve brought on a new web architect to help as well) - also, we probably should have released it to a private beta group for testing first. We will be taking a new beta testing approach going forward (planning it now for our new newsletter app). For Heroku: we're close to having a fresh API integration with them, which will be a huge improvement. Future, similar integrations with other hosting services will be much better with a seamless integration process for them and their users. It’s a top priority item for us.

We certainly didn't mean to come across as arrogant - just confident. While your frustration on the pricing structure is understandable/reasonable, we don't have immediate plans to make significant changes. If there is anything else we can do to earn your loyalty, we'd be grateful to hear what it is.

We recognize that documentation is of utmost importance for a service such as ours. In most cases, a lack of documentation is intentional and reflects that we are working on improving existing docs or writing the original content. All we can say is that this will get better and better over time. Your feedback/suggestions are always appreciated.

We truly believe that deliverability is where we win - it's been our focus from day one. We've learned a lot about it (and continue learning every day), and we use the lessons to serve customers better. While we're confident in our practices that help with deliverability (namely, dedicated IPs), we can't jump to conclusions - so we'll just have to wait and see how SES customers fair in this area.

1) We're aware the credentials thing - it's a problem, and we're working to resolve. Here is a community discussion with more details: http://send.gd/CLf

2) We do our best to monitor blacklists and proactively notify customers as soon as we detect their placement on an RBL. We also recognize that some RBL information may get past us in certain instances. To address this, we're increasing support staff by 66% next Monday. Finally, it should be noted that some RBL's are legit, while others are, frankly, scams and exist for the wrong reasons.

3) Some things we offer to address this issue: set your own policy for bounce removal and remove them as often as you like; disable bounces so that we don't track bounces at all; get bounce notifications - as soon as the bounce occurs, you can remove it over our Web API.

4) This example could be account specific (please contact [email protected] so we can look into your account and work to debug). However, it could be more general - we realize our website is far from perfect and are working daily to make improvements. We invite any and all bug/feedback/feature reports so we can investigate, address, and deploy the fixes and enhancements that are most important to users.