Going in, I thought I had some idea of what I was doing and what I was in for. I mean, I’d been at later stage startups and heard the stories. I’d read the Eric Ries Lean Startup book. I had read all of the “blogs you’re supposed to read” and had them in my RSS reader so that I could soak up collective wisdom regularly.

In some ways, I was right… in others, I was wrong. Here’s a non-exhaustive list of things that are sticking with me after a year. That said, if you’re reading this because you’re thinking about or planning on joining a startup at an early stage, there’s a good chance you’ll have different ones that are important for you 🙂

Hiring is the single most important thing you can do. Good hires amplify everyone around them and make the team smarter and more effective. It’s pithy and everyone says it. But they say it because it’s true.

Hiring takes way more time than you think it will. Your network (and your network’s network) is the best way to source candidates. You’ll post your positions on various job boards and you’ll very very very occasionally get lucky with it. Recruiters will come from everywhere promising great results but will take up even more time since their candidate flow is way higher. Another challenge with recruiters is that when you are before the launch of your product, it can be difficult to convey what you’re doing as well as exactly the type of person you are looking for to join the team.

Fancy new technology is sexy and fun to work with. It also has a lot of problems you don’t have experience with. If you can minimize the number of these you have to deal with, you’ll be able to spend more time focusing on building the right product for the right problem

It’s hard to spend too much time talking with your target customer. If you think that what you have (be it a mockup or a prototype or something else) is “ready” to show to them, you’ve probably waited too long and could have gotten feedback already and learned something

Fail fast. Some things you try won’t work. Don’t continue to fixate on them and sink more time on them if they’re not coming together.

If you’re building something that’s a B2B product, think of your beta as a chance to test selling in addition to the product. Sure, you’re not going to have them pay today but you do want to know that you’re building something that people will pay for when you’re ready to switch to that.

Think iteratively. Once you start to hone in on a degree of product market fit, you’re going to discover that some of the things you built for prototyping/testing purposes don’t work. Don’t be afraid to replace them. But do so in a way that lets you regularly checkpoint the replacement to test that you are making things better. Grand rewrites are rarely as grand as you think and always take longer

If you’re going to spend a lot of time on something product-side, focus more on getting the interfaces right than the implementation. So, for example, if you decide that something is going to have clear boundaries passing messages over a queue, then you can switch between RabbitMQ, SQS and others with minimal effort as you learn the constraints that actually matter for your implementation.

Try to find the one piece of your product that immediately pops in a demo for most of your target users. This is one of those things where you’ll know what it is when you see it. And then use it as a hook to start drawing people in.

Interactions with the customer don’t end when they sign up for your product. Continue to nurture them and do regular feedback calls with them as you iterate on the product. This will help to make them into advocates for your service and they’re already bought into your vision making it

Bugs happen. Fixing them and providing awesome customer service is a great way to foster great customer relationships

It’s been a wild and crazy year but I have had a blast. I’ve done a bit of everything and learned things I didn’t even know there were to learn. Launching the beta of our cloud monitoring product a few months ago was an awesome experience and watching as we’ve started ramping up our sales engine to engage with customers and try it out has been phenomenal. And I’m really looking forward to the next step of launching the paid product and starting to track everything that goes along with that.

Here’s to the next year and many more after that!

Share this:

Although I haven’t really talked about it here, I joined a new startup a couple of months ago called Stackdriver where we’re working on building a hosted solution to make infrastructure monitoring and management suck less for users of the public cloud. After a having to duct tape the various pieces together a couple of times now, it’s super clear that the need is there so it’s exciting to be working on solving it. More on the side of being at a very early startup to come in the future.

Today I had planned to do some work around some of our provisioning and deployment code and Amazon had another EBS outage making the AWS API pretty unavailable for much of the afternoon. So after doing some other things, I took a look at what fails along with EBS to help us remember what fails along with EBS and thought it was interesting enough to share.