First, let me say that, in just a bit, I am going to criticize. I hope it's constructive. I also hope it's helpful, because I am in the same boat with my own screenshots. And I didn't realize it until WWDC this year.
In the iTC lab, the woman helping me said that every screenshot needs to stand alone in telling the story of the app. Every screenshot has to sell. And the app icon. And the title. And the description. She wanted me to pick one or two (no more) of the best, most compelling things about my app and change everything to highlight or focus on those two things.
She told me that potential customers have to "get it" in seconds. I was to make it as easy as possible for them to understand my app as fast as possible. She even told me what she thought the two things were for my app, which I agreed with, but she only got it after talking to me for 10 minutes.
While I agree the Unread screenshots are bad, I'm pretty sure that neither the gradient nor floating text is the problem. It's that the screenshots themselves are not focused on the one or two things that make this RSS reader worth buying.
There are actually 7 points made, in addition to the testimonial. But no one buys an RSS reader because of fonts, comfort, gestures, themes, sharing, OvershareKit, a testimonial, or even full-screen reading. They buy because they can read articles from their favorite websites. Why should I buy Unread? Not a single screenshot answers that question.
Again, I know I'm tearing into someone else's hard work here. But my own app's screenshots deserve the same criticism. Now that I know better, I hope others can learn from my mistakes.
Marketing an app well is just as hard as building one. I know how to do one and am still learning how to do the other.
I think that's why it's best to know the percentage of the company you are being offered. Share count is meaningless without knowing total number of shares.
Once you know the percentage (say 0.1%), you can figure out some other stuff. Asking about the company's hopes to go public or be acquired, and at what valuations, can lead to a lot of good discussions.
I am also in the 'worked for a number of startups, been paid out non-life changing amounts more than once, and have never tried being a founder' category. What I meant to say is that founders take more risk and get more equity than early employees, and that is how it should be.
Once a company has enough revenue (or investment money) to hire employees, much of the risk has already been removed. A product is either prototyped and tested or partially built. Discussions with potential customers have already taken place. Initial marketing strategies and plans have been made. And founders often do that without getting paid or even a guarantee that they will ever get paid.
They also end up with 10x-20x more equity than an early employee who gets paid a normal salary.
So if equity in a company is highly motivating, and you don't mind working on an exciting idea knowing that you may never see any money, then founding a company might be a good fit.
Or you can make job decisions now that will help you learn to be a founder in the future.
Founding a company is a roller coaster of joy and despair, so it's not for everyone. I haven't tried it yet, but a side project of mine has felt like that roller coaster. I can only imagine that doing it full-time would be the same, except magnified.
My original point was that ignoring equity when evaluating a job offer isn't the best approach.
Most job offers don't include two options to choose from. Since I did have that choice, I evaluated my options exactly as you mention: whether to (effectively) invest the salary difference in exchange for more equity.
In most cases, job offers don't include that choice. If that had been my situation too, I would have evaluated whether the salary was worth doing the job. And then evaluated whether the equity was worth the risk of joining an insecure company.
But since this isn't an absolute rule, I might have tried to negotiate more equity if the salary wasn't quite high enough for me to make the jump. Or maybe asked for extra vacation time, or the option to work from home. (I've done all of those.) I know salary and equity cannot be kept totally separate, but I do start there when evaluating how I will respond to a given job offer.
Telling you total outstanding number of shares is required before you can have any idea what level of equity you are receiving. If they can't tell you that, then you have one problem. If they won't tell you, then you have another. Either way, I would be concerned.
'Seriously, the difference between "last founder" and "first employee" is so huge that people who can derive their day to day motivation from equity should be founders.'
I don't think it negates my point. It's just that I don't follow my own advice perfectly. :)
It's also a little similar to how founders essentially work for free in exchange for lots of ownership. If, as an employee, I can work for less money now, then I'm taking a bigger risk betting on the outcome of the company.
Startups often want to minimize cash flow, and some employees are interested in helping out with that in exchange for having more ownership. So it works for both sides.
But I try to keep "doing the job for salary" and "taking a risk for equity" separate in my mind.
Equity = compensation for taking the risk of working at a company with a high chance of failure
Therefore, in the future, an employee with lots of equity should still be paid a normal salary/raise/bonus because the equity isn't "current" compensation for doing the job, but a reward for taking a risk long ago.
But ignoring equity entirely is silly. Much better to say that you should consider salary and equity separately. One is for doing the job and the other for doing it now when uncertainty and the possibility of failure are high.
Also, some people (like me) would trade an increase in equity for a smaller salary, so it's not a perfect separation. I had a job offer once that gave me two options to choose from, which was really cool.
Yes. Especially when someone else mistyped their email address, you did not ask for confirmation, and now I get endless emails without the ability to sign out. So I just mark everything as spam, which I know isn't what you were hoping for. :)
In my case, I had 30-100 clients taking turns trying to transfer a those files across the network. The difference in total time to complete was often measured in hours.
No, though I do think a synchronous API is easier to work with. It isn't synchronicity that is slower. There are lots of socket-level options and buffer allocation options that need to be set up right for raw data transfer to go quickly. And the API needs to make it easy to avoid copying arrays of bytes. And I do have benchmarks for those.
When I first implemented this class, I was upgrading a file caching client that talked to a custom file server. It kept about 80,000 files (about 16GB) in sync with the set of files on the server. The unoptimized Mac process started out about 40% slower than the Windows equivalent client. Afterwards, the Mac client was about 15% faster than Windows with no changes on the server. They couldn't get the Windows client to transfer as quickly as the optimized Mac client.
Could these optimizations be done in an asynchronous API? Sure. But as far as I can tell, none do. Maybe because they don't work directly with sockets. Normally that isn't a problem, unless you really need to push things across the network as fast as possible.
I really liked this article. More generally, I think deliberately choosing to do the "hard" things first (whatever that means to you as an individual) has served me well in life. I wish I did it more often.
At a former company, in a large group setting, I was asked to identify what I thought was the biggest roadblock to the company's success. I hesitated to comment because I knew my answer would be controversial. But, taking the bull by the horns, I answered, "Fear." I felt (still do) that when people are nervous about their careers or how they will be perceived, then they tend to censor themselves, sometimes without even realizing it. If the company took a deliberate approach to making the company a safe place (safe to disagree, safe to take risks, etc) then it would be a major benefit and help improve both morale and performance.
The CEO immediately disagreed. She didn't like the idea that any of her employees (200+) might be feeling some form of fear. Trying to address an issue like that is hard because it implies that high-ranking employees and "leadership" types were acting in a way that caused fear. It didn't even have to be deliberate or conscious. She would've had to do a lot of soul-searching, a lot of questioning the actions of her direct reports, many of whom were friends, and a lot of listening to frustrated employees.
I think it's pretty common to avoid hard things. So I try to tackle the hard things first. I think I learn more and it gets me out of my comfort zone. And the benefits are normally much greater too.
In the iTC lab, the woman helping me said that every screenshot needs to stand alone in telling the story of the app. Every screenshot has to sell. And the app icon. And the title. And the description. She wanted me to pick one or two (no more) of the best, most compelling things about my app and change everything to highlight or focus on those two things.
She told me that potential customers have to "get it" in seconds. I was to make it as easy as possible for them to understand my app as fast as possible. She even told me what she thought the two things were for my app, which I agreed with, but she only got it after talking to me for 10 minutes.
While I agree the Unread screenshots are bad, I'm pretty sure that neither the gradient nor floating text is the problem. It's that the screenshots themselves are not focused on the one or two things that make this RSS reader worth buying.
There are actually 7 points made, in addition to the testimonial. But no one buys an RSS reader because of fonts, comfort, gestures, themes, sharing, OvershareKit, a testimonial, or even full-screen reading. They buy because they can read articles from their favorite websites. Why should I buy Unread? Not a single screenshot answers that question.
Again, I know I'm tearing into someone else's hard work here. But my own app's screenshots deserve the same criticism. Now that I know better, I hope others can learn from my mistakes.
Marketing an app well is just as hard as building one. I know how to do one and am still learning how to do the other.