MVP's: What are You Trying to Do?
Techstars Korea Talk Part 1
Do it. Distribute it. Understand it. Repeat.
A few weeks ago I was invited by my good friend (and current EIR at Korea Techstars) Dan Kim to chat with some startups he’s working with. To be honest, I was honored that he thought I could contribute something, but was happy to try and help folks learn from my past and in-progress mistakes!
Dan prepped me with some context about how there is an incredible amount of high quality intellectual property, especially in deep tech, coming out of South Korea, but startups that are commercializing this IP often struggle with how to turn killer research into a killer product.
We talked about what might be the most helpful topics for the startup teams to hear some thoughts on and landed on MVP’s (minimum viable products) as a starting point.
This is a lightly edited summary of the first part of the conversation!
MVP’s - Doing the Damn Thing
What are you trying to test?
This might be the only question that matters at the earliest stages of your startup’s life.
If you can’t frame this as a yes or no question, you’re probably trying to do too much.
Things like:
“Can I get people to send a payment through this app?”
“Can I get this person to create an account on my site?”
“Can I get people to sign up for this waitlist?”
Are good places to start.
Anything more than that is probably overcomplicating it before you have any useful data.
If you’re struggling to narrow down a question, try asking yourself this:
“What's the smallest, dumbest, most basic, toy version of your idea?”
Don’t be clever. Be dumb.
Like really dumb.
Like this dumb.
I’m building a zero fee payments network on decentralized rails.
This is a huge, complicated, messy monster of a challenge and I’m nowhere near this product yet.
So what question am I’m testing?
“Can I get anyone to buy an NFT through my app?”
Much dumber. Much better.
You have to be dumb because you’re smart. Everyone reading this is the kind of person who wants to really crush the thing you’re working on. This personality quirk means you’re going to do too much work on your MVP.
This means you’re going to delay your MVP launch.
This means you’re going to wait too long before getting actual user feedback.
This means you’re ultimately going to die because you’ll run out of money before iterating to the right version of your product.
It’s harsh, but it’s true.
Reid Hoffman wrote that “If you’re not embarassed by your MVP you waited too long”.
It’s oft repeated, but oft ignored (because it’s hard to risk your ego with your product).
So. Be dumb with it.
Then you can start the real work.
MVP’s - Distribute the Damn Thing
When you put your MVP into the world, it will mostly get ignored.
Unless you have some sort of instant distribution via a Twitter following, substack, or something similar, you’re going to basically need to beg people to use your thing.
If you don’t need to beg, you’re already on to something hot.
Unfortunately, most of us aren’t that lucky. So we gotta work for it.
Friends and family is a good place to start begging.
Don’t ask everyone in your life all at once though.
Stagger the asks so you get a cohort of 5 or so people at a time to start.
You’ll immediately get good feedback on things that don’t work while also avoiding getting 20 people all telling you they don’t know how to login.
Knowing it’s hard to login is helpful, but not nearly as helpful as learning that from the first 5 people, then the next 5 people telling you something else that’s wrong with your thing, and then the next 5 people telling you the next broken piece, etc etc until you’re Google.
Because eventually you’ll run out of friends.
That’s when the hard part starts.
You’re then going to have to convince strangers to use your thing.
Most will ignore you. Some will say no. Some will say yes and then ghost you. Some will say yes and then bounce off the page after 2 seconds. Some will say yes and click around a bunch and tell you it’s awesome without actually having tried to use it.
A few will actually try to use it.
Again, try to stagger your public pushes so you can make improvements longitudinally rather than spend $10K on a huge launch only to find out that your login fix from your early tests actually made it even more confusing to log in!
Distribution is going to be a lot more work than you’d like it to be.
Every marketing channel gets tapped out eventually (usually faster than you hoped).
As a founder, you should always have your eyes and ears open for new distribution vectors. They’re more valuable than gold.
MVP’s - Understand the Damn Thing
You’ve begged. You’ve got some users. What now?
Look at the data.
Look at what people are doing.
If you aren’t tracking sessions with something like LogRocket or Heap you’re not recording most of the useful information about what’s happening on your app. If you’re doing physical product testing, record the sessions.
Play them back. Watch what they do with the product. How they try to use it.
What assumptions did they make about how it worked?
Don’t just ask. Infer.
Sometimes your users will tell you something useful.
Most of the time they don’t realize what they actually do with a new product so their thoughts aren’t that helpful.
The big exception to this is visceral emotional responses. Listen for these. Listen for Rage Clicks. Did they say they loved something? Hated something?
That verbal feedback matters.
Obsess over these details because this is how you build and interpolate and extrapolate a product roadmap.
I try to deliberately list out all of the possible features/improvements/fixes I could possibly do with my app.
Then I prioritize based on the user feedback.
Not just prioritized for what they say they want most, but to optimize for speed of shipping of features and improvements. It’s important to realize that it’s pretty rare to launch a killer feature with one round of iteration.
It’s much more common that 5 or 6 separate fixes over a few cycles improve the quality of an app so much that it feels like an entirely different product.
It’s crucial to optimize for a faster shipping cadence vs longer waits with “more features” with each release.
Every extra week without a new feature is another week without new data about how users think about your thing.
All of this is even harder with hardware products because hardware is just…harder lol. Longer lead times with supply chains, more friction to change anything, and capital tied up in old inventory just exacerbates all the things I’m talking about.
You’ve heard this before, but you aren’t going to listen to it.
Try to listen.
I have (very smart) friends who took a year to ship their product because it "wasn't good enough yet".
Guess what happened?
A lot of their work was wasted because once they started getting user feedback they realized they needed to pivot pretty hard.
That's not a them thing. It’s an every founder thing.
If they had just done it, distributed it, and understood their MVP’s faster they would have gotten to where they are now…a year ago.
I hope this added value to your day.
Please share this with someone who might find this interesting!
If you have any thoughts or questions about this essay - Let’s Chat
To hear more from me, add me on Twitter or Farcaster,
and, of course, please subscribe to Wysr