[tinyvm]

While the read was interesting and bring solid points, I strongly disagree with the majority of the arguments.

>The biggest mistake I see developers make is assuming that they are building something that people both want and will pay a meaningful amount of money for.

Lots of projects were build with no exact plan on how to monetize them of if there would be customers to buy it. They just had a vision about how X or Y technology should be , and just created something by putting their guts in it.

The idea that you should marketize something before starting to build is coherent but not true for tech especially when Innovation sometimes requires to educate the customers about how to use a technology , Serverless and Docker are good examples of that I think.

>The best way to do this is by asking good questions, and then listening carefully and taking notes

Again I strongly disagree here. This pattern pushes entrepreneurs to create a version++ of something already existing because the customers told them :

"We are using [Insert Tech Name] and it doesn't support feature X"

So the entrepreneurs would rush to it's keyboard create a clone of the Tech and add the feature X.

This is usually called consulting in my opinion and they are already lots of people doing that... Being a "Founder" of something involve taking risk and not just adding a tiny feature because it can brings money on the short term.

It's about having a vision.

As a result , we could quote the hundreds of email startups we have today who basically do the same thing with often one tiny feature of difference...

> that does not mean that you have created enough incremental value for customers to make them willing to pay you a meaningful amount of money for your product

I agree on this one.

[Fergi]

(Jeff from PipelineDB / author here)

Thanks for the honest feedback. You are definitely correct that there are many successful projects and businesses that did not start with a clear sense that people would use or buy their products. But there are a disproportionately large number of projects and businesses that have failed, precisely because they did not have a clear sense that people wanted what they were making and would pay for it.

Also, this post isn't saying that builders shouldn't begin with a strong, fundamental conviction about how things should be dramatically different. I, as the author, would actually argue the exact opposite. The point I'm making is that once we have our convictions, we should test and measure the extent to which those convictions are correct before investing large amounts of time, money, and energy into productizing them.

Lastly, the point about asking questions and then listening to customer feedback would only result in building minimally better products if the product hypothesis we start with is itself unimaginative. But that hypothesis can be literally anything. Customer feedback simply teaches us if market demand lines up with our assumptions about market demand.

[_zbkl]

A "Hobby" project turning into a business is a rarity. It comes down to expectations of returns.

If you want a business, a monetize-able product, you have to think about sales. The observation that majority of Software start-ups fail to avoid the mistake #1 from this article is accurate. And majority of Software start-ups start with an expectation of monitory returns.

If the expectation is a personal sense of fulfillment, anything other than a business for that matter, then what you are creating becomes more of an art than a product. There is a chance you might earn from it, but it is slim.

[dandare]

I agree with tinyvm and I agree with your replies, it all should be part of the wisdom.

I have the honor of making all three mistakes you mention and my project didn't end up well :).

[matthewmacleod]

So the entrepreneurs would rush to it's keyboard create a clone of the Tech and add the feature X.

The important thing to remember is that most software isn’t that special. Sometimes you will be redefining the whole market; more often you will be building a faster horse. But that’s okay! People using horses still want them to be faster, and it’s a valid and often successful business strategy to sell products which are similar to, but better/faster/cheaper than, your competitors’.

[benjiweber]

I don't see listening carefully and asking open ended questions as a step towards simply building what the potential customer wants.

Quite the opposite: seeking to understand their underlying needs, the context they are in, and the factors influencing their thinking helps build empathy.

If we truly understand the needs we are trying to fulfil it is more likely that we will build a good product, it's a superficial understanding that tends to lead to products that are treating symptoms rather than causes and only minor improvements.

[paulie_a]

Open ended questions is how you understand their underlying needs.

"What are your pain points" and "so why is that an issue" can give you incredible insight just by listening. They should be doing 90 percent of the talking. honestly playing dumb is powerful.

Engineers tend to want to be right and give answers which make them terrible sales people.

[dagw]

The best way to do this is by asking good questions, and then listening carefully and taking notes

Even better is to watch people work. I've written software for domains where I'll never be an end user and knew very little about how the end users actually work. Talking to people and asking questions is of course nice, but nothing beats sitting behind an actual end user for 30 minutes and watching what they actually do.

