{"id":840,"date":"2018-01-11T20:19:00","date_gmt":"2018-01-12T02:19:00","guid":{"rendered":"https:\/\/www.joshualyman.com\/?p=840"},"modified":"2018-01-11T23:21:03","modified_gmt":"2018-01-12T05:21:03","slug":"learned-bootstrapping-2017","status":"publish","type":"post","link":"https:\/\/www.joshualyman.com\/2018\/01\/learned-bootstrapping-2017\/","title":{"rendered":"What I learned bootstrapping in 2017"},"content":{"rendered":"

I’ve been blessed to be able to spend nearly the entire past year focusing on Perspexi Labs<\/a>, 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.<\/p>\n

(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<\/a> others have yet to learn<\/a>. So we continue.)<\/em><\/p>\n

Lesson 1: Speed matters<\/h2>\n

Remember the classic equation,\u00a0Distance<\/em> =\u00a0Rate<\/em> \u00d7\u00a0Time<\/em>, that you probably learned in seventh grade involving trains traveling down the tracks at a given speed\u00a0R<\/em> for\u00a0T<\/em> minutes, going distance D<\/em>? I’ve learned that same equation applies to business as well.\u00a0T<\/em> is constant for everyone, and if you want to change how far you travel\u00a0D<\/em>, your only lever is your R<\/em>ate of speed.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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\u00a0 a matter of only a couple weeks. Seeing broader application, we also marketed it to service-oriented businesses, and then boom<\/em>, within six weeks we had a flock of customers and a legitimate business.<\/p>\n

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.<\/p>\n

Do whatever you can to build speed, maintain speed, and capitalize on speed to keep your business from atrophying.<\/p>\n

Lesson 2: Team matters<\/h2>\n

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<\/em><\/a> and conversations with mentors were useful, but lacking any real marketing talent between the two of us certainly made things difficult.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Lesson 3: Focus relentlessly on your MVP<\/h2>\n

One thing we did very well was to apply Lean Startup principles<\/a> 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

But how did we solve this? With a switch statement\u00a0in the source<\/em>, with customizations\u00a0hardcoded to different customer IDs<\/em>. Does this scale? No way. Did this save at least 4 weeks of development time? You bet.<\/p>\n

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.<\/p>\n

Ask yourself: do I\u00a0really<\/em> 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\u00a0not<\/em> 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.<\/p>\n

Examples:<\/p>\n