Coding is fun. Really fun. Having played other actors in the startup play (manager, investor, twitter user, coffee consumer, etc) I can tell you that coding is the best flow you’ll get. It’s uniquely great.
So it isn’t surprising to learn that technical founders over-engineer things. Why solve something manually if you can write a script for it? Why talk to users when you can just code? Coding will be more fun, and more importantly, will feel productive[1]. You can rationalize why it makes sense to build that extra integration.
Non-technical founders have an advantage here: coding is alien. Confusing. Hard. This orients their mind to the correct focus: do the minimal amount of work in order to achieve something useful for your users. As a technical founder, you need to figure out how to be similarly lazy. If you have a startup, your job is to grow revenue. Not write code. You’re writing code because that helps you get revenue. Companies incinerate money, and your job is to generate more than you burn. You generate it by making something people want.
A Collection of Façades
The most metabolically efficient pathway to revenue is to put the most barebones-y thing you have in front of users as quickly as possible. Like a studio set with fake doors, your product shouldn’t be complete at first. Good founders will often collect revenue before they’ve built anything[2]. Bill Gates famously did this when starting Microsoft.
For example, suppose you’re trying to figure out if there’s a market for your enterprise product. I wouldn’t write a line of code. I’d start with sending an email to a few users with an animated GIF of a prototype. You can do that in an hour. Then you might try and onboard them manually. Sometimes you can even serve your customers with “low-code”-ware like Airtable and Zapier before you fire up Python or Swift.
“Almost There”
Post-launch another common mistake is the “just-one-more-feature” syndrome. “We’ll pay you if you build X”, they said. This is dangerous,. If you’re not careful, you’ll mistake a mountain for a StairMaster. There will be no end. You’ll realize what you’ve built just isn’t enough of a painkiller to pass through the checkout page. Can you get them to pay now, conditional on building X in 3 months?
Another lazier (and better) hack is to find different users that will be satisfied with your unpolished product than polish it for the giants. Christensen’s famous rebar story is a good model of how a worse product can be just as satisfying for a different customer base.
You want to develop the knack of traversing the laziest path forward, instead of the most intellectually satisfying. But it's hard to change behavior. It's hard to re-orient your mindset. Sometimes software can help you do that, just like Strava encourages more people to run. That's why we started Pioneer. If you want to push yourself to focus on product-market-fit, try it out: https://pioneer.app.
[1] Deceptively productive tasks are the most dangerous. Netflix isn’t a problem: you’ll self-regulate out of binging. It feels indulgent. Email is dangerous. It can be just as unproductive, but it feels virtuous. Don’t mistake activity for progress.
[2] Taken to extremes this can lead to vaporware, which is bad. Don’t do that.
[3] The most common bit of office hours feedback is questioning the question I’ve been asked. “Is that really what you should focus on?”. That’s a post for another time.