Given that we’re approaching the initial launch of Resolution, there’s a lot to be excited about. Every feature, every capability, the simple fact that it exists, etc. etc., and so forth.
But the thing I’m the giddiest about might surprise you. Pricing!
Who can use Resolution?
There are a bunch of ways you can use Resolution, several of which do not involve paying for it.
- If you publish a model, anyone can view your model and even try different scenarios simply by clicking on the public URL. You do not need an account to do this.
- If you just want to try to build something in Resolution, you can do that without creating an account. If you decide you want to save it or share it, you’ll need to create an account or login to your account.
- If you want to save a model — yours or a copy of somebody else’s they’ve published — OR share a model, you can do that with up to two models with a free account.
- If you want to save more than two models (and help support the next generation of awesome improvements, wink wink), you can upgrade to a paid account for $65/year — basically $5 a month plus a couple bucks to cover my Stripe fees.
Why is this cool?
In my career, I’ve learned that there’s a big difference between wanting a bottom-up, community-driven growth strategy, and actually offering something that makes sense to be discovered that way. I’ve worked at a bunch of B2B SaaS companies over the years, and there was often a desire, or even a straight-up edict to “broaden the customer base” and lower the cost of acquiring customers by unleashing some kind of bottom-up strategy.
The problem was… we usually didn’t have the product for it. Instead, we had complex, non-obvious enterprise software designed to be sold over weeks of discovery and demos, to people who would then be onboarded by customer success professionals. At best, our “bottom up” product strategy was to offer a crudely-restricted version of our software at a cheaper price, and then hope that everyone would love it. When that didn’t work, we’d argue about marketing tactics.
By the time I had the core of Resolution working and was thinking about how to actually bring it to market, I knew that since it’s an early version of a totally new, general-purpose tool, I wanted to make available to as many different people as possible. That meant keeping the price down and going for volume.
That’s all well and good — “broaden the base!” — but I also knew it was a fool’s errand to expect random strangers to become crazy advocates for the 1.0 version of software they learned about directly from the guy who made it. Hoping you go viral is not a strategy, and “founder led sales” of a $65 product is a good way to run out of money. I’d be better off selling knives.
So in a moment that was both terrifying and very exciting, I made the internal decision to commit the rest of my pre-revenue development resources (aka, $$$) not to making Resolution more powerful, flexible, or beautiful, but instead to making discovery and sharing of the application as natural and useful to customers as possible.
There’s something about being able to actually use a certain kind of product, even in some kind of sandbox, that makes it seem real and helps people get it. This is especially true with Resolution; pretty much everyone who falls in love with it doesn’t have the “a-ha” moment until they’re clicking around and doing stuff.
For that reason, I really wanted to center the actual product experience. This is scary, and risky, because building good, usable products is much harder than everyone pretends, and building good, usable, bootstrapped 1.0 products is more or less impossible. I think this is why so many companies avoid it, and would rather show you a demo or talk about its value. I get it!
Still, I wanted that pressure — knowing people would be able to succeed or fail using Resolution right off the bat — to keep my product goals focused, and I knew that the more friction I put between the world and my product, the more of a bottleneck I’d be in actually getting it to people.
Long story short, this is why Resolution allows you to simply build stuff without even making an account. Internally, we call it “Scratchpad” mode, and it just basically means that you can pop in and sketch out your idea in a fully-functional version of the application. If you realize your idea is actually pretty good, you can then say “okay, creating an account is worth it”, and go through that (very short) process.
In allowing this (and investing the time and money to support a smooth transition from Scratchpad to account creation, and then to saving a model), I’ve basically prioritized putting the product in front of people over gathering potential customer information. Maybe this is a good business idea, maybe it’s not, but either way it definitely aligns with what I want to prioritize.
Free vs. paid accounts
My original plan was simply to restrict saving a model to paid users. Eventually, after both formal and informal UX research, I got cold feet on this and felt like it was too much to ask. I simply saw too many users who needed to (and were willing to) build two models, and often go back and forth between the two, before everything clicked. I didn’t want to force those people into a purchase decision before the value was really clear.
By making free accounts truly first-class citizens, and only limiting them by how many models they can save, there’s an obvious risk that I’m giving too much of the product away. But when I thought about my goals for getting this thing off the ground, I realized that I valued the potential of community building and user-generated models more than I did maximizing the odds of any given purchase.
I want people to build models and make better decisions with Resolution probably more than anything else. Partially that’s just me being annoying and insisting that the value of the product should drive everything. But I really do think it’s compatible with growing the paid user base — if people build one useful model and find two others, spending $65 is a no brainer. A world with more models out in the wild is a world I’m more likely to succeed in.
Building out the technology and infrastructure to make sharing models work (and work reliably) took a ton of effort, and is probably one of the bigger bets I’ve made at this point in Resolution’s history. We could have cleaned up a million different front-end experiences instead of doing this, but ultimately I chose opening up a fundamentally different social experience for this thing over expanding its power or flexibility. Frankly, my logic was simply that without sufficient discovery, it wouldn’t matter how cool this (already cool) thing got. If I can get off the ground and build a happy user base, we’re 100% coming back to expand the capabilities of the core product.
The other major question — should free accounts be able to share? This was a much tougher call, but in the end I once again deferred to making early stage community building as easy as possible. If you make something cool in Resolution, you should be able to get it out to the world.
Am I underpricing this?
For a small number of customers, absolutely. I think the vast majority of successful businesses that started out in a scenario like mine would probably spend a lot more time than I intend to zooming in on the kinds of people who see the MOST potential value in Resolution RIGHT NOW (independent consultants are a good example), and building a go-to-market and pricing strategy designed specifically for them. The price… would not be $65.
It’s possible I’ll still do this in parallel — I have a lot of vague ideas about how a slightly different version of Resolution could be way more valuable to consultants, for example — but I don’t ever foresee it overtaking the core, general-purpose growth strategy I’ve outlined here.
Will free accounts always have equal access to every feature paid accounts do? Probably not, because I have some very big, very ambitious ideas that might not even matter to casual users. Will I keep charging $65 a year for this? I’d certainly like to, but that’s obviously dependent on me moving enough units to build a sustainable business, which means Resolution has to resonate with a pretty large base of people. I don’t necessarily need it to click with the average person on the street, but we’re not talking about 500 customers a year, either.
Why isn’t this kind of strategy more common?
I don’t mean to make what I’m doing sound novel or more special than it is. I obviously didn’t invent self-service professional software. But, I don’t think this strategy would be possible if not for a couple of things.
Resolution is bootstrapped/self-funded. This is a huge deal because whether I’m right or not, I have absolute control over a strategic decision like this. I don’t have to stick my toe in the water, or execute multiple strategies at once to keep multiple investors happy or interested.
I set my own growth goals. This is obviously connected to #1, but more specifically, I can grow at whatever rate is financially sustainable to me. I know from a lot of experience that the reason so many companies abandon bottom-up strategies and try to move up-market is because it’s just really hard to 2x or 3x your revenue every year building an aggressively priced, general purpose product. Even if you start out priced for everyone and built for organic discovery, eventually your VC-backed growth goals start to necessitate a strategy shift, which is the main reason I want to be able to set my own goals forever.
Product usability is hard, and expensive. The “un-logged in —> logged-in —> paid” flow is really logical for users (that’s why I wanted it to work that way), but BOY is it complicated to implement. We needed a version of Resolution for looking at shared models that didn’t include certain controls. We needed to be able to hold on to a model state during the process of going from not-logged-in to logged in, or through account creation. We needed an answer (AN answer, not necessarily the best answer) for every edge case that fell somewhere in between those paths. And, because we were going for self-service, every time we left something unclear or weird, we knew we were probably hurting the business. Software is hard! Usable software is even harder. I’m passionate about the subject — if not particular qualified to solve it — so that helped, but man, I get it if you don’t want to deal with any of this.
Lastly, for all the aforementioned reasons, it’s really hard to “test” the value of especially smooth, frictionless experiences through the traditional MVP process, because it’s basically impossible to build a smooth, frictionless experience and still have it BE an MVP. So this isn’t one; it’s definitely a 1.0, and it definitely does not come with the validation and certainty I might feel if I had built a proper one. Unfortunately, not every concept in human computer interaction has a form that is both “minimum” and “viable”, so you can either just stay away from those kinds of things or prepare for more risk.
I Guess We’ll Find Out
Did I get any of this right? Who knows??? The truth is we won’t find out until we open this thing up and get people using — and hopefully paying for — it. So stay tuned, and prepare for launch.