Not just beta invites and email promotions, but also emails to advisors and early investors. It's more than just a reminder of what the heck you do, it's also handing them language to talk about your business to other people.
For beta users, advisors and early investors - these people are going to be your advocates. You need to give them the tools to advocate for you, and a well crafted 3 sentence elevator pitch that describes your business is a huge help.
>> Matters of face, allegiances, and frankly who's in a bad mood on what day determine outcomes as often as logic.
This is so true. Matters of face can spiral out of control easily. I think you handled this specific one with real dexterity.
One related thing from my own experience - As groups grow you tend to get moments where the community norms that everyone took for granted can't be assumed anymore.
It always starts with a single person operating outside those norms. You're faced with the question of whether you have a one-off situation, or a systemic problem (of which this one moment is just the first inkling). Knowing which approach is the right one seems like it's frequently gut feel, but then again, if you know that you are going to need process or guidelines soon, you can use see those moments as an opportunity to get things right before you get bigger problems later.
What Dave doesn't mention in this post is the mindset he brings to these meetings. Honest, open, generous, no time wasted, and he's completely direct. Regardless of how you got to the table, you end up having a super high value discussion because of how he approaches the time.
The fact that he gains so much from these later is no surprise to me. What he gets back later on is just a big karma circle finding its way back to him.
That's the same way I got to know everyone I now consider friends and advisors when I moved to San Francisco without knowing anyone. I agree that coffee dates with brutally honest people are the best - they may sting a little but I've learned more from those who don't sugar coat their advice than those who try to spare my feelings.
Having met Dave personally I can say he is one of the most humble and dedicated people I have ever met. His mix of characteristics ensures that opportunities dont slip by unnoticed or undone. Coffee meetings seem like the perfect avenue for him to do what he does best.
Well written automated tests will accrue value over time by saving you manual testing time (and increasing your confidence) with each release.
A lot depends on your situation at launch, but I think a lot of teams overestimate how much testing they should do, when in fact their bigger issue is not having enough customers, or not engaging their customers with a decent product.
If you have time, my suggestion would be to focus on a few items:
1) Notification tools to help you know when something goes wrong (e.g. email to the dev team). If you are using ruby, then http://hoptoadapp.com is a great tool, but if you can't find a tool, write your own. It's worth it.
2) Monitoring tools to know if the site is down (e.g. pingdom)
3) Figure out how to cleanly do site updates with zero downtime. This will let you fix the inevitable bugs without inconveniencing users who haven't hit the bug yet.
4) Write automated tests for the things that you think really can screw your users the most.
5) Develop a culture that, when you find bugs in production code, you write tests to reproduce them, then fix the bug, then use the test to validate the fix.
Great article, and fun to see what is going on inside. We used a similar strategy with great success at my last company (though we were using Passenger).
Once you've nailed the zero-downtime deployment, it's a short hop to adding a small box (or a script on your test server) to do continuous integration and then moving from there to continuous deployment. For our small team this setup was really liberating.
If you head down that path, I'd love to see updates on what your team's experience is with that transition.
The code is simple to understand, self contained, based around rake, and worked almost immediately for us (after some configuration). We were a two person team. I don't know if the setup we had would have worked with a larger team.
It felt like it made an impact in our ability to turn code faster. We had a solid test suite, which helped.
I'd like to hear your thoughts on how the iPad doesn't lend itself well enough to Enterprise.
I have nothing specific in mind that disputes your assertion, but the linked article below says this, which sounds meaningful - "80% of Fortune 100 testing/deploying, 366 documented mass rollouts."
I'm also hearing that Microsoft views the iPad as a potentially disruptive force in the enterprise, though that is second hand.
Sure, they are deploying them, but only because nothing really fits the bill better, and often because their users beg them for them as toys. My wife has a director-level title at a large biotech. Some of this comes from her experiences. Here is where it falls short:
Most large businesses have a variety of native windows apps they rely on. The ipad works well as a web browser, but misses all of these. Companies have large investments in these programs, and having them inaccessible is a liability for the ipad. As an example, I have seen business units literally "powered" by excel spreadsheets and VBA. The iPad can't deal with things like this.
Standard native file access. How do I open a config file with "notepad" in the iPad? How do I browse to the file? What app opens it?
Windows permissions. The iPad can't work with Windows file system permissions, so it is a second class device on Windows-based networks, if you want to access files, it does not play well with your carefully created Windows permissions, so those access rules and group policies are lost on it.
The iPad is not a part of the standard microsoft security apparatus, so it is "special" in this regard. It won't get Windows updates, security bulletins, etc in the same way. It needs special attention from IT, and carries separate and perhaps unknown security risks.
Since the iPad is oriented toward finger-touch, stylus apps don't work well, so note taking apps don't work well.
The app store is consumer and game oriented, something businesses would specifically like to avoid on their devices, generally. Because of the app store approval process, and low price point expectations "Enterprise" business apps are loathe to move to it and risk a heavy investment that could be arbitrarily destroyed.
The iPad's success in the Enterprise is really a result of a failure of imagination and execution by Apple's competitors.
We adopted continuous deployment at my last company, and it was a huge win for us. It resulted in less downtime, reduced the cognitive load on our developers, and let us turn changes and bug fixes faster, which just made everyone happier. Here is the approach we took --
We got continuous integration working first by setting up an automated test server. We used cerberus, which is a trivially simple ruby gem that simply polls a repo, grabs code, runs tests, and reports the result. You could install this anywhere, even an old Mac mini if you wanted. We spun up a low end server for it. We wrote great tests, got decent coverage, and made adjustments in our automated testing strategy to increase our confidence.
Then we worked on zero-downtime deployment and rollback. This was actually the hardest part for us. With regard to schema changes, if we had to hammer our database (new index on a big table) then we needed to take the site down, but otherwise our strategy was to always add to the scheme, wait for the dust to settle, and then remove things later. This worked for us, but we had a relatively simple schema.
I haven't quite figured out how an ajax-heavy site would pull this off. That seems like a hard problem since you need to detect the changes and refresh your javascript code.
We then combined these two to get automated deployment to a staging server. We could have written monitoring code at this point, but we decided to punt on that, relying on email notification for crashes and watching our performance dashboard.
And finally, we set it up to deploy to production, and it just worked, and we never looked back. It was the most productive and pleasant setup I've ever worked in.
Regarding ajax heavy applications, I have been faced with that particular problem. A few of my sites are javascript heavy apps, with long flows between page reloads. If I ever change my server API in a way that would break the javascript, I need to signal to the client that it needs to refresh. (I keep track of version numbers for the server code, and whenever that is bumped, it means the client is out of sync)
This can be kinda.. awkward. What I've opted either a lightbox or some kind of message saying we need to refresh the page. But that is not ideal.
Has anyone dealt with this issue before? With javascript heavy apps, the development is more like a traditional desktop app, or a mobile app that has to deal with the client/server model interface in a non-trivial manner.
I've been doing continuous deployment (multiple production deployments per day) with an ajax-heavy application and have been doing a sort of rolling API change, where both the client and the server still function using the last generation's contract, so I rarely get a client request that the server can't deal with, or send a response that the client can't deal with. It doesn't work with every kind of change, but it has helped me.
Something that you could do (and I may wind up doing) is just having the page ask the server if it needs to refresh itself every so often.
I haven't directly but I just happen to be staring at Pivotal Tracker which handles it pretty nicely. The do as you say and push a little lightbox which says "A system change has occurred requiring a refresh of this page.
Please click 'OK' to reload Tracker."
I think how Gmail handles the problem is they keep multiple instances of the server-side software running, one for each version of the API. From my experience, whenever GMail rolls out a new feature, I don't see it until I do a refresh and frequently that's what GMail tells me I need to do to see the new feature.
Strongly agree (to both this and webwright). The package that felt strongest for us when hiring was to have amazing talent that other people want to work with, hand over significant responsibilities to new hires, and provide an environment that people are excited to come to work in. That doesn't mean that recruiting is easy, but it sure makes it easier once you have found the people you want.
The numbers you quote look in line with what I would expect, especially if you are getting close to a market rate salary. They are profitable and funded, which is a big milestone. It would help to know - Are they paying you a market salary? What is your past work history like? Does it include startups, and if so, in what role? How great is the rest of the team you are joining?
The Mark Suster link mentioned by brudgers is solid. My suggestion is to examine your motivations and goals, and then to be true to them. It will also help you evaluate your progress against those goals.
I'm going to presume this is your first startup, so these comments may be wildly off base if it isn't. The things I got out of my first startup were these:
(1) Money (we actually went public, though I had a very small piece of it).
(2) Massive rapid skill development in circumstances where I could take on as much responsibility as I wanted and could learn from great people.
(3) Connections to people that pretty much set me up for almost every job I had after that.
The value of (2) and (3) were huge. If I could give advice to my younger self it would be to focus on those two things first, then negotiate the best financial outcome that I could after maximizing those elements.
I mentioned I'd be getting a bit higher than market salary. I've worked on my own startup for a few months until my co-founders split, and I was unselected for a seed incubator program as a solo founder (no big surprises here). The rest of team is pretty much being built, but they are seriously taking into consideration Sequoia's tips (which is referred from pg's lib http://ycombinator.com/lib.html): http://www.sequoiacap.com/ideas
For beta users, advisors and early investors - these people are going to be your advocates. You need to give them the tools to advocate for you, and a well crafted 3 sentence elevator pitch that describes your business is a huge help.