How to Build a Category-Defining VERP - Part 2/3
This is part 2 of a 3-part series on Vertical ERPs (VERPs). Here is Part 1 and Part 3.
Vertical ERPs (VERPs) are one of the next decade's largest startup opportunities. By combining vertical software and embedded fintech, VERPs are significantly expanding the TAM of every market they touch, while rewriting the traditional SaaS playbook and unit economics.
VERPs are so powerful because they represent the source of truth for a business, centralizing all of its critical parts, its inputs, its outputs, and all the processes in between.
When evaluating VERP opportunities and building a product strategy, it can be helpful to start mapping those critical parts and input-output flows. Below is an example of a service-based freelance business, like Bonsai:
As a rule of thumb, if you were to do user interviews with 20+ of these businesses, the objects in the map should be the nouns that appear in the overwhelming majority if not all of the interviews.
10 people may do this exercise and come out with 10 slightly different maps. Maybe the atomic units are connected in a different way, or maybe there are a handful that appear in one map but not another. There is no objectively correct way to build such a map for a given business. However, you will find indisputable atomic units.
For example, I would expect 90%+ of freelancers to mention proposals, contracts, invoices, and payments when they describe a typical project, but some might omit to-do’s or time tracking.
Here’s another good rule of thumb on the level of resolution to use: focus on the type of product or tool a user describes rather than a specific brand-name product. For example, note where in the workflow to-do’s, invoices, and documents fit; don’t focus on Asana, Xero, and Google Docs. It can be helpful to note the actual product, but your maps should describe the underlying product function.
I’ve found that the objects included in the map often contain implicit assumptions about the user’s persona (e.g. certain types of freelancers use time tracking while others don’t). It also says something about the scope of the product that the entrepreneur envisions.
Here's another map of a restaurant business, for building a VERP such as Toast:
I like to highlight atomic units that represent where money flows in or out of the business, as these are key points of leverage in the product for retention and/or monetization:
With these units mapped out, you can start thinking of the connections between them as key workflows that represent products. Although you ultimately want all of these concepts represented in a VERP and touched by multiple products, you can start by mapping out a single workflow whose product can be a wedge or MVP for this.
For example, the workflow below represents the core workflow at Bonsai, where a freelancer goes from a proposal or quote to legal contract to invoice with their client:
Because VERPs are bundled, all-in-one products, it can be difficult to achieve feature completeness quickly. The best practices around finding a wedge and building an MVP apply here just as they do with pure software businesses. While you want a product roadmap that ladders up to the full suite, you should start with a product that absorbs one specific workflow. You can differentiate this product and make it more attractive by having it be highly opinionated and embedding the assumptions or best practices of that market into it.
You want to start as close to the flow of funds as possible. However, it can often be difficult to start too close, as companies will be wary of trusting a new startup with a bare feature set with their money. It's often best to start in a cash flow-adjacent area, earn your customer's trust, and then add products that actually touch the money.
One of the most common patterns here is to start with a workflow that's adjacent to invoices or whatever most closely maps to income in a given vertical. Prove that your product is valuable and sticky adjacent to invoices, then get the company to move over to your invoices, then get them to move over from their existing payment processor to you.
In the next essay, we’ll discuss pricing strategy for payments, as well as monetization opportunities once payments and workflow are tightly integrated. Click here to read Part 3, "VERP Product Strategy: Vertical Software, Payments, and Beyond".