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 braniac, can do whatever you want.

So you’ve found your customer. You know what they want need. And now you’re going to write a custom piece of software for them.

Except… don’t do that. You haven’t really understood them yet.

First, solve their problem. Then, do it better, with code.

We were working on improving code review with an automated, intelligent bot. And in this instance, I think we did the right thing: we started reviewing a lot of code for our customers, manually. We identified common patterns across a few unrelated organisations, and then we started to automate it.

We could have coded less. We still built a UI for ourselves, and the pipeline to funnel data to and from GitHub was pretty complex. Totally unnecessary, as it turns out; we scrapped that product in the end. The research that came out of it was very interesting, but we probably didn’t need to write a single line of JavaScript to enable that.

Our second product was totally wrong. A beautiful UI, very sophisticated tech… and not a single customer.

Code is horrendously expensive to write (in both money and time), a burden to maintain, and a huge sunk cost that encourages you to sink more into it.

Write as little as you can. Do it on paper for a while, with a pen. Use a spreadsheet—they’re ridiculously powerful, and while I’d argue that making a spreadsheet is coding, it’s definitely less coding than writing a UI from scratch.

If you can’t do that, use Pipedream (I love it), or Zapier, or whatever you like to connect the dots. Make a bookmarklet to augment a web page that does 80% of what you need already. Make a browser extension. Write a Twitter bot.

There’s a hundred different ways to outsource part of your application somewhere else entirely. You don’t have to keep it that way forever, but you may want to think hard about where you start.

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

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 original thinker, can do whatever you want.

I write software, and I thoroughly enjoy it.

Despite reading a lot of books along the lines of The Lean Startup, I thought that in my role in my company, I’d mostly be writing software.

This was, in hindsight, quite foolish.

Until you grok your potential customers, you don’t need any software.

Go out and talk to people. Understand their woes. Figure out what keeps them late in the office. Ask them what happened to cause their latest catastrophe, and help them conduct a root-cause analysis to truly get to the point.

Be generous with your time.

And if you can’t get in the door, that’s one more reason why you don’t need to write any code yet.

I’m finding this hard to write. I don’t want to talk to people, I want to code!

But code is not the end, it’s the means.

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

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 smart aleck, can do whatever you want.

A map is not the territory. Just because you know where you’d like to be, that doesn’t mean you know how to get there.

So start exploring. Figure out what you don’t know, and make plans for how you’re going to figure it out.

At Prodo, we started out working on intelligent analysis of code to detect common problems—the sort of thing that’s usually caught by a code reviewer, but is mostly a waste of their time (and the reviewee’s, as they’re blocked waiting for review). If we were honest with ourselves, we might have come up with a list as follows:

• very little sales experience
  • practice selling
  • make a few sales before we start the business
• customer base is interested in solutions but entrenched with established players
  • figure out what it would take for someone to switch away from GitHub
  • investigate embedding a product into GitHub, rather than making a whole new thing
• no real expertise in how to apply ML algorithms specifically to code
  • explore the state of the art
  • read a lot of papers
  • make some small models that demonstrate potential
• unsure of the adoption of code review across the board
  • survey a lot of companies to understand their review process
• … and so on

If I’d seen that list, perhaps I’d have hesitated, and asked a lot more questions. Perhaps I would have pushed for a different make-up of founders, or for more practice before we started.

If you can’t see a potential path from here to there, you may not be ready to start a company. That’s alright; you can start exploring now.

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

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 thought provokee, can do whatever you want.

We form relationships with our co-founders under the best of intentions.

It’s still a relationship. If you’re doing something right, inevitably, there will be conflict. This is normal. Whether it’s healthy or not depends on how you handle it.

You could wait for this conflict to emerge, and then work on it. However, this is costly: you’ve invested a lot more into the company by this point, and perhaps you even have employees, who won’t get much of a say but will still have to deal with it.

Instead, practice. You could talk about controversial things (”here’s how I think we should run this business”), and get it all out in the open before you even start, but I don’t encourage that, because that kind of conversation is hard enough when you have stable foundations. It’s even tougher when you have more than two founders, because it’s quite easy for two people to come to a conclusion while completely ignoring input from others, and still think they’ve got consensus.

So hire a professional—a therapist, a coach, a facilitator. Have those conversations, but explore them with someone who knows how to facilitate them and help you grow. With help, you can have these discussions earlier.

You’re going to have them anyway. Make sure they’re constructive.

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

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 article assimilator, can do whatever you want.

Yes, yes, I know. Data is the new God. We can’t make any decision without spreadsheets.

But when you start a company, typically, you have no data. You don’t have customers, you don’t have a product, and you don’t know where to start.

When you don’t have something to ground you, it can be very easy to be swayed by someone a little more charismatic than you. This whole process is so exciting, after all!

And yet, you do have something to keep you level: your gut. Pay attention to the small sensations going on in your body when your co-founders propose a direction, or when you’re trying to figure out how to approach your first customer. At this point, your instinct is all you have. Use it well.

Sometimes, something won’t sit right. Listen to your inner monologue. Take your time. It’s early, and you’re in no rush; it’s OK to do absolutely nothing for a moment until you figure out what it is that’s bothering you.

Other times, it will just be nerves; a fear of the unknown, or anxiety about exposing yourself. That’s fine too. Acknowledge it, understand it, perhaps even say so out loud.

And then do it anyway. After all, this is the start. It’s time to explore new ideas.

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