Principles
Note from Brendan: There are a lot here... Obviously
Bias for action
Move quickly. Once you're ~70% sure of something, execute on it immediately. Most decisions are reversible. The thing that will kill Fig is not making a decision. Accept that your assumptions are likely wrong. When you inevitably make a mistake, correct it quickly.
Everything is a product
Everything should be built in a way that it could be used by future internal teams + externally for future products. e.g. using sendgrid to send emails to customers? Chances are you are not the only Fig product that will need to send emails. Build our email sending server as if it is its own product that can be used by any internal Fig team in the future. Monorepos are good for keeping code close, but monorepos should have a well defined structure with unbreakable walls between separate chunks of code. Define the communication protocol between your app and the rest of the world early and continue to document it. If we follow this principle, what may start off as a small thing may end up becoming a core component of Fig or better still, a paid product! Modularity also allows for better more defined team structures + lower bureaucratic overhead.
Bias for money and/or powerusers
When building a new product that serves external users it's either used 20+ times daily, it's embedded as core infrastructure, or people are paying for it, otherwise, it's not worth our time. Don't kid yourself into thinking that you have fake product market fit. If someone used your tool once a day then never comes back it is NOT product market fit.
Push it
Something is not done until it's pushed and live. If you have a ton of PRs open, the onus is on you to get them merged. If you're editing things that objectively aren't going to break things, just push it. Don't waste time getting reviews. You have the keys to the castle. As we learned above, most decisions are reversible. What will kill us is constant bureaucratic overhead of reviewing things that really don't need a review: if you are unsure if your code will break something, get it reviewed. If you just want feedback on your code quality and style, you should absolutely seek this out, however, this shouldn't prohibit a merge and products live. You should ask another person to sit down with you and review a bunch of old merges you did and add commentary. Do this in one hit don't block stuff being pushed if it's valid!
Customer Obsession
Literal obsession. You should not make any decisions without having customer data. You should constantly be speaking to your customers and asking for feedback. Watch your customers use your product. The tool that you've spent months building and you think is perfect is often not perfect at all. You only realise this when you see a user struggle with it. Remember, a customer is not necessarily the end user. If you're writing an RFC, the customer is the relevant team / company. If you're setting up a new internal tool, the customer is the eng team.
Create magical experiences
Steve jobs: user experience should be "insanely great" - with insanely meaning you it is literally mentally insane. It doesn't make sense why the experience is this good. Experience is not just the product, it's everything: documentation, usability, support, etc. In order to do this, you must truly understand the customer and their workflow. Talk to them! The more we can do for the user so they don't have to make choices and it just works, the better.
We make money
Many dev tools companies are scared to acknowledge this. Fig cannot exist without making money. We make products that people love so we can make money, so we can make more products that people love. Without making money, Fig will die. VC money accelerates the rate at which we make money from our customers. VC money is NOT the way we make money.
Our current thesis is getting a lot of users on a very stickiy product will make it easy to monetise in the future.
Nothing is impossible
Fig pins a GUI next to your typing cursor in an application that isn't our own. It took a lot of work, but we did it. If we can do that, we can overcome just about any engineering problem. In saying this, we shouldn't do engineering tasks because they are hard. We should do them because they are the best solution for a customer.
Focus on problems, not solutions
Users often talk in terms of solutions e.g. I want an app that can do XYZ. It's your task to work out what their underlying problem actually is. Then you can solve the problem how you see fit. Another way to think about this is, what is "job to be done"? What is the end goal the person is actually trying to accomplish here? Identifying the problem is the hardest part. Solving it is often quite easy. e.g. The problems in the terminal:
- [Beginners] I have no confidence when I use this tool. I don't understand terminal, shell, or CLI tools. The keybindings are different. There is no syntax highlighting. My job / homework relies on me using it.
- [Advanced] I use this tool all the time and I want to be as fast and efficient as possible.
Problems are things that people describe as painful or annoying. Finally, don't focus on the problem with the solution, focus on the broader problem. e.g. I wish my iphone could have two sim cards is a problem with the solution. The broader problem is: the user travels a lot and needs a way of switching phone numbers.
Many people think that having a great startup idea means it needs to be revolutionary and sexy and not something that anyone has ever thought of before. That is probably not the case. Most of the time, the problem is very small and clear. What's surprising is how many people actually face it. It's often easiest to just solve a problem that you know already exists rather than try to uncover a new one.
If you have to keep one thing in mind: don't attach yourself to an idea, attach yourself to a user's problem (or set of problems) and solving them.
Always be learning
Be curious. Test product ideas while you're getting user feedback. Ask people about specific problems they are facing even if it's adjacent to what you're working on right now. You never know, it could be Fig's next product and you could lead it.
Dive Deep
No matter how long you've been at Fig nor how experienced you are, no task is beneath you. Get your hands dirty. Don't rely on information to filter up to you, speak to users and investigate the primary data yourself.
Commit
Once a decision is made, commit wholeheartedly to the decision. Don't passively undermine the decision or deliberately go against it. If something isn't working, provide feedback about what exactly is not working and propose a solution to make it better. We can't work together as a team if we assume you will do one thing and you do another.
Ruthlessly prioritise
What are your #1 and #2 priorities for the week? Month? Quarter? At any given time, these should be abundantly clear. If they are not, consult with your team immediately and clarify them. Now ask yourself: "what am I working on right now?". If you're not working on what you've identified as a priority, you're doing something wrong. Stop whatever it is immediately and start working on top priority. Look at your calendar for the week. What events have you got scheduled? If you have events that don't match up with your top priorities, you're doing something wrong. Cancel those events immediately. Don't even reschedule them. It is not rude at all to cancel. Your time is incredibly valuable. Don't spend it on low priority things.
Set goals and hit them
What will you do this week? Set goals that you will 100% hit. Even if they are slightly the wrong priority,
When you have too much to do, three problems occur:
- You become overwhelmed and lose sight of priorities and end up working on the wrong thing
- You end up getting 50% of a lot of things done rather than 100% of a few small
- You end up working on easier tasks, leaving the harder tasks behind.
We've learned that the harder tasks are often the most important tasks for an organisation. We've also learned that if you prioritise incorrectly but you hit your goals, then in the next week you will end up working on the top priority task. Over a longer period of time, you will end up hitting all your top priority tasks.