Creating vs. Testing vs. Building

Starting and running a business is a great way to reveal the gaps of your own lived experience. Inevitably, you'll run into plenty of unexpected challenges you haven't previously seen (i.e. unknown unknowns) that require use of judgement, and you'll realize that your inability to act is less about missing a specific skill, but a gap in your experience.

One of the gaps I discovered a few years ago was that my background working in early-stage venture-backed startups conditioned me on a specific model of decision making. Generally speaking, we were laser-focused on localized, short-term experimentation that centered solely around: "will a user do X?"

At most early stage startups, this is completely rational.  You're drawing down from a bank account filled with venture capital and your task is to keep pushing experiments until you uncover something that could either lead to rapid growth and/or give you the leverage to raise another round of financing at favorable terms. In the best case scenario, it might even lead to uncovering a business model that allows you to write your own ticket.

Orbital, however, wasn't an early stage startup.  It was a self-funded mid-career residency program for myself, which came along with non-trivial operating overhead.  Both the context as well as my goals were significantly different than working at a startup.  It necessitated a different strategy altogether.  However, when I reflected on my experience, all I had was a specific playbook of skills and intuition that was having a limited impact.

What made the most difference was learning to be more deliberate about my intentions before beginning a project.  What was I really trying to do?

1. Create a one-off that "just needs to work this one time"?
2. Test a hypothesis?
3. Build the first step of something that was intended to be repeatable if not financially sustainable?

Given my background, I knew how to do (1) and (2).  However, while working in venture gave me invaluable exposure to (3) at an intellectual level, it was insufficient.  There's often little to no replacement for having relevant lived experience, indirect or otherwise.  And often that's what you need to make the leap.

Ironically, in retrospect what helped me get through all this was that I had decided to take on multiple challenges at once: co-teaching Entrepreneurial Design at SVA, while running both the membership community and the business of Orbital (particularly the Studios).

All three tracks gave me the opportunity to be confronted with (3) but in different contexts. That made it easier to identity themes and blind spots.  Often an insight derived from one project ended up saving the day on another.

For example:

• Cash flow is oxygen, so you need to actively manage this.
• You can build all of the well-executed software features you want, but if you have sufficient leverage in the market, it doesn't matter at all.
• A low cost structure can be a defensive moat, so be wary of operating in a manner that's difficult to sustain over the long term.  On the flipside, you're not immune to what's happening in the market, so don't be complacent and assume your options and outcomes are fully within your own control.

Even more valuable were the more personal lessons:

• You need to be intentional about how and where you expend your emotional energy.  If you haven't established boundaries for yourself, others will dictate that for you.
• Trust is a huge driver of behavior and an incredible moat, but it takes time.   It also requires learning to see and accept people at face value.
• People aren't static–they evolve and change, and you can't control them.  What you can do, is design and build a system that accommodates for this.

These insights are like tools you keep in a toolbox, which you can turn to when you encounter new challenges down the road.

Which is also why taking the time to review, reflect and write out the lessons is a worthwhile ritual to have in one's career.  You're not blogging to share with others in the hopes of becoming an influencer and gaining followers, you're blogging for yourself.  You need to get it out of your head so you can keep moving forward, and the lesson is important enough that you don't want to forget it.

Now that all of these projects have either ended or abated, it's been wonderful to no longer be working on a gazillion things at once.  While I certainly wish I had spent less time and money learning these lessons—not just the differences between these different modes, but the lessons themselves—I'm clearly better off for having done so, and so it's hard to be regretful.

It is just a shame though, that most of the educational system and the tech industry in particulary are well setup to teach people to create and to become obsessive about testing, but the opportunities with which to learn what it's like to build and how to do so are limited in terms of both access (who gets to drive the car) and scope (what kind of journey they get to go on).

On the other hand, it might just mean that I've got a lot more research to do.