Internal Product Market Fit

Increasing your teams' product output without reliance on your product team.

The Problem

Many early-stage venture-backed companies rely heavily on their product teams - perhaps more heavily than what is really necessary.

These companies often get blocked or slowed down by their product output because there is only so much the product team can build; tasks like getting customers' data into a CRM, reporting on data, building MVPs, etc., can pile up because the product team does not have the capacity to handle all of the requests.

How can this be resolved?

In recent years, we've seen an explosion in no-code tooling. These tools require little to no technical knowledge and give users the ability to build websites, mobile apps, integration workflows, etc. It started with website builders like Wix, Webflow, and Squarespace, and then workflow builders like Zapier and Integromat. Now we’re seeing mobile app builders like Glide.

These tools facilitate non-engineers to build products without the need of an engineer or the technical knowledge an engineer possesses. Enabling non-engineers to build takes the pressure off the product teams and allows anyone to go out and create what they need in order to test a hypothesis or build an MVP.

At On Deck, we heavily rely on no-code tooling to enable anyone and everyone to build whatever they need, whether that be an internal tool or an external facing product. The product team typically does not harden/build anything in code until it has been validated in no-code tools. Once these products are created and start to "break" or get limited by the no-code tooling supported features, the team members will bring it to the product team to build in-house, most likely adding functionality the no-code tool doesn't support. This is a game-changer; taking pressure off the product team and allowing anyone on the team to create what they need.

Product Market Fit

Product Market Fit aka PMF was coined by Marc Andressen back in 2007.

Product Market Fit means being in a good market with a product that can satisfy that market.

It has become the go-to phrase for startups to describe if they've found a product and market combination worth dumping money into to scale.

At On Deck, we have this idea of Internal Product Market Fit (iPMF), a term which I will attribute to Andreas Klinger. As I previously mentioned, we don't build/harden products in code until they hit this idea of iPMF, meaning they've been implemented and validated using no-code tools and now need to be built in-house to be customized and/or scaled. This practice works well because it enables other teams, like ops, growth, and marketing, to build out what they need without relying on the product team and without wasting time writing code on things that haven't been validated.

There are three reoccurring reasons we move away from no-code:

• Nuance - there is a very specific set of things we need that the no-code tools just can’t do.

• Scale - we are scaling and it is getting hard to manage within the no-code platforms

• Complexity - the no-code infrastructure is getting too complex so it needs to get extracted and optimized.

An example

I’ll give you an example: at On Deck, a core part of our operations is the application process for potential fellows. These applications are quite complex and are different for each fellowship. Many startups would have built this in-house. This would have been slow, bug-prone and constantly require changes due to how fast things move. Instead of building our own system for the applications, we built the entire flow using no-code tools. The current application process uses Typeform with Zapier triggers that send the data to Airtable (am many other things like confirmation emails, mailing list subscriptions, referral tracking, etc.). This works incredibly well. However, over the last 12 months, we have grown considerably, now having more than 16 fellowships and countless fellows. The application process has been iterated on and redesigned many times using the no-code tools, but we’ve now started to hit a place where it is hard to scale from here. We have many Zaps that are duplicates of each other for each program, we have limitations on the branding and UX we can provide through Typeform, and we have limitations on the reporting of analytics.

At this stage, we’d say that we have found iPMF. That is why in Q2 this year, we started building the application flow in-house in order to improve the experience and add custom features that no-code tools couldn’t support - like a UI that matches our brand, the ability to edit your application, and others. This process worked well for us because we already knew exactly what we needed to build. It was already built, validated, iterated upon by the people who use it every day and know it best. Because of this, we were able to get the product team up to speed to quickly and effectively rebuild it in-house. 

My predictions

As mentioned, the No-Code space is exploding but there is still a lot of room to grow. Thinking about how this market is changing, here are some of my predictions for the next few years:

1. We will see no-code tools start to build out comprehensive APIs so product teams can successfully build on top of these tools instead of rebuilding in-house once they grow out of them.

2. No-code platforms will start adding more complex features like enterprise-level logging, testing environments, and sophisticated version control that will enable larger companies to take these tools more seriously.

3. There will continue to be an explosion of no-code tools, especially in the workflow and integration space, pushing the bar farther and farther. Many of the current big tools are going to get disrupted because I don’t think they will keep up. Zapier and Webflow are both ripe to get overtaken by someone who solves their shortcomings.

Closing

In my opinion, this is just the start of practices like this; as no-code tools get more sophisticated, we will see more companies follow this pattern. It will take the reliance off product teams and help early-stage companies reach PMF faster and more efficient than ever before.

TLDR;

• No-code tools are exploding (Airtable, Zapier, Webflow, etc.)

• Product teams often build things that aren’t needed and slow down the non-product teams due to lack of bandwidth.

• No-code tools enable non-product teams to build and validate MVPs before handing them off to the product team to be built in-house.

• No-code tools still have a lot of room to grow and mature, and there is a lot of room for disruption.

Image creds to BudiBase and Joe Johnston.