⚡ TL;DR
- Stay focused on 1 customer problem as a small team (< 5).
- Have a high bar for the tools you use.
- Hire slowly, but always be hiring. Talent can pop up at any time.
- Automating diagram creation is a waste of time (for now).
- There’s no growth hack, just talk to your customers.
🚀 Intro
The last year has been a whirlwind, from growing the team, learning how to work together, rethinking major parts of the product, and becoming more confident about the type of company we want to build.
Admittedly, we’ve been pretty bad at celebrating our successes and talking about our experiences. So, to break the ice, we’re sharing a few things we learned building IcePanel over the last year. These are practical tips (no LinkedIn clickbait) that are most useful for startups in a similar stage as us — a small team of 5 making around $2M ARR in B2B SaaS.
💆 Focus on 1 thing
Last year, we grew the team to 4, and we’re now 5 with plans to continue hiring (slowly). This was far from hyper-scale growth, but getting to this size meant we’d have to be more thoughtful about what we worked on, who worked on what, and when. Coordination was needed instead of informal, ad hoc collaboration.
One of the biggest mistakes we made early on was trying to work on too many things at once. Having more people doesn’t necessarily mean you can ship faster, and we got into the trap of trying to build too many features at the same time. This created a lot of issues, like people not knowing what others were working on, which compounded because people were also onboarding. It ultimately led to slower velocity and poorer quality. The worst of worst. 🫠
Thankfully, we caught this issue pretty early and were able to course-correct. We decided to work on only a single customer problem or bug fixes in a 1-week cycle. We came up with a simple rule to write down on a sticky note: “I will focus on…” to remind ourselves every day. It was probably excessive, but it sort of worked. This cadence and singular focus worked well, and we plan to continue working this way until things inevitably start breaking again.
Takeaway: Don’t overthink your team structure. There’s really no need to break up into separate product teams until you reach a certain scale, which we’re nowhere near. And even then, you should prioritize team structure based on the product areas most critical to the business. We watched a great talk about this from Nan Yu at Linear at Config.
🛠️ The tools you use influence your quality bar
You might have seen research studies on the influence that people you surround yourself with have on your outlook and values. The same holds true with the products you use daily at work. If you use poorly designed, bloated, and ugly software, there’s a good chance that it’ll influence how you think.
Good design is a core product value of ours. This is why we expect any new hire to have good design sense — being able to dissect a product, pick out flaws, and knowing what good and amazing software looks like are important skills to have. A lot of the software our customers use or used before IcePanel didn’t prioritize design, and it’s become a key value of ours.
This is why we constantly reevaluate the tools we use. Poorly designed products don’t just annoy us, they actually have a business impact and waste time (don’t get us started on Canadian banking…).
Some of our favourite tools are Teams, Missive, Vault, and Linear (we were not paid for these plugs).
Takeaway: Review your tools regularly and replace any that are poorly designed or prevent you from accomplishing key tasks quickly.
🤝 Hire slowly, but always be hiring
We can probably write a separate post on hiring in Vancouver, but to keep it short, hiring here is tough but not impossible. Jacob describes it as “furiously trying to lift rocks, and eventually you’ll find talent.”
Our friend Ian from PostHog has written a lot about this (read this). From our experience, Vancouver has a lot of talent, but the brain drain to the US is real. Salaries are lower, there are less interesting small companies, and the proximity to bigger tech hubs (Seattle, SF) is hard to pass up. Although we compensate on the higher range relative to other local companies, as a (profitable) bootstrapped company, we don’t have the war chest of tech behemoths (Amazon and Microsoft have a big presence here) or a VC-backed startup.
With these challenges, we’ve shifted to an ‘always be hiring’ philosophy. Since our hiring bar is high, talent is transient, and we’re not hiring a whole lot of people, timing is key. Instead of going through traditional ‘hiring rounds,’ we keep our job posts up indefinitely. If you’re interested in joining us, apply here. We’re always looking for talented builders.
Takeaway: If you’re a startup hiring in-person / hybrid in a competitive city, you should always be looking for talent. Focus on quality over quantity.
🤖 Automating diagram creation is a waste of time
We’ve heard architects consistently want to automate a lot of the architecture design process. “What if you could just generate the diagram from code and connect it with your CI/CD process?” Nowadays, it’s more like, “What if AI could just create all the diagrams for us?” We roll our eyes internally whenever we hear this.
Automation, to this point, has overpromised and underdelivered. We’ve written about the gaps with diagram-as-code here. In a nutshell, here are some problems we see with it:
- Automation doesn’t come for free, there’s an upfront cost to set it up.
- Automation requires constant maintenance (integrations always break).
- Automation at scale isn’t reliable. There’s a speed <> accuracy tradeoff.
Most importantly, the value of architecture diagrams comes from the answers they provide on the ‘why’ behind certain decisions. Why did we choose this architecture pattern, this technology, this API protocol, this deployment structure? A lot of context and tradeoffs get lost when it’s automated. Automation skips the thinking behind these decisions.
Takeaway: There’s a time and place for automation. Avoid automating higher-abstraction thinking or decisions, and instead, spend some time documenting things manually.
🫶 There’s no growth hack, just talk to customers
There are so many opinions and ‘advice’ out there nowadays. Just log on to LinkedIn for your daily digest of ‘Here are 5 ways to reach $1M ARR in 1 month”. People want easy, simple solutions, yet the reality is always messy.
There’s no ‘hack’ to help you build a great product and business. If your product isn’t solving an important enough customer problem, no amount of trickery in your onboarding flow is going to solve it. If you don’t have 10 active, paying customers, there’s no point in discussing EBITDA or unit economics or PMF… Focus on building something useful enough for a small segment to start.
Nothing beats just spending time with your customers, listening to their day-to-day struggles, tasks, and how your product fits into their workflows. Being close to our customers is super important to us, and we expect everyone in the company to be consistently talking to customers.
1 tool that’s helped with this (again, not a sponsored recommendation) is Cal. When you book a demo, we set up ‘Round robin’ mode with weights to rotate customer calls across everyone. This makes sure everyone on the team has consistent exposure to customers.
Takeaway: If you’re a small, high-calibre team, have everyone be continuously exposed to customers at different stages in their adoption journey.
Bonus: It’s about the journey, not the destination 🛣️
Ok, one more thing. A huge motivator for us to wake up every day and build IcePanel is having fun along the journey. Being able to work with great people, build a useful product, and help people understand complex systems. We’ll most likely look back on our time building IcePanel on our experiences together and the challenges we pushed through instead of the dollars in the bank account.
As always,
Stay chill 🤙
