Spenser Skates on the Indie Hackers Podcast

I just listened to a great Indie Hackers podcast. In it, Courtland Allen interviews Spenser Skates from Amplitude. Some of the things they talked about are too good to forget; so instead of relying on my leaky brain to remember them, I’m going to pen some of them down here. All of the following quotes are from Spenser Skates. Seriously though, if you’ve got an hour (or 45 minutes if you’re like me and listen on 1.5x speed) you should go listen to the podcast yourself.

Build It, Sell It, Build It, Sell It…

So the thing about great engineers is that, if you’re an engineer your natural instinct is to solve a problem, so if someone says, “Hey, I have a problem doing this.”, you’re always like, hey I can fix that for you, let me build something that can help solve that. That part is easy and all you have to do as an engineer to add onto that is like, go talk to customers.

I definitely agree with this. Engineering at its core is utilizing a technical skillset to solve problems. I get lots of practice doing this in my Engineering studies and internships. The important part here is the reminder to go talk to customers. This is the next step that sets the building companies apart from solving problems. Spenser Skates continues to elaborate on this saying:

If you keep doing those two core things really well, if you understand what people’s problems are and then build something to solve them, and you do both of those things really well, then, yeah that is the core motion of success for any software business. Anything else that people think is starting a company doesn’t really matter. You don’t really need to market yourself, you don’t need to have a great product strategy, or the perfect messaging, or hey I need to sort out all these things on my finances, it’s like no no no, all you have to do is build the product, sell it… build it, sell it, build it, sell it, that’s it. When you’re very very early on that’s the core motion that will lead to building a successful company.

This is a comfort to hear. The core motion here of “build it, sell it” is non-trivial. But, when you reduce a complex problem like building a software company down to a set of simple steps, it brings it within the realm of possibility. At that point all that’s left to do is to execute — easier said than done I suppose.

The other cool thing about this “build it, sell it” core motion is that it seems like it would have a fly-wheel effect. As you build something great, it becomes easier to sell it. As you sell to people, it becomes clearer what you should build.

A problem from the heavens

I think the false expectation that a lot of people have is that they’ll be handed the ideal problem down from the heavens, and the perfect definition, and know exactly what it is to build perfectly for all things.

Love this!

The really important thing to understand, the difference between when you’re at another job, or when you’re at school, working on things is that in the world of startups and business, the problems are not well defined, so defining the right problem is a job and super important in itself.

My dad always makes the comment that University is a unique time because your life comes in discrete 4-month chunks. Once you graduate this is no longer true. This is another way of saying that the problems are well defined in school. Pay attention in class; hand in your assignments; do well on the final; you pass! What an alluring trap. It seems to me that the opportunities to do great things are not clear cut. They are ambiguous. Confusing. Scary. Or in other words not well defined.

So how do I learn to deal with not well-defined problems? An Engineering degree isn’t giving me that experience. My internships are a bit better in this regard, but they still fall short. How can I seek out more experience like this?

Product/Engineering

We have this saying here at Amplitude, which is that product’s job is not actually to come up with a solution. Product’s job is to define the right problem.

This is a helpful framework to understand a technology company. I’ve certainly spent a lot of time at my current internship working to understand the relationship between Engineering and Product. A good interface between the two is critical for a healthy and functioning technology company. I’d propose that:

Product should define the right problems to work on. Engineering should solve the problems.

Practical Advice

I would say spend half your time [updating your understanding and definition of the problem], that’s what talking to customers is. That’s what sales is, sales is uncovering the problem of the person you’re talking to, you don’t know that by default. Split your time between the two. It sounds crazy to spend half your time defining the problem, but that’s actually how you should think about it. Spend 50% of your time talking to customers to update your understanding of the problem and define the right problem, and spend 50% of your time solving it, because the worst is you define a crappy problem nobody needs solved and you spend 95% of your time on the wrong problem. That would be the challenge I have to anyone who’s starting a company from an engineering background is to spend half their time defining and understanding the problem they’re solving.

That quote could have started with a “Dear Caleb”. It’s like he was speaking to me. I 100% fall prey to this trap of not solving a real problem. “The worst is you define a crappy problem nobody needs solved and you spend 95% of your time on the wrong problem”, is the theme of my past four side projects.

So it’s clear that I need to talk to customers. But, this leaves me with all sorts of questions. For example, how do I go about talking to customers if I don’t even know what problem I should be solving? Perhaps, the answer is to just start trying.