Even if they say so - building something is fun - I get my ideas into code I decide.
When customers start paying it stops being fun and people start having demands/deadlines/requests/issues.
Once you start rolling with project that is used by others it opens can of worms that is support.
I have wet dreams about building "Super Trubo Combo Tool - that solves everything ^TM", next moment I recall all the support calls and emails my boss is getting I don't want any of that.
It is the same with people who want to "learn programming", they could get a nice job and nice salary for that so they always say to me they would like to learn, but when they just think about sitting in front of computer for 12 hours reading documentation - well they just bail out instantly or after first 10 mins when something is not working as they wanted.
I'm currently writing a post about being a monasteric code machine where I have a project I love but don't want to market or sell it... yet.
Instead, im going to bring decades of side projects together into one platform and then just try to use it to build a few businesses. Nothing major, but i want it to be a platform to play with.
A lot of this article sounds less about selling, and more about selling out. It doesn't teach you how to sell an existing idea/product that you already have, it tells you to "abandon the hope of finding the next billion dollar idea inside your head, and instead look for it out there, in the heads of other people".
I don't want to scour the markets trying to find an opening, and then put in years of effort only to realize that I don't care about any of it. I'd rather build a product that I care about from the beginning.
Totally get it. But, the issue is that to sell something it has to solve a problem for someone else. Generally the choices are:
a. Build something that solves your personal problem - later find out if that applies to others, and whether they are willing to exchange money in return for a solution.
b. Find out what problem others have (ask them if they'd pay for a solution) - then build something that solves it responding to their feedback (if it does, ask for the money they said they'd give for a solution).
Maybe another way of looking at it is that (a) is about saying what "your vision is", and (b) is about finding out what "someone else's vision is".
Following (b) is a better commercial/sales strategy, but you're right that it might involve building something that you don't care about - because it's not for you, it's for the customers - which is probably why it's work and we do it for monetary compensation rather than just joy.
Perhaps the most difficult outcome is that many Founders now read product books or go to accelerators where they're told to follow strategy (b). They then basically do (a), while pretending they're doing (b) - but really all they do is listen to people who are positive about their vision and ignore any counter evidence.
You're right, that's what the article is about, because that's easier. Finding paying customers and product market fit for an existing product is harder, and that's what I teach at growthlab.so.
Open source exisystem is an interesting counter answer, where we dont tey to build sandcastles, big complete things, but often just try to build libraries, protocols, standards that others can expand upon & grow.
This post talks about failing to find the right target. But ratger than sales first, building things & getting to assess their value, getting direct peer feedback, allows an unconjoined exploration of utility/value.
Actually I think open source supports the author's point. Lots of open source projects are cool. Not very many make money. In fact sitting here I can't even think of one. Okay, Red Hat made money for a while.
This superficial judgementality ignores the whole point that most of the computing on the planet is powered by open source. Look at github stars or npm popularity: devs sell all the time. To other devs. In an arena of ideas, competing against each other, vying for usefulness. That money is somewhat orthogonal is part of why so many of these ideas spread so widely, are able to power so so so many commercial enterprises.
The exchange is also somewhat more intellectually honest- maybe not totally egalitarian peership, but more on the level of even & honest exchange, rather than dumbing down a complex situation idea & gussying it up as product, as salvation. Which this article pitches as the nee-plus-ultra.
The truth is inbetween. But the article totally stomps over truthfulness & intellect & engagement in favor of it's own preferred idea of selling.
That's conflating a licensing choice with a business goal. Slapping an open source license on code isn't a business model. Licensing choices do inform what kind of business model the author of the code is going to follow.
The main difference between open / closed source is that the IP is or isn't sold for a licensing fee itself. If the latter is true, you need an alternate business model. One alternative is selling something tangential to your project: typically expertise in installing, operating, maintaining the code. Consultancy. Another alternative is leveraging open source software to sell a service: hosting, CRM, managed services, social media, etc. etc.
All of a sudden, open source becomes very profitable.
The way I like to evaluate advice like this is by taking a selection of successful businesses/founders I know and applying the advice to those cases.
For example, I know of one company that very successfully gamed Google search to drive massive traffic to low value pages but pages that give a tiny bit of value to consumers looking to buy a house. Enough to drive ad income to live off very very comfortably.
You see, that business success has little to do with the novelty of the solution (does this exist already?) or deep insights into the customer needs (what do customers really want?). It’s mostly clever exploitation of specific market conditions (cheap to build websites, Google ranks your site for free, lots of people in need of housing, easy to sell ads to many different companies through an intermediary).
I almost feel like the article pushes this idealized view of how to build a successful company that is actually rarely the right recipe to success in practice.
What I don't like about it: The price! A bit steep (IMHO) if someone doesn't have the money... although I do understand that everything in business has to be appropriately charged for...
What I do like about it: Everything else!
Because I've had the exact same problem that the author writes about -- so I know a market exists for solutions, such as his, to this problem!
Plus the bonus fact that unlike Accelerators, Angel Investors or VC's -- no percentage of ownership is apparently taken in the participant's company!
Which is nice!
Anyway, great idea, and wishing the author a lot of luck with this business endeavor!
The article isn't very good but it does raise an interesting question.
What happens when your prospective customers say they would buy your solution if it was available, so you build it, but it turns out there is a big gap between saying they want it and actually buying it.
I see this happen a lot. This is why its probably better to ask for a deposit when somebody says they want your unbuilt product. You will get a much more honest answer.
I also took some sales coaching, it helped me a lot.
The article is more about finding a market fit for entrepreneurs than really about selling. To me, it reads more like why developers can’t do marketing well than why developers can’t sell but that wouldn’t be as good of a title that’s true.
I kind of feel personally offended by the title because I stated my career as a software engineer, moved to management consulting and now mostly do business development but then again I hated being a developer so maybe he has a point.
Even if they say so - building something is fun - I get my ideas into code I decide.
When customers start paying it stops being fun and people start having demands/deadlines/requests/issues.
Once you start rolling with project that is used by others it opens can of worms that is support.
I have wet dreams about building "Super Trubo Combo Tool - that solves everything ^TM", next moment I recall all the support calls and emails my boss is getting I don't want any of that.
It is the same with people who want to "learn programming", they could get a nice job and nice salary for that so they always say to me they would like to learn, but when they just think about sitting in front of computer for 12 hours reading documentation - well they just bail out instantly or after first 10 mins when something is not working as they wanted.