You might have been wondering why my publishing cadence has shifted back to the initial bi-weekly schedule instead of the weekly posts you’re used to. There are multiple reasons, the main one being that I’m working hard on Anzu, the new company I’m founding. As with all startups, there’s a lot to do, but most interestingly, there’s a lot that shouldn’t be done right now.
Before we get into today’s issue, let me quickly plug this new format. I’ve built this blog to share the notes I was already collecting about software engineering, management, startups, and whatever else was on the top of my mind. There’s no purpose in having notes pile up when they’re never read, so distributing what I learned was an easy choice.
The same thought applies to my experiences building Anzu. We’re just at the beginning of the journey and there’s already a lot to share: Beyond the classic building in public, journalling has a self-serving purpose too, it strips away the emotions and helps focus on what matters. So I’m going to do just that and publish whatever is going on at a given point in time, be it engineering-related, product process, or talking to customers. Feel free to stop by once in a while and read the latest issue, if you’re curious.
Now, back to the last weeks. You’re probably thinking “I’ve seen you write about Anzu for the past two years now, what do you mean you’re just starting?”. You’d be right and wrong at the same time: I’ve been using Anzu, the name, for multiple product ideas in recent times, but every time I nearly caught on to the idea, a new turn of events came up and a pivot followed. I’m not even sure which iteration my co-founder Tim and I are on right now, but every time we pivot, we get closer to actually creating value and building more than just a weekend project.
Anzu started out as a visual Infrastructure-as-Code platform to unify all your cloud resources in one place. From this, we moved on to more high-level general-purpose building blocks that all applications needed, like queues, compute, file storage, and more. We continued walking up the abstraction layers and found ourselves providing user management, analytics, and a CRM, all tools a team needs to build products in one place. The further we pivoted, the more we realized that while the product completely changed on the surface level, the underlying idea remained the same: We tried to fight fragmentation and silo-building by collecting relevant context in one place.
We’re working on yet another iteration, and it’s starting to become clear that context doesn’t just help engineering teams, it can enable the entire team to move faster and serve customers better. A hunch alone doesn’t cut it for a serious business (tm), so we had to move away from thinking in terms of product and engineering and get back to the real world.
As a builder, taking a step away from the urge to just build has been a challenge, but I’m glad it’s finally happening. Building products can be addictive, you feel like you’re making important progress, but what’s the use of that if you don’t have customers? Not just users you could somehow bring in, no I’m talking about actual paying customers. From the first lines of code on some weekend projects to the first job, engineers are taught to build up experience through hands-on work. When you’re suddenly responsible for ensuring that your and your co-founder’s salaries are paid, you’re thrown in cold water.
So I’ve been doing the absolute minimum coding to update our landing page and allocated my time to two other focus areas: Fundraising and customer outreach. Let’s start with outreach.
Every resource for building a new product starts with the problem. Either you’ve been exposed to a problem in your previous job, through your immediate network, or in some other way. From the problem, you get out of the proverbial building (books haven’t adjusted to our work-from-home reality) and start talking to people. This sounds like the most obvious advice and yet I neglected the most important point, time and time again. It’s like your dentist telling you to floss more, you know they’re right, but somehow you end up not doing it nearly enough.
So when we started this time around, we almost ended up building without clear validation again. What saved us was that for any type of fundraising, we’d have to showcase clear interest in our product, and the biggest sign of that is having first customers, simple as that. So the last two weeks, we ramped up active outreach efforts via LinkedIn, targeting B2B SaaS companies in Munich and Berlin. In addition, we had first interviews with amazing people from previous jobs who helped confirm the problem at hand and gave us tips going forward. This helped us settle on an initial ideal customer profile (ICP) and get in touch with relevant decision-makers.
We’re not quite selling yet, we’re focused on validating the problem and understanding if multiple companies are facing it. Once we’re sure about that, we will verify that people are willing to pay for it. You’ve probably read this sort of process a million times now, so if you’ve been like me and always started building first, then asking the right questions, uninstall your IDE and pick up the phone right now. Until we close our first customer, I’m not writing another line of code, simple as that.
To me, the decision to reset all assumptions and start with seriously validating a problem also means that we started our real work a couple of weeks ago. Before that, we were simply playing around.
While we’re focusing on outreach throughout most of the week, I’m looking into the fundraising process as well. Even if we found ten customers before we racked up any costs, they wouldn’t pay the bills, so we need a cash injection to get started, and we’ll need more to keep moving.
There are four primary paths in fundraising: incubators/accelerators, Institutional investors (VCs), government grants, and angel investors. In most cases, it’s a combination of all of the above. Having studied at TUM, we could tap local accelerator programs like XPRENEURS or TechFounders, which are run in batches and can offer up to 25k. Even if we invested our time and got the full funds, that wouldn’t be enough to pay salaries for one co-founder, not to mention both of us.
Looking across the big pond, YC now invests 500k in batch companies, up from 125k previously. Given current cost calculations, even 125k would give us the runway for a full year, the only downside being giving up 7% equity and potentially dilution through the MFN safe, which are still acceptable. The bigger issue would be the administrative and bureaucratic overhead that comes with registering in the US.
Another option is applying for the EXIST grant issued by the German government. Founders are paid up to 2500€/mo for a full year with a budget for equipment, hosting, and other expenses of 10k per founder. The upside here would be that EXIST does not require giving away equity, the only requirement being that founders take part in coaching sessions and present their updates and results at different milestones.
Institutional investors and angel investors are further options that we could theoretically pursue, though there’s a moral hazard with applying for funding without having the first paying customers: Too many startups with a flawed business model are kept alive through venture capital funding when they shouldn’t exist in the first place. Raising VC money also comes with growth expectations, at the end of the day the sovereign wealth and pension funds need returns. Neither my co-founder nor I want to end up in that situation, so we’ll figure out the business first, then see if raising funds from VCs makes sense.
To conclude, we’re following the proven model now, validating the problem we’ve selected, seeing if customers are willing to pay, then moving on to building the solution. We’re also in the process of raising initial funds to keep the lights on until we break even, which additionally keeps us accountable to move ahead with the outreach work.
Focusing on non-engineering work also means that the next post may still be about startups instead of whatever code issue I worked on, and I’m totally here for it. This post will keep me accountable for following through with real work and is the first outlook of our transparent development process at Anzu, the product, and the company.
If there’s one thing to take away from my posts, it’s that if you’re a builder and you’re serious about building a real business, stop building until you have material evidence that you’re onto something valuable.
See you in the next issue!