In failing to build a company, I have learned many things. Core to all of them is that a company is not a product. Ideas change, products change, people change. We “pivot”, rapidly, relentlessly, sometimes ruthlessly.

Managed well, change is a catalyst. Managed badly, it can be catastrophic.

In this series, I try to explain the various ways in which I failed to understand this, and how I would endeavour to do better next time. You may notice that the style of these posts is more instructive than usual. Remember that these are mostly addressed to my future self, and as such, I am telling myself what to do; you, my dear completionist, can do whatever you want.

I am a millennial, and therefore I want to be friends with all my co-workers. I thrive in a place where we can play a game of table tennis in the break room, talk about listening to covers of metal songs by angry Finns playing the cello, or simply grab a beer (and talk incessantly about beer, because nerdery is not limited to computers). Since working from home, I really appreciate a chat over coffee, even if it is through a screen.

At Prodo, we used to play Dungeons & Dragons every Tuesday night. It was a wonderful way to bond with my team and get to know each other.

And yet, it strikes me now that perhaps I could have seen it as a warning sign, because it was the work event I looked forward to the most.

I worked with lovely people who I consider friends, even if we don’t talk too often nowadays. It turns out that doesn’t make a company.

Perhaps if I’d invested that energy into pair-programming more with the developers, or trying to push for a product that customers loved, things might have gone better.

Friendship is excellent, but don’t mistake it for doing a good job; we can do that and still clock out at 5pm every day. We don’t need to drink together to be able to work together on system architecture, or a sales strategy.

Though, of course, it helps.

Thanks for all the fish

This is the last article in the series, at least for now. I hope you found it informative and at least a little entertaining.

If you do have any feedback, or just want to say hi, please drop me a comment, a tweet, or an email. Details are at the bottom of every post on the website (so click through if you’re reading this in a feed reader).

Cheers all. I found this very fun to write.

1. Introduction
2. Focus on the problem, not the solution
3. If the company goals change, the company should probably change too
4. "Do research" is not a corporate strategy
5. Your corporate values transcend your product vision
6. Trust your gut, understand your heart, and open your mind
7. Go to therapy with your co-founders
8. Explore the terrain first
9. Unless someone cares, don't waste your time
10. Code is a liability; ship without coding, if possible
11. Do less, and do it better
12. Agile methods are tools to try more ideas in less time
13. Until you have traction, money is a trap
14. If you don’t know how to do it, that’s your biggest problem
15. Roles can be fluid, but they must be defined
16. Camaraderie is helpful, but no substitute for working together

In failing to build a company, I have learned many things. Core to all of them is that a company is not a product. Ideas change, products change, people change. We “pivot”, rapidly, relentlessly, sometimes ruthlessly.

Managed well, change is a catalyst. Managed badly, it can be catastrophic.

In this series, I try to explain the various ways in which I failed to understand this, and how I would endeavour to do better next time. You may notice that the style of these posts is more instructive than usual. Remember that these are mostly addressed to my future self, and as such, I am telling myself what to do; you, my dear knowledge aggregator, can do whatever you want.

When you start a company, the first thing you do is give yourself a ridiculously overblown job title. “Chief Technology Officer”, you call yourself, ignoring the fact that you’re a chief of 1 person—yourself, you don’t know what your technology is yet, and you don’t have the first clue about being any kind of company “officer”.

The title is important, because you’re communicating to the outside world that you, in fact, represent the company; you don’t just work there.

However, this is an external-facing title. Internally, roles are more nebulous. Perhaps one day, you’re the programmer, and the next, you’re the accountant. Congratulations: you’re now a generalist. This is an incredibly valuable set of skills you’re learning; rejoice!

Of course, you won’t stay the accountant for long. You’ll probably outsource that work anyway, but it makes sense to do it first so you can understand the job.

Some roles aren’t so clear-cut. Who decides the roadmap? Well, you’re the CTO; surely this is your job?

However, this can go badly. What if the CEO expected to have final say over what comes next? After all, they’re the one talking to potential customers… probably.

