Was aiming more towards some real ones :)

I wrote it on my spare time and based on my experience. Nobody proofread it and it's a takeaway for next time. I posted it on HN since I like HN, that's all.

Don't worry about some asshole picking apart stuff. Your writing is clear enough that if someone has a hard time parsing it - that's their loss. I've been in Saas for over 10 years helping sales and marketing teams convert and close at higher rates. The article hits home for several tech founders who understand customers but don't understand prospects. The post captures some learnings that many other people never ask or dig into - but make all the difference. Thanks for sharing, I've shared it with several people who will not think this is obvious - and they won't need to "pickup a standard book" to learn some snippets.

Question: how much better does the salesperson perform compared to your previous attempts? How long will you give him to prove himself?

SaasTr is a great sales resource if you're looking.

I don't have clear numbers on conversion rates before and after, prospects were from different segments and we kept changing our pricing and offer during that time to find the right fit so it's hard to measure. Before we brought him in we said we'll give him 3 months but it was clear we have a lot to learn and benefit after 3 weeks.

I used to be more of a grammar nazi but in my old age I came to view with suspicion emails or texts that are written "too perfect." It signals a person who has too much time on their hands or allocates their time poorly, and is insecure about letting a few mistakes through.

I easily understood that sentence first time I read it and so did 'mreiland'. Don't mind these silly comments.

HN users have already said it, but if it helps at all, we (I'm a moderator here) sure hope you won't let a nasty comment like that bother you. Plenty of non-native English speakers write excellent articles and comments for HN. What matters is the content.

Don't worry, the text was perfectly understandable. Great read!

Your English is good, but not good enough. If you're going to continue writing these articles in English, find a native speaker to proofread for you.

If you start getting your stuff proofread, my "asshole" comment will have done you more good than any of the touchy feely bullshit you've seen elsewhere in this thread.

Emails and everything sent to customers were always proofread by a native english speaker. I wrote this on my spare time but lesson learned for next time.

Here's a little bit of constructive advice. There are several places where you've made a "comma splice" error. That is, a comma (,) was used when a period (.) or semicolon (;) should have been used (or alternatively, a conjunction could be used). Example:

> We’ve interviewed a bunch, during one of the interviews after the candidate was done presenting, he looked at me, I looked at him, he did OK …

This should be instead:

> We’ve interviewed a bunch. During one of the interviews after the candidate was done presenting, he looked at me, and I looked at him. He did OK …

Note that punctuation applies to other languages as well.

Sure, the grammar needs a little work but this sentence is the only glaring issue...

> He then asked this question “How is a typical call with a prospect looks like?”

Should be "How does a typical call with a prospect look?"

Also - great article! I've worked in sales and emails never worked, especially in this day and age of constant spam. Email is great for an info blast, but you will not close with an email.

My 2 cents: Fix the major issues on this article sooner than later. It is a great little post and if all goes well it will have a long tail of visitors or will get picked up again for a nice exposure spike. I think that makes it worth your time. Of course that is just my opinion.

You should absolutely be taking ohfunkyeah's advice, as in today. This is a great piece with some good ideas and good learning being shared, but the poor quality of delivery severely hampers their usefulness.

I noticed a couple of grammar mistakes but nothing major. Thanks for the article! I appreciated the tips.

That's for employees, it's not the cap table, it's equity compensation. Where is the investors equity?

This is actually sort of a content ad for changeagain.me

Smart move by Changeagain to integrate with Google Analytics experiments since everyone uses GA but GA experiments is nearly impossible to use.

Yeah! We improved interface, added visual editor as well as Google API helps us to bring our customer brilliant data accuracy ;)

"untrusted" is the issue here, and trust is built over time. In the meanwhile you can use the library and implement the server side.

You can only use JSOP and CROS with sites you have control over or are designed to behave and support external requests. It makes it very very limited!

"You can only use JSOP and CROS with sites you have control over or are designed to behave and support external requests."

That's kind of the point.

It limits the thing you can do. This library allows you to easily get and display content from any external source.

Those limits are a security measure to protect against XSS and CSRF. Intentionally weakening your site security isn't a good idea for most people. Your mash up site evidently uses this to get around same origin policy without the cooperation of targeted sites. It would be interesting to know how you plan to mitigate those risks.

It's just your cross-origin traffic, which is not possible without this library, everything else will behave exactly the same.

And whoever is running this proxy will _promise_ not to log any sensitive information (API keys not the least) or otherwise use/modify the response for their own ends?

Not to mention that the API endpoint is HTTP only, meaning everything is broadcast in the clear.

Also, cross origin requests are perfectly possible without this library, it's precisely why we use JSONP and CORS.

When it comes to security, this library is a collection of anti-patterns. As well as the JS anti-pattern of not overwriting native objects, such as XMLHttpRequest in this context.

Why? remember your product will function exactly the same. It just makes more thing possible.

No, it will not function exactly the same, because it sends stuff through your server. That is a very important difference.

Leaving my front door open when I'm on holiday also makes more things possible. That does not mean I will like those things.

If you are working on super sensitive website for the NSA, I totally agree. YOU SHOULDN'T USE IT.

But if you have a blog and you would like to constantly display some specific content from a different webpage via ajax it seems like the easiest & most simple solution.

Don't take me wrong… I would use your service in any proof-of-concept/mockup/prototype… It really helps a lot in those use cases, since is one less thing for me to worry about.

I just don't trust it enough to use in production.

There is a level of trust needed. However, you can use this library, change the proxy url and implement the server side yourself.

I don't doubt that your service works with the best intentions, but why should I open a security hole in my application, when I can easily avoid it by writing my own proxy and keep it private?

What happens to my application, if your service goes through a DDoS? What happens to my application, if you suddenly decide to close your service?

I'm pretty sure you can use these arguments about other services, but this service exactly, is not worth the risk.