Comment by kareemm
6 years ago
This is the right advice if you want to nerd out on technology. But my experience suggests[1] that if you want to build a business it'll be cheaper to validate problem/solution with phone calls and mocks / designs before writing code.
This is because:
* It's cheaper to make changes before code has been written
* A functioning product isn't the best sign that you're making progress - paying customers are[2]
Don't get me wrong. I like to write code as much as the next guy / gal. But I've made the mistake of writing code first. And I've worked with clients who - despite my best attempts - decided to forego validation to build a product that they spent a lot of dev dollars on to fix once the market met it with a trickle of interest.
1- https://uncog.com/archive/v2/why-only-fools-write-code-first...
2- https://uncog.com/archive/v2/how-to-get-paying-customers-bef...
I read it differently--this is not targeted at founders trying to validate a business plan, it is targeted at engineers whose job it is to build the product, and he's saying to quit fiddling around with your tools and focus on building the product--which is more fun anyway.
"It's important to learn how to use your tools well, but once you have, stop prioritising that. They're good enough now, you know how to use them. Don't get trapped in this local maximum of optimisation. Go and build stuff."
10 years ago, I wanted to learn Ruby on Rails, so I bought my first MacBook Pro. Just grabbed it off the shelf at the store.
I got my first software development job, and everything was great. I thought it was odd that the other guys didn't know much about Macs (and didn't really seem to care), so when they'd upgrade the OS I'd have to fix everything for them, or they'd have issues with gems etc.
I started buying every MacBook as they were relased. Installing beta software, upgrading the RAM and HD just because I could. Spending countless hours reading reviews, posting on forums...
The other guys just wrote code. Eventually I got tired of keeping up with the crap (or maybe I just got older) and now I crank out code on my far-from-the-latest MacBook, running Mojave. shrug
It was fun stuff, but I could have spent that time (and money) more productively.
It's really funny to me that someone could get excessively sucked into tinkering with and "nerding out" over Macs, the desktop/laptop platform that's by far the least inclined toward that. Usually stories like this start on Windows or Linux and end up on Macs precisely to minimize time & brain space lost to tinkering and esoteric platform knowledge just to keep things basically working OK, as the appeal of that sort of thing wears off.
I don't mean that in a bad way! It's just one of those "huh, so many different experiences out there, who'da thunk it" things.
1 reply →
This was also my interpretation.
You're correct - this was the intended message :-)
This is not what the article is talking about in the slightest. The choices are:
1) working on tooling 2) building the product
Of the two, which do you prioritize?
The article makes the case for #2.
That's it. Nothing you say contradicts what the article is saying, nor does it add to what the article is saying.
How do you get quality feedback? In my experience people will often say yes when asked or shown a mock up but will not buy. You don't find out who will actually buy until they try a functional product.
I really suspect that the lean startup method belongs in the early web era when there was a ton of low hanging fruit with simple market research and simple MVPs. All that low hanging fruit has been picked. Today it's pick your brutally hard problem and iterate for 1-2 years before you get a MVP that you can test.
> How do you get quality feedback? In my experience people will often say yes when asked or shown a mock up but will not buy. You don't find out who will actually buy until they try a functional product.
Ask them to pay you based on the mocks. If they say no, ask why. If they say yes, take their money and give it back in N days if you haven't built your MVP. I've done this BTW - it works.
> You don't find out who will actually buy until they try a functional product.
You'd be surprised how many people have gross business problems that some well-placed code would solve and they'd be thrilled to pay you for it because the other options suck.
I have real trouble wrapping my head around this kind of thing because I can't imagine paying for a product under those circumstances, no matter how useful it'd be. I get that it must work since so many people say it does, but it's totally alien to me.
If you don't have something to sell me, now, why are you asking for money? Am I an investor? No? Come back when you have a product. I'll probably still say no because I won't expect your business to last very long, but you'll be 100x closer to a "yes" than you are now, which is about as far from it as you could possibly be. Is this an unusual attitude?
1 reply →
This is the hard truth that people leave out.
Just build the product - the purest most minimal version you can. I mean be judicious with the knife, and slice like it's going out of style. Accept it - you're throwing out 100% of the code eventually - be fine with it; it's not ideal, but you'll ship and be live. Add the analytics you need - test hypotheses. Reach out to people who drop in and drop off, they're more valuable than features.
Don't agonize over "this isn't done", "this isn't perfect" or "it needs X to be useful". Get it out, charge for users, and you'll build a sustainable business, or it will fail quickly. Sure, this may not be VC sexy - but you know what, you can build product quickly, validate or toss and idea and move along or improve, based on feedback.
This ships. It ships repeatedly. It's not perfect, it's not awesome, but it works, always.
Read the second paragraph he is talking about:
> Ok, now -- what language was it written in? Which editor did you use? Use any open source libraries?
> In the best way? How long did it take to run the build? Was it easy to debug?
> Was it as memory efficient as it could have been?
> Were you building it on a really slick machine? What was your keyboard set up?
This article is about your improving your life as engineer, questioning your technical way of working is how you grow, but not always the way forward. Search this article for the words "company", "business", "startup" or "customers" and you will find 0 hits.
As someone who built probably 10 apps / businesses before I read the lean startup, and learned to validate things first, I think "JUST DO IT" is about the worst advice anyone can give you.
Maybe I was and still am a complete idiot. But I think a lot of people would be like me and just assume that lots of people want X, Y, and Z -- so go out and build the thing, and then realize nobody wants X or Y, and no one is willing to pay for Z.
I started doing financial models when I get an idea. What I always find out is -- even in my wildest dreams -- these ideas wouldn't pay more than my current job.
Granted, I make a lot of money. But I think the vast majority of people on here make more money now than is reasonable to believe their business could ever make, if everything worked out.
How much of that is just people wanting to make their own mistakes? This is one of those things where people only learn from making the mistake themselves.
Most products are mainly built by people who face that same problem their app solves. This gives them a reason to build it. As worst, it's used internally. At best, it's a side hustle or much more.
Conversely, you cannot validate product market fit without a product. Validation via “Is this something you can see yourself paying for” isn’t really a substitute for actually getting people to pay for your product. At best it will filter out just the worst ideas.
I agree. Earlier in my entrepreneurial journey I've spent a year building a product without validating it properly or validating it with biases (validating it with like minded people) only to find that not many wanted it when the product was released[1].
Tangentially, recently this motivated me to build a platform for validating problems by making people post their problems and even validate startup ideas as solutions to those problems[2].
[1]https://hitstartup.com/startup-ideas-vs-problems/
[2]https://needgap.com
It's fair to say this is line of conversation is tangential to the original post, but respecting the passion of your reply, do you think ideas like those represented in The Lean Startup perhaps over-rationalise the creative process?
Like, taking a rough guess, I wonder if there aren't as many successful startups, as there are successful writers. But no one takes those guides to writing a successful book quite as seriously as those guides to running or starting a successful business.
Not every problem can be solved manually. There are many businesses where the technology itself is the valuable thing, not just glue between humans doing all the work. "Don't write code" is smart when the code could be replaced by a person and a spreadsheet but that is not always the case.
Examples include circuit board layout programs, finite element modeling, any engineered hardware product, entertainment (like computer games), or anything other than pure business, really.
> Examples include circuit board layout programs, finite element modeling, any engineered hardware product, entertainment (like computer games), or anything other than pure business, really.
"Don't write code" really means "prototype first for your potential users". So if your code won't have users/customers, then write away. But hardware and entertainment can absolutely have low-fi cheap prototypes.
This approach is designed to elicit learnings to make a better product that's cheaper and faster to build. Of course you can write code first, but my experience suggests that that's a slower and more expensive approach.
To further your point, there is always a risk that some assumption you're making will turn out to be wrong. You should build the product only when the risk of not building it is greater than the risk of your assumptions being wrong.
Users fixate on low-fi even if you tell them it's a prototype. Talk about a blocking bug.
1 reply →
Playing devil's advocate here:
This is basically an attempt to gather more information before you act. In principle, that's an Obviously Good Thing. But you have to question whether that information is actually as conclusive as you want it to be, and whether you're changing the outcome by observing it. There's two problems with the information you gather by making phone calls and showing mockups/designs:
1. Mocks/designs only communicate a fraction of the product, and often the parts that aren't visible in mocks/designs are the most valuable parts of the product. Speaking in vague terms: I'm working on an app where the main value is that it calculates actionable numeric values that users typically calculate in spreadsheets. The UI is certainly a selling point, but users aren't going to easily understand the connection between the new UI and the old spreadsheet formulae without playing with the actual product. Phone conversations are likely even less communicative.
2. Communication is a two-way street: releasing early allows you to get information from your users, but it also leaks information to your users, which may not present the image you want. Kickstarter has shown that with good enough marketing you can get paying customers with literally nothing. But you can also burn customers so they never want anything to do with your product ever again. There are numerous high-profile failures-to-deliver that have killed not only products, but the reputations of individuals and companies. But failure doesn't have to be that catastrophic to lose customers permanently: all that has to happen is for someone to pay for your product, find it a bit lackluster, and decide to cancel their subscription. That user is worse than a non-user, because they are never going to be a user again, and might tell others about their experience. Short term success not only isn't an indicator of long-term viability, it can cause long-term non-viability.
Sure, it's cheaper to validate problem/solution with phone calls and mocks/designs, but you get what you pay for.
The best strategy probably lies somewhere in the middle: code a minimum viable product, but really make sure it's the minimum, and really make sure you think it's actually viable. A good compromise might be to release a discounted beta for select users--that lets you get feedback from paying customers up front, but also sets expectations so that users don't get the wrong idea about your product before it's mature enough for a real release. It also limits the exposure, so even if you burn a few beta users, you don't burn your entire potential user base.
> I'm working on an app where the main value is that it calculates actionable numeric values that users typically calculate in spreadsheets.
Even this sentence is a perfect tool for validating the market: I have no idea if the product is for me! ;-)
(I get that you may be keeping your product’s specifics vague here, but by doing so you’ve provided a contrived example of how a simple description of the product itself can help find information about the target market. I have no idea if I’m in your target market, for example, so if I’m supposed to be, that’s a problem.)
See point 2 above.
You probably are my target market--it's a pretty broad demographic. But if I showed the product to you now, you'd probably be unimpressed and forget about it, which probably loses you as a customer forever. Better to wait another few weeks and give you something that actually solves a problem you actually have.
There's only one chance to make a good first impression.
Agreed.
I'll write something (or even just put together drawings) for someone and the first review of something like really light prototype / sketch where I get direct feedback from decision makers and/or users is FAR MORE TELLING about where things are going to go than anything else.
It's amazing how much pivoting can happen there.
http://momtestbook.com/