> 2) assuming that what you are building is something the user wants - until people use it, you have no proof for this. Lots of startups fall into the trap of building stuff that nobody wants or needs.
> You have to pitch and explain the thing to them and even then they still might not get it. Only when you show them the thing and they like it will you get some confirmation that this might be something they want/need.
If you have to build first in order to pitch and show it, then necessarily you've had to assume that what you were building is something they want. Maybe your point was to get new features quickly into the hands of users to test the assumption early, but that has its own significant downsides.
I like the way you phrased it though, in terms of "don't assume foo" instead of "do bar", because it implies that there's really no replacing good old-fashioned _thinking_ with blindly following a 5-step plan to success.
> Users generally have no idea what they want, especially related to novel things.
This gets uttered like a mantra, and there is a kernel of truth to it, but people often take the idea too far -- so far that it becomes false.
People generally know what they want to accomplish. People generally know what workflows work for them. Around the edges, they may not be aware that a particular change will improve their lives -- but in the main, they're pretty good at telling that.
> If you waste time listening to the masses and have no initial vision of your own
You need both.
> Build something great and they will come.
This is not generally true, and I've seen many, many ventures fail because they believed this. History is jam-packed with objectively great things that were build but were rejected by the masses.
I think this mostly happens because the great thing did not address what people really wanted, and the company did not properly determine what people wanted. You can build the greatest doohicky ever made, but if it doesn't actually meet a real need in people, nobody will come.
>> build a product that I would like to use myself
> Yup, that's a first mistake, no?
No. The anti-pattern here is
"Build something you think other people would want because you would
like it."
transforming into ->
"Build something you think other people would want because you would
like them to like it."
(there's a subtle change)
In three or four startups I've been associated with, this was going
on. In psychology it's 'projection', and I think many young
entrepreneurs fall into it.
Indeed it's a common problem in digital technologies - the development
of a feature by one group of people, who've become convinced another
group want it, so push it against all evidence and market behaviour.
Innovators can get enchanted by their own idea, and really want to be
"creatively validated" by what they see as an "audience". This has
gotten worse as software startups took on the characteristics of a
"new pop music" business.
Or, (with existing semi-succesful companies) they get mixed up in
unconscious ulterior motives for wanting people to adopt an idea (such
as displacing another product/paradigm they dislike, or effecting some
kind of control over users (DRM etc).
>Your friend’s terrible prototype is worth 100x more than your great idea.
>Why? Because your friend actually did something with their idea. They created something. It may be terrible, but at least it exists. They’re now informed about how to proceed based on something real, something tangible.
I recall an article (or maybe it was a comment) posted on HN about someone who was very engineering focused about their start up. They focused heavily on code quality and product quality. Their product was said to be rock solid.
They had a good thing going in a space they believed would be huge.
Then over a few months a competitor showed up with a janky / flaky product and took all their customers. This new competitor output new features left and right, they often didn't work well, but they existed (unlike the startup in question).
It janky product, it was Salesforce.
Finding that 'executed well' in this case was getting features out the door.
"Executed well" could just be a matter of recognizing "right now we need to get these features out the door". How / when ... who knows how you figure that out.
> I'm going to launch a thing that can do this and that for you.
This is just selling an idea, not a product. You can sell anything this way, just promise something and trick them into buying, it doesn't mean that you can actually deliver on that promise.
> Then you can build something people want
The problem is that you don't know what people want. People don't know what they want. It's hard to know how to solve a problem or if a product will work unless you try it, there are so many unforeseen issues that can arise once the product is"done".
"The thing is, you have to talk to potential customers or you're taking on more risk than you need to. Yes, you can build something "useful", but what you and I find useful might be useful to 0.0001% of the population and not have wide enough appeal to make a business out of.
If your product is simple or easy-to-understand enough, your conversation can be a simple sales pitch and a preorder form -- if you get the orders, customers want it. Boom, validation. Don't waste your life building something you and your buddies/family think is useful until you find a bunch of people willing to pay you for it."
I'm sorry, I completely disagree with this line of thinking. When you make something useful for a market large enough to make a successful business out of, there is no mystery. I think we lie in the product development phase by telling ourselves that we are going to make X much easier than it is today but in reality we are just making an additional way to do something that may or may not save people any time or accomplish something that they couldn't do before.
Yes, people do lie about what they need/want, but there can still be money selling into that market. What I'm referring to is obvious, large jumps in innovation. Would another system for writing down todo's sell if I could integrate it with Outlook? Maybe, maybe not. I'd have to hear more and have it demoed, etc., etc., etc. In any case I probably wouldn't pay anything for it.
How about a car that travels on 1/3 the gas of a typical sedan and costs $300? I'd be interested in buying that no matter what. It turns out the challenge is not in understanding customers, but having the ability to build things that are really, obviously useful.
Obviously those are extreme examples, but if you look at a more granular level, the same applies. If you have to complete some job every day that requires three hours, and somebody shows you a tool that can automate much of the work and have it done in ten minutes, I think it's safe to say you'd open your wallet. Most startups don't provide that type of utility, and thus fail at closing any customers.
> Why not leverage what you know and build web-based products/services?
Because it's really difficult.
I find I can keep a big-picture, this is what the customer wants mindset, or I can have a detail-oriented this is the code that I want to improve mindset, but having both and/or switching between them is amazingly difficult. As I write the code I lose sight of what 'normal' people (non-programmers) want. I don't even know how to pitch to their level any more, or what isn't obvious to people who haven't spent 20+ years using and thinking about computers every day.
tl;dr: programming changes the way I think in a way that's unhelpful to build a product.
Next there's promotion and marketing... which is another skillset that depending how hard you want to push the product may/may not sit well with your ethics.
Thirdly and this is a personal one, I have an ADD brain and staying focused on one idea long enough to take it to market is very difficult. I have a list of ideas I dreamed up and started work on and never finished that someone else later launched successfully. As does everyone I suspect (execution >> ideas) but it's a neverending pattern (as I look at the 30+ OS projects on the go)
> I really hate the advice of don’t build something before validating. That has literally never worked for me.
> It’s so easy to sell something that people just get at first glance because it’s actually good at solving their problem, because you had faced that same problem and decided to do something about it.
What am I missing? You did validate it. You were the (prototype) customer, were you not?
> and perhaps pivot into a different product, one that people are actually willing to pay for.
Or of course pivot into a different market.
I think the hardest lesson to learn is that different people can value the same thing differently. The value of a product isn't just a product, but with respect to a user. It's not just the observed, but also the observer. You cannot evaluate it as a tuple of its qualities (particular features, price etc). You have to weigh each quality by the user's valuation it.
And different users value them differently.
It's seeming to me more and more that this summarises the entire startup problem.
As a developer, you have a clear idea of what features you want to add, how difficult they will be, how general they will be, and how cool they will be. You're not even evaluating it as a user, but as a creator. It's the difference between a novel that was interesting to write, and one that's interesting to read.
But even if you do manage to shift your perspective to being a user, you'll still only have one user's perspective. In fact, there isn't "a user", but a whole world of different situations, tasks, skills, equipment, knowledge and values - each of which counts as "a user", who will evaluate the qualities of the product different. e.g. for some users, a higher price makes it more valuable.
This is an incredibly obvious point, but it's one that I have to be constantly reminded of. Perhaps because the more deeply immersed I am in my work, the less evidence I have of other viewpoints (I can't see them, at best they're imaginary) so it's easy to not think about them. Or maybe I'm just excessively egocentric and solipsistic.
Different strokes for different folks. What might be right for you might not be right for someone else.
One solution is to imagine your ideal user (who'd love what you want to make anyway - whether they exist or not), and keep evaluating your product in terms of that person - including marketing. Users who are similar to that person will tend to fit themselves into the image. Guy Kawasaki (early Apple guy) talks about this. And that's what's happening in ThomPete's intriguing two examples.
> When we started development in 2009, few rich web applications existed. And with so few examples, there were no best practices to follow.
I think what you need is not best practices. You need principles.
If you take performance as a matter of principle from the get go, you will never ever ship a slow product.
Most startups nowadays seem to value design more than performance. They even value the design of their landing page more than they value the design of the actual product.
Another thing they seem to value is _perceived_ ease of development, at the expense of performance.
I say perceived because, in my experience, what you may perceive initially as a productivity boost ends up becoming a productivity burden as the code size grows.
>Why do people want everything for free when other have put a lot of effort on making it?
I don't think that's the problem. People will pay if what you build solves their problem. More specifically, they'll pay if they see that what you build solves their problem.
Before building, you should check:
1. Do they have a problem?
2. Do they know they have a problem?
3. How much of a problem is it for them?
4. Who, exactly, has the ability to act on this problem?
5. What language do they use to describe the problem?
6. Do they have any requirements that aren't obvious to me? Can I incorporate them into what I'm building?
If this sounds like marketing, it is, but it's the good sort. Building something people don't actually want is a perennial problem.
Rather than trying to sell what you have, figure out what they want. Then you'll know whether to:
It wasn't the original plan, but things change. You often don't know what you don't know when you first set down a path. Sometimes the bar for a proper MVP is beyond reach without a team. It can take a long time to realize that.
>Without real feedback how do you know if you are building something people actually want?
Good question. I've watched several companies come into existence in that time, and also watched several established companies add similar features to their products. Every time this happens it's both well received by users while at the same time revealing a larger trend. Each represents a piece of the same puzzle, it's just that nobody has put them together yet.
I'm also scratching my own itch in terms of what I'm building, so that's a plus. Fortunately it seems to be an itch a lot of people have.
> Do you usualy give one or multiple scenarios to complete?
I am OP, and it depends.
Im old enough that I have done this with paper prototypes, and it is shockingly effective.
Now most of the code I write is compartmentalized enough that with a bit of effort I can come up with a one off digital artifact. Just rip out the chunk of your app that you want to test and present ONLY that. Spend a day building ugly shims early enough in the process and you might make some dramatic changes!
> Be aware that you are not controlling the environment and the users may be distracted by outside factors. Which may affect some of your metrics (time to perform tasks, success rate...)
Even with those things going on your going to be shocked at not only what issues come up but how frequently. That thing you did that you thought was simple and sane, no one gets it. Do more than half of your test subjects comment on the same thing (good, bad, both) then you have a problem.
The key isn't controlling the key is listening...
I also want to state that a slighty drunk, distracted bar patron, getting through your process without quitting, telling you your product is shit, or giving up is a positive sign that in the real world people who are more motivated than "beer" are going to have a fairly positive and expedient experience.
> Don't promise features you are not planning to build and align your prospects expectations with.
As an engineer turned sales for my own indie company (15 employees today, had 0 when I started doing sales) - I partially agree with this point.
Don't build something custom simply to win a new customer. But there are a few times I've listened to a prospect describe their need and I though, "huh, that kinda wasn't in my original vision but it could be useful to other customers/markets." I'd subsequently tell them the feature is on the roadmap and pitch a higher price than I normally would.
Sometimes they bite, sometimes they don't. But on a few occasions, they came on board, I delivered, and that feature became a popular differentiator with other prospects.
>This is a common mistake: building a product based on assumptions, and not on the market's demand. I've learned not to add a feature before I have someone who paid an advance.
I first came across this sort of advice here:
The Montana Mogul: RightNow CEO Greg Gianforte (Part 1)
> My experience is that you push out the feature and test them. If there us usage, you keep them
There are virtually an infinite number of features you could be developing. But you have finite resources to develop them.
And some features will take a lot more of your finite resources to develop than others.
You need some way to prioritize what to actually develop.
If your product doesn't actually do too much but is essentially just clickbait, then, sure, your features are very cheap to implement, and you just throw everything you can think of out there and A/B test.
Start a project, commit to the technologies beforehand, and deviate under no circumstances.
Facebook was built with PHP. AdWords was built with MySQL. Instagram was built with Django. GitHub was built with Rails. Stack Overflow was built with Microsoft technologies.
It seems there are few instances where a "boring" tech stack prevents the product from being built. If the idea is good enough, you'll make it work with what's on hand.
If you can commit to a stack, yet still can't finish a project, you may have to face some uncomfortable possibilities: that your ideas are no good, or that you're simply not a very good programmer.
Attention span is a requirement for being a decent programmer.
> the minimum viable product preached by Lean Startup has limited practical use. Customers aren’t interested in funding your “learning.” They want reliable software that delivers value consistently. You must build the minimum desirable product, and if you don’t have a good understanding of what’s desirable before you start, then, don’t.
Oh, how I wish I could tell myself this five years ago. Maybe it's the industry I do most of my development for, but users I interact with very rarely want to hear "that will be in 2.0!" The ones that even let you finish the sentence before hanging up/walking out usually respond with "That's great. Let me know when it's done, then we can talk about signing up."
MVP and incremental development is great when you're a VC-funded startup in Mountain View, but when you're a real business you either have a working product that people want, or you don't.
> Why would anyone build features without any thoughts about their benefit?
> In practice you never know how a feature is going to work out
Those two sentences are somewhat contradictory. If you think through the features you should know exactly how they further your initial goal. When you add things based on what some people might like, that's when you are guessing and you can't know.
This all boils down to having or not having a vision.
Some leaders have a vision and you can see the long-term goals, others (like Google) throw things at the wall to see what sticks then shuts them down. If you're not a monopoly, that strategy will not work.
> You have to pitch and explain the thing to them and even then they still might not get it. Only when you show them the thing and they like it will you get some confirmation that this might be something they want/need.
If you have to build first in order to pitch and show it, then necessarily you've had to assume that what you were building is something they want. Maybe your point was to get new features quickly into the hands of users to test the assumption early, but that has its own significant downsides.
I like the way you phrased it though, in terms of "don't assume foo" instead of "do bar", because it implies that there's really no replacing good old-fashioned _thinking_ with blindly following a 5-step plan to success.
reply