Roles are fluid, but they’re also a source of pride and privilege for the people taking them on. We don’t expect them to change without our knowledge. You signed up to start a company because we thought it was intriguing, challenging, joyful, purposeful… if you wanted to be told what to do and receive a high salary for doing it, you’d go get a regular job.

Just like everything else, the key to a harmonious relationship is to regularly have open conversations about roles and responsibilities, explicitly recognise changes, and write them down. This includes roles that no one is taking on right now: if you need a website but no one has time to make one, make sure everyone is aware of that.

An unmentioned change is still a change, except that it’s going to cause havoc when you least expect it.

More in the series

1. Introduction
2. Focus on the problem, not the solution
3. If the company goals change, the company should probably change too
4. "Do research" is not a corporate strategy
5. Your corporate values transcend your product vision
6. Trust your gut, understand your heart, and open your mind
7. Go to therapy with your co-founders
8. Explore the terrain first
9. Unless someone cares, don't waste your time
10. Code is a liability; ship without coding, if possible
11. Do less, and do it better
12. Agile methods are tools to try more ideas in less time
13. Until you have traction, money is a trap
14. If you don’t know how to do it, that’s your biggest problem
15. Roles can be fluid, but they must be defined
16. Camaraderie is helpful, but no substitute for working together

In failing to build a company, I have learned many things. Core to all of them is that a company is not a product. Ideas change, products change, people change. We “pivot”, rapidly, relentlessly, sometimes ruthlessly.

Managed well, change is a catalyst. Managed badly, it can be catastrophic.

In this series, I try to explain the various ways in which I failed to understand this, and how I would endeavour to do better next time. You may notice that the style of these posts is more instructive than usual. Remember that these are mostly addressed to my future self, and as such, I am telling myself what to do; you, my dear complex individual, can do whatever you want.

When you’re small, you don’t have traction, you’re making sales calls, and you have a problem, $Y$, you don’t know how to solve, it’s totally understandable to say, “I’m busy and this is not my expertise. It’s time to hire someone to take this on.” After all, you’re the expert in $X$; stands to reason that an expert in $Y$ would get this done faster.

Don’t. Do it yourself first, badly. If it goes well, you’ll have a new appreciation for the solution space and a much better idea of who to hire (or where to outsource). If it doesn’t, you can abandon the plan without much cost.

It’s expensive to hire (recruiters cost a bomb, job ads are tough to write well, and a multi-stage interview process can take weeks), and it’s costly to let someone go because they’re not working out. It takes time to make that decision, during which you’re not focused on your real problem, and you’re paying that person to do the wrong thing.

If you can do the job badly and still make a sale, it’s useful; go get a professional to do the next version.

This doesn’t scale. That’s OK; you’re not scaling right now, you’re figuring out what your product is.

More in the series

1. Introduction
2. Focus on the problem, not the solution
3. If the company goals change, the company should probably change too
4. "Do research" is not a corporate strategy
5. Your corporate values transcend your product vision
6. Trust your gut, understand your heart, and open your mind
7. Go to therapy with your co-founders
8. Explore the terrain first
9. Unless someone cares, don't waste your time
10. Code is a liability; ship without coding, if possible
11. Do less, and do it better
12. Agile methods are tools to try more ideas in less time
13. Until you have traction, money is a trap
14. If you don’t know how to do it, that’s your biggest problem
15. Roles can be fluid, but they must be defined
16. Camaraderie is helpful, but no substitute for working together

In failing to build a company, I have learned many things. Core to all of them is that a company is not a product. Ideas change, products change, people change. We “pivot”, rapidly, relentlessly, sometimes ruthlessly.

Managed well, change is a catalyst. Managed badly, it can be catastrophic.

In this series, I try to explain the various ways in which I failed to understand this, and how I would endeavour to do better next time. You may notice that the style of these posts is more instructive than usual. Remember that these are mostly addressed to my future self, and as such, I am telling myself what to do; you, my dear reader of blogs, can do whatever you want.

It seems that more and more startups raise money before producing, well, anything. Mine included.

We raised a significant amount of cash from angel investors within a few months of starting, thanks to some incredible work by our CEO. It was enough to pay ourselves a reasonable salary, rent an office, and hire a few people.

