Hacking SaaS #13 - Startup Things

On security, product and culture at early stage companies, and other useful links for SaaS developers.

Security

Companies have two security problems - building secure products and making sure the company itself has enough security. This newsletter typically focuses on secure SaaS products (naturally), but other security aspects matter just as much.

Since most developers aren’t trained for this, and knowing how much security is needed vs way too much is hard, I really appreciated this handy guide for security in startups, clearly written for developers. I don’t agree with all the recommendations, so don’t take it as a sweeping endorsement. Some choice quotes:

Welcome to the company! We’re here to change the world! Before we start moving fast, we need to make sure you don’t cause a massive security incident and flat line the company’s productivity for a few days.

I realize that if I mess up this next section, I will be compromised and blamed for all of our data leaving the barn. That means that I need to please, please(!) pay attention to this list in front of me and not switch tabs and read reddit for at least one minute.

Any systems I design or am reasonably involved with will have centralized & read only usage logs designed for others to look back on a security incident. I am fully aware of how terrible the nightmare would be if the company had a breach and had no records of what actually happened.

Culture

An oldie-but-goodie post from Rands on how company culture changes after shipping its first version:

The reward for shipping 1.0 is a deep breath. Whew, we did it. In the days, weeks, and months that follow shipping 1.0, the work is equally important to your success. But you never forget the moment when you consider the product done, because you are intimately aware of the blood, sweat, and tears it took to get it there.

… the act of shipping 1.0 creates an internal threat as well. The birth of 1.0 initiates a split of the development team into two groups: Stables and Volatiles. Before I explain why this rift occurs, let’s understand the two groups.

It was written in 2012, when SaaS was still a bit new-ish. You know that because they talk about “shipping 1.0” and not “publicly available MVP”. But in my experience, even in today’s startup culture of shipping small MVP early and rapidly iterating, there is still the same cultural tension.

Product Management

Startups typically have only engineers, and PMs are hired relatively late (as late as series C at times). So for a long time you need to build a product that customers love without the product managers, and need to create process and culture around this.

At our company, we were working in interdisciplinary teams with people in Engineering, Design, Business, and Marketing. Since we didn’t have a full-time product manager, some things were different from operating in a traditional product development setup for building tech products.

We installed three building blocks:

 Extreme Ownership

 Decentralized Product Processes

 Strong North Star

And if you find yourself in this situation, or are transitioning to a product role, you may want to read this 12-part series about creating a product strategy (this isn’t startup specific, and a lot of it doesn’t make sense for startups).

One of the biggest product traps for a startup is relying too much on customer feedback. Yes, you need to listen to customers all the time, but how to listen, what information to listen for and what to do with this information is important.

My first UX design job was at a SaaS startup. As in many startups, the main challenge was finding product-market fit, and as in many startups, the strategy was to ask companies with deep pockets what features they would like us to build for them.

What easier way to get “validated” insights than to get the customers themselves to tell you? Now we can just build it and watch the metrics and revenue go up.

Except it didn’t work out that way, for us or for anyone else. After a few “user-centered” releases like that the CEO soured on the entire concept of research. Users don’t know what they want, he said, because we built it and they’re not paying for it.

If you want more in-depth and detailed framework for incorporating user feedback into design, this article on contextual-design is not a light read but has a lot of useful models.

More Things

One of the things that makes a huge difference in quality of life for an engineer is their relationship with their manager. A mistake that junior engineers often make is to hope that if they ignore their managers, the manager will go away. Staff and principal level engineers are usually really good at partnering with their engineering managers. This blog focuses on the part of the relationship where managers ask a lot of questions about work in progress - it explains why these questions come up, how engineers can help, and how managers can help in return

It can feel bad to admit that you’re having trouble with something, but tasks usually aren’t hard because you’re “slow” or “bad at your job”. Usually it’s because there’s something concrete that’s making it hard. Identifying what that thing is and telling your manager about it helps them a lot!

And last but not least, over on the SaaS Developer Channel, I talked about zombies in distributed databases and how to avoid them.