Table of contents
There is a lot of dogma around shipping a product in startup land. Many founders follow strict patterns they got from a book or some influencer's tweet.
"Ship Early" is one of the more stubborn ones, and in many cases it is exactly the right thing to do. The earlier you start learning about what your users' problems and how your product solves that, the better.
I shipped Checkly fairly late. This was partly due to personal quirks and partly because I knew launching early was just not in the business's best interest.
I'm entering an established market
Shipping early works when you’re going after a new market where there is little proof anyone wants your product. If you are going after an established market with great players, it falls flat. You need to compete. Your half baked Bootstrap site with two features for $30 a month is not going to cut it.
Checkly is a new product in a competitive, already established market — Pingdom and Runscope are fantastic products and Apex Ping is a great inspiration. I’m not trying to “win” on feature set per se but rather on ease of use, UX, pricing and focus.
This means Checkly needs to at least deliver on those goals and that takes time. A Wordpress site with a stock Bootstrap theme won’t do.
I'm a polisher
I’m a bit of a polisher. I like it when things work smooth and look good. I strongly believe typography, color, visuals, snappiness, attention to detail and choice of words matter.
Actually, I tried lowering my standards and going with more “stock” things or not obsessing about padding and fonts: a rough MVP in popular terms. Turns out I get frustrated and hate working on my own project! It lowers my moral and is surely a sign that this “rough/mockup/MVP” mindset does not work for me.
I needed a bedrock
Some things you can piecemeal / iterate together and you end up with something nice. I guess some writers and musicians do it that way. You start small and add and expand as you go. Multitracking and overdubbing can produce fantastic record.
In IT land we call this Agile. Or scrum. You get it. Agile / scrum does not work when building out a backend that should be the bedrock for your Saas. Designing the data model, developing the infrastructure, integrating with cloud providers are all fairly well done in a planned, waterfall-ish way.
First impressions do matter
Users don't like it when your SaaS breaks due to bugs, wrong logic or patchy integrations. Shocker. In many cases however, this is not a direct reason for users to jump ship: invested users tend to be pretty forgiving.
But this loops back to the established market. When there is a somewhat suitable alternative in the market, you bet that your user always has this in the back of his/her mind when another bug pops up. Launching broken code just puts you one step behind right at the beginning of the race.
Is at an MVP then?
I guess all of this comes down to how you define the term Minimal Viable Product or MVP. When meeting fellow founders working on vastly different projects, this is always a pretty confusing discussion.
<insert Chris Pratt meme: "I don't really know what MVP means anymore, and at this point I'm too afraid to ask">
A simplified example. I do some freelancing on the side. I build simple landing pages and other one page, temporary websites. The term MVP gets used a lot and we actually make MVP-like things: Simple Bootstrap-a-like page, some good, readable copy and nice image or two, contact details and some links: boom, done.
This is enough for 95% of the visitors to the page and if they can't find what they need there is an email address or chat box right there. That takes care of the remaining 5%.
The term MVP makes sense here. Sure, we could have spend one more week tweaking, editing, animating, testing etc. etc. But we choose not to as the diminishing returns pile up.
But the terms "minimal" and "viable" are both stretched beyond recognition when you enter a well established SaaS market. What is minimal and viable in the B2B API monitoring market might be a pretty big list of features and non-functional requirements.
I mean, I just filled out a 40 question security survey for a hot lead, a Japanese Fintech. One of our most used features is inviting team members and sharing the Checkly environment among coworkers. This includes RBAC access control, password resetting, invite sending & invalidation etc. etc.
You catch my drift. That's not MVP territory anymore, at least not how 95% of the people I meet define MVP. I would say that for my market, it is an MVP. It's the price of entry.
P.S. I stole the title of this post from Guy Kawasaki. I love his directness and this video on 10 mistakes entrepreneurs make is startup gold wrapped in comedy gold.
banner image: detail from "Eight Scenic Snow Views of the Eastern Capita", Hiroshige Ando, 1797-1858, Japan. Source