Elevator Pitch
Making the transition from creating software to creating a business is not an easy one. It’s even harder when you’re only spending 0 to 10 hours a week on it. Learn from the CEO of PaperCall.io about the mistakes we’ve made over the past three years and how not to make them yourself.
Description
When you’re a developer building software, you get into this mindset that the most important thing is the product. You’re focused on scalability, good design, and building features. You spend hours thinking about new features, creating wireframes, and coding up new widgets. You think in terms of “what’s the best possible user experience?” and “how can I build all the same (but better and more!) features as my competitors?”. While those a good instincts for a developer, they can quickly lead you down a self-destructive path when you’re building a business.
PaperCall was founded by two highly technical individuals, each of whom had spent the majority of their time building products and not building businesses. Especially during our first year, we fell victim to building a field of dreams over building a sustainable business many times. We overengineered the original implementation of the website, built features without adequating understanding if they were needed, and failed to prioritize features that could jumpstart growth. We also failed to fully understand exactly how we’d market ourselves and acquire customers. We knew the mechanics of acquisition, but we didn’t focus on how to strategically deploy them in a manner consistent with our features and positioning.
We also failed to fully understand the users of our platform. We focused almost entirely on the experience for speakers, while asking event organizers to entrust us with helping them build the core of their events.
Probably most consequential, we failed to understand how little time we’d have to spend. We’d both built many applications, but never had one with such a large number of users that we supported only in our spare time. There’s no “I’ll just add that feature during our next sprint”, it’s “Let’s schedule that call for before work and I’ll get to implementing that feature over the next month, in the couple of hours I have to spend each week”.
In this talk, I’ll be focused on explaining the mistakes and fallacies we encountered in the mental shift transition from building software to building a business. I’ll dive into how something that is rational when you’re a developer, responsible for code, can be wholly irrational in the context of building a business from scratch. I’ll also explain some of the shortcuts that I wish we’d known (or even known to look for) when we first started that would have given us the frameworks and ways of thinking that could have easily saved us months or even years of work.