I have no proof, of course, but I believe it was this act that led to our downfall.

Now, of course, the money wasn’t the issue. The issue is that we spent it. We hired people without knowing what it was that we were making, including an ML specialist before we needed any real ML (as opposed to something “good enough to prove the point”), and a web developer before we really needed a web interface.

And so, we got some ML, and a web app, long before we knew what our customers wanted. This caused us to double down on these, treating them as the result rather than the mechanism.

If you don’t have investment, you have to make money through sales. While having the money in the bank meant we could quit our jobs, I think in our case, it would have been far healthier to act as if we had only enough for our own salaries, and knock on some (metaphorical) doors, delivering demonstrations, talks, and consulting until we got someone to pay some money. That would have enabled us to figure out what it is that people actually wanted.

We had the runway to do a bunch of programming, rather than talk to people, and so we did. If you don’t have money, you need to deliver.

This is not to say you shouldn’t go out and raise money, if you think that’s necessary or useful. Go for it. I recommend it, in fact; if your project is uninvestable for some reason, better to find out sooner rather than later.

And then take most of that money, lock it in a box, and put a sign above it saying, “to be opened when we have a clue what we’re doing”.

More in the series

1. Introduction
2. Focus on the problem, not the solution
3. If the company goals change, the company should probably change too
4. "Do research" is not a corporate strategy
5. Your corporate values transcend your product vision
6. Trust your gut, understand your heart, and open your mind
7. Go to therapy with your co-founders
8. Explore the terrain first
9. Unless someone cares, don't waste your time
10. Code is a liability; ship without coding, if possible
11. Do less, and do it better
12. Agile methods are tools to try more ideas in less time
13. Until you have traction, money is a trap
14. If you don’t know how to do it, that’s your biggest problem
15. Roles can be fluid, but they must be defined
16. Camaraderie is helpful, but no substitute for working together

In failing to build a company, I have learned many things. Core to all of them is that a company is not a product. Ideas change, products change, people change. We “pivot”, rapidly, relentlessly, sometimes ruthlessly.

Managed well, change is a catalyst. Managed badly, it can be catastrophic.

In this series, I try to explain the various ways in which I failed to understand this, and how I would endeavour to do better next time. You may notice that the style of these posts is more instructive than usual. Remember that these are mostly addressed to my future self, and as such, I am telling myself what to do; you, my dear thinking meatbag, can do whatever you want.

Not gonna lie, I love me some sticky notes on the wall. I adore test-driving code. I want to pair on pretty much everything, including drinking coffee. (My morning coffee with my partner is mandatory.) I love retrospectives. I think the daily standup can be an inspiring start to the morning (when it’s not conducted over fucking Zoom with everyone’s camera turned off).

All these methods are just that, methods, not results. They don’t achieve anything by themselves. They’re all enablers to help you iterate frequently (and at a sustainable pace), with high-quality, actionable feedback.

Use them, by all means, but use them to iterate. You don’t need to polish the internals of an app you’re 80% likely to throw it out. Test-drive the code, if it helps you achieve your goal, but if your goal is a demo, remember that. Write tests around the parts that must work, and test the rest manually if it’s faster to do so.

Reflect, of course, but focus your reflection. Maybe instead of a retrospective every week, you need one after every customer sales demo. If you have no feedback, there’s not much to talk about.

You have many tools in your toolbox. Choose the tools that will help you ship the thing you intend to ship, when you intend to ship it.

More in the series

1. Introduction
2. Focus on the problem, not the solution
3. If the company goals change, the company should probably change too
4. "Do research" is not a corporate strategy
5. Your corporate values transcend your product vision
6. Trust your gut, understand your heart, and open your mind
7. Go to therapy with your co-founders
8. Explore the terrain first
9. Unless someone cares, don't waste your time
10. Code is a liability; ship without coding, if possible
11. Do less, and do it better
12. Agile methods are tools to try more ideas in less time
13. Until you have traction, money is a trap
14. If you don’t know how to do it, that’s your biggest problem
15. Roles can be fluid, but they must be defined
16. Camaraderie is helpful, but no substitute for working together