If you’re new to this newsletter, click here to access the rest of my newsletter articles such as the “Why We Passed on this Startup” series, reflections on investing, and tactics on winning in the market. Now, onto today’s post!

It’s taken me 10 years, through thousands of mistakes and a couple good decisions, to write this post.

Here are five things that I would do if I were doing a venture-backed tech startup today….

1) I would work with a technical person to build my product.

✅ Startups that have a technical person at the outset have an order of magnitude difference in progress than startups that don’t. ✅

The key in startups is speed. Speed to hypothesize. Speed to build a feature around that hypothesis. Speed to experiment in the market in real time. Speed to learn and iterate again.

The speed in startups comes the velocity of putting together mini-product experiments to see which product should be built.

In my FinTech, startup, we used founder funds to hire a software development firm to build out our MVP. One year and $242,000 later, we had a working MVP that didn’t satisfy the needs of the customer. There was little experimentation in my case because the arc of our MVP was tied to a third-party developing our product.

As an investor, if you were to step into my mind, you’d see that there is a major single difference from startups that scream into the market and the ones that stagger into the market - it’s a technical person being able to build from the beginning. I’ve seen founders with an otherwise great idea totally handicap their progress by not having a tech person by their side.

Now, this could be a co-founder, but doesn’t need to be. It could be a high caliber computer science college student that you pay nights and weekends to build an MVP. It could be a friend that is a strong coder that wants to take on a side gig.

Find a technical person who is competent, has capacity, trustworthy, and has passion for what you’re doing, and get building. Get to market, iterate, and repeat. Don’t get hung up on a getting a “technical co-founder.”

If you are wondering about how to think about compensation for that person, check out the article I wrote on “How NOT To Give Away Too Much to the Wrong Person.” 

2) I would be laser focused on a specific problem use case, first

Many founders are naturally too high level in the problem that they solve. So, they build an overly general product that doesn’t solve anyone’s problem.

I once wrote about the three levels of a market problem - the Google Earth view, the Google Maps view, and the Google Street view. See my LinkedIn post for reference.

The "Google Earth-view" 🛰️ problem - This is the big change that the startup wants to want to see in the world. It’s the 10 year vision. It often involves industry-changing language or vision-related language.

The "Google Maps-view" 🦅 problem - Where the focus zooms in, similar to the map focus on a smaller geographical area or neighborhood. The startup sees a series of problems in a given company or industry and that need to be solved, and decides to solve all of them at the same time.

The “Google Street view” 🚘 problem - This is a super narrow, use-case specific problem. Here is the key - this is the market entry point of your startup.

In my FinTech startup, we were way too broad in the problem we were solving. In fact, we started with a problem statement that a customer described as, “I want a system that tells me which bonds to buy and sell everyday.” In retrospect, that statement is devoid of the ideal customer profile. It’s devoid of any layers of details that actually matter on what solving the problem looks like. This potential customer was expressing a Google Earth view of the problem - how this person wanted bonds to be traded in the future.

But startups, out of the gate, de-risk themselves by building to a Google Street view, narrow use case of the problem.

✅ I define a specific use case as an action that has a tightly defined start time and a tightly defined ending time for one person (customer/user). ✅

Furthermore, if this action has a high frequency of occurrence, then you might just have a solid use case on your hands. ✅

So, startups should be looking for defined start and defined ending points in time to build their product around. They should not start with solving an entire workflow. (That is the Google Maps view)

Why a use case? Because solving for one use case shrinks the size of the product needed to start solving a problem. (See the emphasis on speed in #1 above.)

In the words of your customer, a use case sounds like, “When I do X (specific action), every time I have to do XYZ, and it’s __adjective that describes the pain____.”

The “When I do ________” phrase often communicates a potential use case to go after.