What are we building?
In June, I co-founded Schematic with long-time collaborators & partners Ben, Jas, and Gio. We’ve worked together across several venture-backed SaaS companies for most of the last 8 years.
In Schematic, we’re building the Auth0 for packaging digital products.
The core problem we’re addressing is that supporting the inevitable evolution of packaging (from single product to multi-product to enterprise selling and so on) is consistently complex and expensive for product and engineering teams.
This problem starts in the product stack, but bleeds into the entire quote to cash stack.
Our beachhead product is designed on top of feature flags to decouple business tools and packaging logic from applications, so that developers can focus on building features without having to consider how those features are sold & billed, and vice versa, so that GTM users (product, success, sales) can package & sell flexibly.
As of October, we’ve signed LOIs with 6 high growth design partners & we recently released early access to those partners.
How do I spend time?
In my role, I’ve organized my time into several broad categories:
Market discovery — many conversations with the market to understand the problem deeply, as well as how people solve it today, whether they believe it’s abstractable and urgent to solve for, their requirements in a solution, and the value they’d place on a good solution.
Design partners — finding high growth companies that A) believe the problem is critical to solve; and B) orient toward working with an early stage company like ours to outsource the solution. From there, working closely with them to ensure that A) they achieve the value they expected; and B) we accelerate our understanding of how to solve their problem delightfully
Synthesizing & communicating what we’re learning — weekly written reflections, journal entries, community updates (like this one), investor updates, and pitch decks (sales & investor decks).
How have we approached product & customer development?
Someone (I can’t remember who) once said to me, “you have a few decisions in life that matter. Try to get those right.”
Beyond the obvious big decisions we made (e.g. who our co-founders & investors would be), the most consequential decision to date has been the decision to pursue product & customer development via the design partner model.
The design partner model in its basic terms is this:
Startup has a point of view on a problem & how the world might look if that problem were solved
Startup offers the market a choice between the status quo and its vision for what could be
Startup works to find companies who believe in the choice that the startup’s vision would provide to the market
Those companies agree to enter into a design partnership with the startup to execute on a clear set of deliverables. From there, the startup works closely with the design partners to ensure that the solution actually solves the problem.
If the startup’s solution ends up delivering the desired value, the design partners eventually become the startup’s first customers. The design partners receive a material discount for their important role in co-development, and their testimonials fuel the startup’s ability to grow, attract capital & talent, and invest in making the product the best that it can possibly be.
There are several specific elements of a design partnership that, when effectively managed and run, accelerate value creation & innovation. Those are:
Design Partnership Agreement / MSA — by including an MSA in a design partnership, three types of value are accelerated: 1) the startup actually has to sell, prior to having any product. This process teaches the startup upfront whether its actually solving a meaningful enough problem. 2) A clear set of deliverables is established between the startup and the design partner that more clearly align expectations & the definition of success (e.g. should we succeed together in solving this problem, this relationship will become a relationship between customer & vendor). 3) The startup takes a significant step in de-risking an investment decision for outside capital. We found this agreement form from Common Paper a useful template to build from.
Willingness to pay — Madhavan Ramanujam frames this concept with more eloquence, writing "Price is more than just a dollar figure; it is an indication of what the customer wants — and how much they want it. It is the single most critical factor in determining whether a product makes money, yet it is an afterthought, a last-minute consideration made after a product is developed.” Willingness to pay is also a useful exercise for buyers & design partners to go through with startups & vendors, and I would argue that it's a critical factor in determining the extent of the value buyers can realize. Here’s the willingness to pay template we created.
Message market fit — one of the universal challenges with building enterprise software is determining how to position the software, or in other words, deciding how to talk about the problem and the solution. Great design partnerships facilitate message testing to help startups communicate to the market, using the language of their customers. Here’s the messaging template we created, and below are a few screenshots of the creatives we’ve tested.
Co-Marketing — early on, startups need to spend a lot of time evangelizing the problem they’re solving. There’s almost no better way to do this than in collaboration with real companies and users that have the problem firsthand. Here’s an example.
Product Exercise — Last but not least, great design partnerships ensure that a startup’s early product versions get a lot of exercise and pressure, accelerating debugging, stability, reliability, and delightfulness. As one investor recently said to us, “usage is like oxygen for an early stage product.”
What do we have to prove?
I’ve written at length about this question, because I think it’s so important. In Patrick O’Shaughnessy’s interview with Whoop Founder Will Ahmed, Ahmed says, “I think a lot of building a company from scratch is figuring out what you need to prove at what stage.”
Over the next few months, we have 2 things we need to prove:
that our design partners trust our service in production
that once it is running in production, it is valuable enough to begin paying for
Final Note
It’s been energizing to found again. Many readers of this newsletter have played a significant role in our pursuit of building Schematic, for which I’m grateful and energized.