I’ve been blessed to be able to spend nearly the entire past year focusing on Perspexi Labs, the company I co-founded with my great and very able business partner last year. We create the fastest feedback loop ever to help businesses get more feedback from their customers by automatically texting as soon as a service is complete. Over the course of the last year not only has Perspexi grown, but I’ve learned a volume of valuable lessons, which I wanted to share.
(Yes, I realize some people may find much of the following obvious! But they were valuable lessons learned, and wise men have said that what you have learned others have yet to learn. So we continue.)
Lesson 1: Speed matters
Remember the classic equation, Distance = Rate × Time, that you probably learned in seventh grade involving trains traveling down the tracks at a given speed R for T minutes, going distance D? I’ve learned that same equation applies to business as well. T is constant for everyone, and if you want to change how far you travel D, your only lever is your Rate of speed.
We’re bootstrapping Perspexi, but I now better understand why companies seek funding. Additional funds become an enabler to do more things, more quickly, with more people, reaching your desired business goals faster.
In the early days of Perspexi, we spent about six months building and marketing a tablet application for a specialty of doctors to record outcome measures, but while an effective product it arrived too early.
By the time we were coming to this realization, we started to think about other ways to positively affect outcomes in healthcare and, nearly on a whim, I built out a text messaging platform for getting feedback from patients in a matter of only a couple weeks. Seeing broader application, we also marketed it to service-oriented businesses, and then boom, within six weeks we had a flock of customers and a legitimate business.
But then… sales didn’t continue the growth pattern after we explored the first network of referrals, and time started to stretch on. Competitors began catching up, momentum started to slow down, and you start to feel like you’re in the mud.
Do whatever you can to build speed, maintain speed, and capitalize on speed to keep your business from atrophying.
Lesson 2: Team matters
On our team, I possess the technical skills and my co-founder possesses key relationships. However, neither of us are marketing people. At all. This contributed to the slowdown just mentioned, as we flailed around trying to figure out marketing channels that we could employ to boost growth. Helpful resources like the book Traction and conversations with mentors were useful, but lacking any real marketing talent between the two of us certainly made things difficult.
I hold the core belief that anyone can learn just about anything, given time and perseverance. But again in a bootstrapped company, time is one of the precious commodities you have little of. Having all the unique and essential skills needed on your team is critical to bootstrapping success.
One more note on team: because of differing career and life circumstances, we spent different amounts of time working on the business, and doing so at different times of the day. Being out of sync like this also makes things difficult, though not impossible. We effectively operated as a remote team, with the pros and cons that go along with that. I’m used to remote work, but some aren’t.
Lesson 3: Focus relentlessly on your MVP
One thing we did very well was to apply Lean Startup principles to our product development. We did not overbuild but instead launched products before they were truly ready, using the very early feedback and observations to quickly build out required features, and using invisible hacks or stopgaps to deliver needed value without spending too much time on development and coding.
Story time. When we launched with our first beta customer, we knew they would be entering many customer phone numbers per day, but we didn’t know ahead of time exactly how many or how they could be entered. When we walked in the door, the only way to enter the numbers was one at a time via a single-number entry screen. I sat with our customer for the first two days, being their righthand man and doing much of the work for them, but also learning very quickly how the business operated and how best to allow them to enter in multiple numbers. By the end of the second day, I had built out a robust yet simple bulk uploading tool, allowing them to simply drag-and-drop a report from their CMS into our tool to instantly enter a day’s worth of services for texting.
Had we tried to prebuild this feature, we wouldn’t have gotten the details correct, we would have likely built something overly complicated based on API-usage or screen scraping, and it would not have turned out nearly as user friendly.
Story time #2. This makes me cringe as a software engineer, but cheer as a business owner. It is how we handled verbiage customizations. We start all our customers with the basic Net Promoter Score question for their texts, but at our higher plan levels we allow customization of this prompt as well as the creation of new questions. The “proper” way to do this is to store message templates in a database, instantiate a copy of the template as a new record for each customer, and create a UI for managing modifications and new question records.
But how did we solve this? With a switch statement in the source, with customizations hardcoded to different customer IDs. Does this scale? No way. Did this save at least 4 weeks of development time? You bet.
We spent those four weeks (minus the 4 minutes per customization required to change the source) doing many other valuable biz dev activities, time well spent and a lesson well learned. Eventually the proper code ends up getting written, but not before there’s business justification for doing so, and all our customers were fully satisfied in the meantime.
Ask yourself: do I really need to write this feature? Yes, it would be fun to code it up. But guess what? There’s probably a greater than 50% chance that you do not need to write that feature right now. There is quite likely a way that you can accomplish the same business end with a technical solution that takes 10% of the time.
Examples:
- Customer needs a bulk entry screen? You be the bulk uploader till you build a simple CSV parser.
- Want to have your app send out alerts to increase engagement? Yes, automate those someday, but for now set a reminder in your calendar and send a batch of emails out yourself.
- BigCo CustomerMart wants much more fine-grained RBAC controls? For just a little while, hardcode some user ID checks on the required pages because you know their team doesn’t change that rapidly, then add better RBAC once they send you the first fatty check.
Lesson 4: Growth does not happen on a nice, smooth curve
Hockey stick up-and-to-the-right growth graphs are nice, but they’re also fictional, especially in the early stages. Real growth happens in fits and spurts.
This makes it difficult to plan, and it makes it difficult emotionally. We grew at a rate of several hundred percent for several weeks at a time, and then had no growth for the next long set of weeks. When bootstrapping, you can’t count on any sort of linear growth rate. This of course has troublesome implications for cash flow, if not managed correctly.
Luckily our business was ramen profitable from the get go (thank you cloud!), but it made it difficult to plan for hires. We really wanted to hire a sales expert—had we experienced linear growth based on our early acquisition of customers this would not have been an issue at all. But because growth happens in fits and spurts, that makes bringing on a real hire more difficult. It also creates that rollercoaster ride of emotions that defines entrepreneurship.
Conservative planning and aggressive sales are about the only way out of this until you can get a smoothly humming growth engine running, so don’t get fooled by strong growth too early.
Lesson 5: Know your strengths
I am a terrible ads person. We spent a chunk of money (in the $X,000 range) on various online ad providers, and got nothing from it. It’s common knowledge that PPC campaigns are usually a money-loser from the start, but with the amount we spent common knowledge also says we should have seen at least a few converted customers result, but we had nothing. I can’t blame the channels though. I can only look inward, to the creator.
So yes, I bombed at that, hardcore. I will never allow myself to do that again. Right tool for the job, and right person for the job. When I launch online ad campaigns again I will find outside talent to do that in a heartbeat.
Know your strengths, play to them, and don’t waste time trying to do it solo when you should find someone better.
Lesson 6: Tech stack doesn’t matter, innovation chips do
Despite personal preferences and flame wars, the tech choices really don’t matter. You can choose to develop your Big Idea
with just about any stack you’d like: go plain ol’ Java or shiny Scala, use inexpensive VPSes or scale up with AWS EC2s, write normal server-rendered pages or a hot reloading SPA, it doesn’t matter.
What does matter, however, is how you spend your “innovation chips.” (This idea isn’t mine, but I can’t for the life of me find the source post on this).
What’s an innovation chip? It’s doing something new that you don’t have direct, past experience doing. For example, if you’re an expert C# dev without a lot of functional programming experience, writing a new application in F# counts as an innovation chip. If you’ve done consulting in the past but haven’t built a sales team, that’s an innovation chip.
Any time you use an innovation chip, you are expending a vastly larger amount of effort and brain power to accomplish it compared to doing what you’re already experienced in.
In a project or new venture, you could just about sit down with a stack of four or five real poker chips, and label any new thing you’re doing on one of those chips. Once you’ve labeled out all of your Poker Innovation Chips of Science, you aren’t allowed to take on any “new” approaches or experiences until you firm up experience with one of your current explorations.
At Perspexi, I was careful in how I spent my innovation chips, and that caution paid off. Several innovation chips I spent right at the very beginning included integrating a new API (Twilio), launching products on Azure’s App Service, and running a B2B SaaS company (with that last one being the big innovation chip). Yes, that’s right, new business experiences count just as much for innovation chips as do technical experiences. Because I was rationing out my innovation chips and spent the ones I absolutely had to spend first, I knew that I could not allow myself to do some other “shoulds,” like implementing a message-based, microservices architecture from the get-go. That would have been fun, and would make for a more robust architecture, but it would have been overspending my chips.
Overspending your innovation chips will spread you too thin, slow down progress, and could kill the business. Wisely deciding how you will dispense your innovation chips with the team will reap you rewards in both learning new skills and being able to successfully deliver a product and business. Make the hard choice to tell yourself “no” now, and you will have the freedom to tell yourself “yes” later.
Random bonus lesson: trade shows are not for decisions
I probably should have realized this beforehand, but tradeshows are not a place where decisions are made. Introductions happen and relationships begin, but no one makes a “let’s do this” decision on the floor, while talking to you, no matter how good your pitch and demo. That decision and commitment will only come after following up post-conference.
Also, people won’t read your signs. The big backdrop at your booth is just that: a big backdrop. Put your logo on it and nothing else, because no one is going to pay attention to what it says besides logo recognition. I put together what I thought was an awesome poster. It had our three biggest selling points on it and instructions on how to text your name in for a quick demo, all on a beautiful 4×6′ canvas banner. I thought it was going to be great, and so much more effective than anyone else’s!
No one even read it. I explicitly pointed it out to a few people, and they obligingly played along, but it otherwise went completely unnoticed. The one good thing we did do is put one big picture on it that summed up nearly our entire product very well, and I was able to point at it and walk potential customers through the product, which was very handy.
Conclusion: bootstrapping is hard and awesome
The past twelve months have taught me more about business, technology, and myself that I have learned in the preceding several years. They are lessons that will accelerate my path in the future, and lessons that I couldn’t have picked up had I not gone and done something. I can’t claim huge success just yet, but learning is point by point, line upon line. If you’re looking to learn, take to heart some of these lessons, then go out there and do something yourself, learning more than you can just reading this!
