I’ve been thinking recently about how product companies are built from zero to initial launch. Everyone loves to focus on success stories, but most startups still make many of the same mistakes. I would generalize it and say they sell out their future to gain a short term benefit. Here is a grab bag of different things I would do with a product that is built from the ground up.
Startup Rule #8: Don’t sell out your future. The decisions you made in the beginning will be around much longer than you think. (Technical Debt post)
Authentication and Security
Every system has user management and some level of security. For most products security is context, not core to the mission. In other words, a company should focus on things that are their unique intellectual property and everything else is just something you need to have. Don’t build context, buy/partner for that.
Okta is an example of company where security is their core, not their context. Rather than build a custom security apparatus in your own system, just partner with Okta instead right from the beginning.
Sure, you might be worried about COGS (Cost of Goods Sold) but, in my opinion, it is worth it. Security is a massively valuable feature. Two factor authentication, LDAP/AD integration, RBAC, and more all come “out of the box”.
You could also implement an open source version of the same thing, but you will get less support. Here are a list of free Okta alternatives.
Here is the key reason why you should do it. It’s really easy to implement if you do it in the beginning and it’s really hard to implement later. This is one of those “regret” items that will haunt your future self. Just partner with them from the beginning and then have best of breed security.
Feature Flag Manager
Another similar system you should build right from the get-go is a feature flag manager. Every SaaS system needs it and it is much easier to do right from the beginning. LaunchDarkly is a service (like Okta) where it is their core and will give you a great foundation. Of course, there are other free feature flag alternatives, with the same same pros and cons between open source and a partnership.
Slack is the highest profile example of this phenomenon in recent memory. Other notables are Figma and Atlassian. You basically make it REALLY easy to sign up and get your system up and be productive right away. This approach creates a foundation of people to drive marketing and sales initiatives. Additionally, it lowers the friction of trying out your solution. Assuming you have a product that doesn’t suck, then you can also create a buzz about using it.
The key is to make the free model very useful in and of itself, but leave enough on the table that a company will be interested in paying money for it. It’s a balancing act, but if you can pull it off, the benefits are significant.
One thing to make sure is that you have solid feedback mechanisms in place to field customer input. This includes a community forum, Twitter, and other support channels.
You usually don’t need it right away, but this is another one that is easy if you do if you start in the beginning. The basic process is to segregate all UI strings to a single resource files. Never put error messages deep in the code or database. Always put them in a central location. You will eventually partner with a translation service where you send them the original files and they send back a translation. International sales will be greatly boosted. Most new startups are in English only. You can gain a significant advantage with this simple feature.
When we did this at Marketo, it took almost 18 months to accomplish because we didn’t start from the beginning. There were strings everywhere. It’s not bad if you just start on the right foot.
I have to admit, I didn’t understand the power of APIs early in my career. I didn’t understand SOAP vs REST until I made the wrong choices. At Marketo, the APIs were built after the fact and are widely considered to be poorly designed. As a designer and product leader, I feel like I dropped the ball there.
If I were to build a system from scratch now, I would make sure the contracts between backend and front are clearly defined. React frameworks help with this approach, but you need to have discipline. Additionally, I would make sure the API documentation is solid from the get-go.
Lately, we have been experimenting with Redocly, a service that can help have a great API doc site. There are open source alternatives, but the key is to have API discipline.
My friend Ben Nadel, co-founder of Invision, started his company with remote workers being the norm. They never had an office. This obviously has helped them in the last year, but it also is a smart way to go.
Some of the benefits of a distributed workforce are:
- No office leases
- Recruit from anywhere increases the size of your candidate pool
- Pay less for people in remote areas
- No office management
- No paid for lunches delivered to the door
You will want to offer a stipend for internet access and office supplies, but that is a small price to pay for all the benefits. I have found that in the last year my team’s productivity (surprisingly) has not decreased. They have moved around the country and still managed to design beautiful product specs.
I believe that there should be a new role in companies to facilitate remote working in terms of bonding and communication. I believe it can be done well, but it’s not free.
A founding team should invest right from the beginning on culture and coaching. Too often, a company suffers from a weak or inconsistent culture. Especially in a distributed workforce model, you need someone who is going to wake up every morning and think about who they can coach to greater success.
Startups aren’t just the products they produce. It’s the people that make the company and the values they share. It’s the leadership that each employee can bring to bear at every level. Even a newly hired intern can provide fresh eyes and insight which could make a difference.
If you hire for this right from the beginning, your foundation will be solid. If you think, “We can do this later”, you will be building culture on quicksand.
Startup Rule #13: You are who you hire. Make sure you hire for culture first. A bad employee can kill your culture.
Again, this post went too long. Man, I am becoming long-winded in my old age. Bottom line: Start on the right foot and your future self will thank you.