[fulafel]

But did Docker succeed in sales? They were acquired to gain control of the user base, without making money. Serverless seems headed the same way.

You need to succeed in sales if you want to make sales, otherwise not :)

[ainar-g]

>"We are using [Insert Tech Name] and it doesn't support feature X"

>So the entrepreneurs would rush to it's keyboard create a clone of the Tech and add the feature X.

Uhm, why is this bad? Haven't we all seen examples of companies that do the same stuff as other companies but better and succeed? I'm pretty sure even pg wrote about this in one of his "How to start a start-up" essays.

[dagw]

Uhm, why is this bad?

There are two big problems. If someone has lived without X for long enough they've probably found workarounds for living without X so that just adding X might not be that valuable to them or at least it might be hard to convince them how valuable it is to have X. The second is you often greatly underestimate how much work it is to get to the point where you have a good enough clone to even have something to add X to. And while you're busy working on your clone the original company might get around to adding X and thus undermining your whole business.

Haven't we all seen examples of companies that do the same stuff as other companies but better and succeed?

Sure, but they're often better in a whole category of ways (price or speed or ease of use etc.) and not just a clone of an existing product with X added.

[SimplyUnknown]

There's nothing wrong with it. As you say, many quality products come from this kind of work.

However, you can read this article as saying: "The only way you can sell software is by listening to customers and building exactly what they want." Which often is "We are using [Insert Tech Name] and it doesn't support feature X."

This narrative is clearly false. Many good products are built and monetized by just building something what you think the world needs or you think is fun to build. Again, many more of these software projects have failed using this strategy. Many good products are built and monetized by listening to customers and building what they want. And again, many poor clones that add no value are built using this way.

It is a two-way street which is not reflected in the article.

[sonnyblarney]

">The best way to do this is by asking good questions, and then listening carefully and taking notes

Again I strongly disagree here. This pattern pushes entrepreneurs to create a version++ of something"

... --> not if you are actually listening!

Listening is not about 'let them tell us what feature they want' ... it's 'problem discovery'.

This is maybe the most valuable thing because young devs with 0 exposure to how operations actually work within a company will have their eyes opened wide.

This is where you can hone in on both real and perceived pain points, and develop the lingo that will work in messaging as you go to sell the 'learned' product you make ...

[tilt_error]

It all comes down to domain knowledge, I believe, where it is hard to provide good solutions without actually knowing anything about the type of problems being under scrutiny.

There are other types of generic problems, e.g. word processing, but those domains are often overpopulated with solutions where it is either hard to compete or hard to earn money.

The point you are making is that it is worthwhile to invest in understanding a problem domain well and the more specific it is, the more you have it for yourself :)

[sonnyblarney]

It's not just the problem domain though - there are issues that are very specific in the 'real world' that are not apparent to those even who understand the problem domain well, especially if it's a true B2B style product. Second, is understanding the mindset and uses cases of buyers. Tech people tend to way over-estimate the sophistication of users, and also underestimate how hard it often it is to do basic things.

I once worked for a huge high tech company in Product Marketing, we wanted to run this simple program to reach out to some users. Our problem? We had to host a few images and bits of content and we literally had nowhere to host them. Seriously. Just a few images. We had no production capability for that ... even working with the marketing ops teams ... they have complicated tools and content management systems unsuited to 'just hosting a file'.

We reached out to our customers (carriers like AT&T) so that maybe they could host. Same problem! We're talking business unites of major high tech corporations here unable to just host a file.

Want to use S3? Or whatever? Enter 'legal'. Make a request to the legal department, maybe get a response in a month. Maybe.

It was eerie and funny and sad ... but it was a real eye opener.

[neolefty]

Wow, no wonder Box is doing well — that's a main problem they solve. I didn't really understand its value without hearing your predicament.

[throwaway487548]

> They just had a vision about how X or Y technology should be , and just created something

And the money for covering expenses and living came from..?

> It's about having a vision.

I have the vision that crap like Hadoop should be rewritten in Go. Shall I dive in and start re-writing?

Where are all the crypto visionaries nowadays?