It's not irrational. People often don't know what they want, or think they know but often devise overly elaborate solutions. Also, building before asking means you can potentially create a new market with a new product that's never been seen before, which is far more lucrative.
Also, people are more able to communicate their wants and needs as deltas rather than absolutes. Creating something as a starting point is a great way to seed the conversation and get people thinking, even if that something doesn't end up getting used in the resulting product in any way.
Adding to that, there is an entertainment component to almost everything these days. People like Turbo Tax because it makes it easier, and a little bit closer to fun, to do your taxes.
Right, but, you'll tell a new customer you will have the product ready for them quickly, but because you didn't have a stakeholder that would, you're running the risk trying to sell them a product that wouldn't solve their particular problem (feature mismatch).
Maybe if you believe the limits of technology would be a blocker to solving your customer's vision of their problem, then a prototype before you have a stakeholder that would compensate you somehow is probably the right answer.
But I think you can easily confuse the business objectives with engineering objectives in making the assumption that the prototypical solution is representative of the customer's vision of the solution.
It's not that I think you or a business can't live with that dissonance, I think it may open you up to that problem.
I know what you mean. One of my previous projects was a homeschool tracking SaaS. Even at $5/month people were complaining about the price and I never got more than a dozen subscribers.
In the end I shut it down (while keeping an instance running on a home server for my own use) because it was barely breaking even and wasn't worth the headache.
I agree. Its most often the case that we arrive at problem to solve based on our own experiences/or troubles. A builders passion is fueled by his own problem and he can think of selling it if he see that the problem is present in life of others as well. Most successful products starts like this.
Trying to hunt for problem that others are facing won't is not at all motivating for a hacker mentality. And even if he is able to discover challenges of others he probably won't be able to execute the solution for it as neatly as he cad do for challenges of his own life.
Thanks for this comment. I think you articulated the thought process that this post aims to speak to beautifully. Builders do want to build, and finding an audience first and doing the type of tedious customer development work described in this post IS an impediment to building, which is precisely the point I wanted to make.
Assuming that the goal of building a product is to ultimately generate revenue, having a temporary impediment between conceptualizing a product idea and building the product is a good thing. This impediment allows for the builder to pause and objectively scrutinize his own idea, using feedback from potential customers as data about the extent to which the product hypothesis is correct.
You're right that stagnation is the worst outcome. And the inverse of stagnation is momentum, which will exist to the extent that people want what we're making for them, something that can be determined in advance of building simply by talking to potential users and customers.
I'll also add here that the process mentioned in this post in no way inhibits the type of creative and inspired thinking that developers use to envision game-changing products. It's quite the opposite - rigorous and merciless scrutiny of our own ideas is the distillation process that allows us to refine our ideas into their essence, then confidently build things with conviction, and be right.
So to summarize (for my own understanding)... It's fine to want to build something first. However, if you want it to be financially profitable in a big scope of impact, you have a higher chance by plotting it out and then executing, than accidentally stumbling upon a perfect business model for your completed product.
Yes, that is my opinion. And if it's possible to build something minimal that helps demo or describe the product to users, it's totally reasonable to build that thing quickly and take it to customers for feedback.
The pitfall to avoid is investing large amounts of time, energy, and money building products in a vacuum based on assumptions about what people want and will pay for. I've heard this referred to as committing "assume-icide."
> you have a higher chance by plotting it out and then executing, than accidentally stumbling upon a perfect business model for your completed product.
You have a higher chance of stumbling upon a perfect business model by speaking to the customers before / during product design.
On the contrary, doing it the other way ensures that when you’re done someone is willing to buy what you built. It’s not about what one customer wants defining what you build, but rather having commitment from a handful of customers that they would buy what you propose to build. There’s a huge gap between securing a commitment to buy a future product and announcing vaporware you have no intention or ability to ship.
This can be dangerous as well though. Most people aren't naturally adversarial and get uncomfortable pushing down paths where you don't know the answer or seem unprepared.
You often won't get someone to really challenge your assumptions unless they have some meaningful motivation. So you may have to listen in a different way than you're used to, or push people a bit to get them really comfortable with telling you things they might think you don't want to hear.
Couldn't have said it better. I am another one of those people here with the same experience.
Ironically, building because of being afraid that nothing will be built often leads to exactly that outcome: months or years spent on something that nobody ever uses. Now it's built, but it doesn't matter, which is essentially the same as if it had never been built. In my experience, this really often is a self-fulfilling prophecy. And it has a tendency to become a vicious circle when the fear becomes self-reinforcing.
I knew it was a small niche market, and I set it as really a "reasonable" goal.
"If 100 people in 30 days are interested with this ad spend, then I'll reach out engage them and build the thing."
Depending on your app/market, you can change that number accordingly, but I think 100 is just a great "feel good" number thats hard enough to hit as evidenced by my test.
I’d say even for some new CRUD app, assumptions that it will be easy to build are so, so common, and the reality of most “super simple CRUD apps” is that the implementation is way harder than you thought, and selling advanced features before you definitively know how to build them is a big source of failure for seemingly straightforward products.
It’s very much sales hubris to ever believe you know how to build something you’ve never built before, even in cases when it might seemlike a minor variation of something you built before.
I find presenting your experience can help a lot at local dev meetups and conferences. If you can find a venue for pitching your product, then great! But most of the time, people don't want to hear a product pitch. Instead, present ideas or work that is related with the goal of the community viewing you as an expert. Writing books or blogs can also help with this. And in your presentations, put your company's logo in the corner.
The nice thing is that presentations shine a spotlight on you, and then potential customers will come to you rather than you having to go to them. Eventually you will need to do the latter, but your first customers are likely to be people in the crowd watching your presentations or their friends. When you do start having to go find more customers, you will have a much better idea who to target as well and have at least a small network to utilize.
Nope, but a box of Jenga and some small stuffed toys would suffice ;)
(And actually, my brother and I played a paper version of Worms when we were kids - with the map drawn in pen, and our movements and attacks plotted in pencil - was fun)
While I think this is a great piece — especially the part about listening — and it's something we engineers all need to take to heart, I think its applicability varies depending on the nature of the product and the market.
If you're trying to serve a previously completely unmet need, as many startups are, then this advice is spot on and you should print it out and pin it to your wall. But there are different cases. Sometimes you're trying to bring an incremental advance to a well-established market. In that case there may well already be established marketing and distribution channels, and the value of your product may be readily evident to users of the existing ones. This is especially true in cases where the primary barriers to improvement are technological. To take an extreme example, people working on fusion power don't need to validate the market at all; when they finally build a working plant, they'll just have to plug it into the grid and get paid. Some of the things we build have this character, at least to some extent.
Another exception has to be made for truly visionary products. Sometimes, as Steve Jobs famously pointed out, people don't know they want something until they see it. The Macintosh might be the best example; computer users in 1983 were not generally thinking that they needed a GUI-based OS. This is a dangerous one, though, because we all want to think we're visionaries. If you're going to go down this path, do it with your eyes open, and realize your vision may be wrong — or, more frustratingly, right but too early (e.g. [0]).
I have to disagree with #1. The overwhelming response at this stage is a big FRIG OFF from the other end who in the past 10 years have steadily been receiving from various "disruptive" startups, who all read the same pile of garbage that is "The Lean Startup", who all preach the same fucked up assumption- that the rest of the world has access to the same socioeconomic environment, "The Country Club", friend of a CEO father who knows people, etc.
I feel that it's no longer a merit based but short term pump and dump in which private equity is traded but not without surrendering your control as the founder and that you are now on the dole on a community of investors that trade shares for pennies and have every legitimate reason to dump it to unsuspecting public market to reap profits.
Advices like #1, In 2018, honestly irrelevant, and increasingly sounding like the new telemarketer. For instance, I repeatedly get calls or emails from a variety of SaaS founders or other developers who started their product that I've grown to detune and avoid them.
The big marketing fields are prohibitively expensive so those with the pocket can bid up and essentially deny competitors access to the same consumers.
Trying to sell something that doesn't exist can be done, but not without compromises with unclear results. Why? The power dynamic is asymmetric due to the sheer capital and a hound of top tier lawyers ready to sink their teeth into your startup.
Meaning, they can even sign a memo or an agreement to express interest and then pull out. What the fuck are you gonna do, sue a Fortune 1000 company?
None of these problems seem unique to selling a product that isn't complete. You're right that selling is hard, but it's done every day in a repeatable way by tons of sales professionals.
Maybe the answer is to pre-sell a very simple product that you are certain you can build. Any half-decent engineer can build a CRUD app that consumes a spreadsheet and renders some graphs, for example. You can add all the theoretical magic that turns a good product into an amazing one after you build this basic MVP.
Fundamentally it's about risk.
If your startup is writing OCR that out competes tesseract or automatically diagnoses melanoma that has very different risks than building a B2B product to allow optometrists to manage their clients.
In general though I think most startup's have more go-to-market risk than technical risk. If you can out compete tesseract in OCR you're not going to fail because of market. And if you're Salesforce you're not go to fail because you can't build software to track leads. You're going to failed because you couldn't find enough users.
This is why investors spend so much more time looking at adoption rates, and so little time looking at the backing infrastructure.
When talking with customers, focus on the problem, not the solution. The problem: going from here to there takes too long. There are many solutions to that problem. Faster horses are one of them. Cars another. Telephone, flying cars yet another. Not going is also a solution. Etc.
Currently I'm in totally "guilty" of #1, but it feels fine and I don't care if it's not the best way to launch something. I want to sell t-shirts online. What kind of research do I need? It's a proven model, people buy t-shirts and other merch online, so the only thing I need is to build it, design it before selling. I just want to build a side project that pays the bills, not going after to outplace major players.
#2 is interesting, I will do this by first selling to friends and talking to them in person to collect enough feedback to do an iteration on the product. I do agree that listening is key.
#3 The ideal situation for you is to have as many signed, legally binding customer contracts as possible
Meh, this is for one specific type of business, there's tons of business models that this doesn't apply to. If the product can collect money from day one, then you won't have the problem of mistaking interest for demand. What's even better is to turn people who are just interested into your advocates.
If you are ordering the production of 1,000 shirts hoping that design will sell, you are guilty of #1.
If you are just designing it, putting on a website and will only actually manufacture the shirts you sell, then the solution to #1 is already built in your business model (assuming you are not spending 6 months of coding with your ecommerce website).
Why do you think my comments did not already account for that? The article claims that software engineers make the mistake of building before they sell, and advises an aggressive form of selling before building instead.
But that advice directly means to skip engineering due diligence (which very often requires building before you sell). It doesn’t matter if the person implementing the advice would be an engineer or a sales person or anyone else.
Your comment comes off as if it is supposed to glibly (and I think also rudely) undermine what I wrote, but in fact I think you didn’t understand what I wrote, and you seem to suggest that it would be impossible for an engineer (using the article’s advice) to fail to consult an engineering estimate of technical feasibility prior to selling something.
Having a high degree of confidence that you are capable of building what you are selling is a given.
Nobody reading this is building anything resembling a perpetual motion machine. Pretty much everyone in this post’s intended audience is building some combination of a database and a bunch of web forms and tables to undertake a routine business process.
Your comment is plain old reductio ad absurdum. It’s not clever.
Writers are entitled to favor conciseness over having to pre-empt any fallacious dismissal they’ll get from whichever random person on the internet needs to entertain themselves that day.
> “Having a high degree of confidence that you are capable of building what you are selling is a given.”
No, it is emphatically not a given. Not in the context of some new CRUD tool. Not in the context of latest & greatest self-driving cars. Absolutely not.
> “Pretty much everyone in this post’s intended audience is building some combination of a database and a bunch of web forms and tables to undertake a routine business process.”
You’re just simply extremely wrong about this. Even internally to a large company you often have projects spun up for face detection, natural language processing, complex workflow management tools, adtech tools, embedded systems, robotics, medical devices, systems dealing with personally identifying information, and on and on.
Expand to include start-ups and the breadth and scope of products being developed grows dramatically.
All the time, across all of these situations, you face engineers, product managers, sales people, and many others, who over-promise on product offerings during initial stage sales piloting. It happens all. the. time. And one of the most serious drivers of this huge and risky oversight is a lack of investment in building parts of the product in advance of attempting to sell it, in order to acquire knowledge that you did not already have regarding the cost and blockers of the engineering implementation.
That you dismiss this as implausible by saying “confidence that you are capable of building what you are selling is given” is nothing other than an indication you do not know what you’re talking about in this topic. I feel frustrated to receive such a rude comment that is self-evidently more focused on trying to undercut me, even mentioning wildly non sequitur things about concise writing as if it applied to the original article, than focused on the actual discussion of the thread.
Sure at a big company. But this advice is targeted to engineers who want to start their own company. Its unlikely they can even afford any of the layers of cruft you are talking about.
If this was advice for starting some new initiative at BigCorp I might agree with you.
The need to build before selling is more critical for start-ups or single person gigs or consulting, because in those situations you don’t have existing stable revenue streams to use to absorb financial or reputational losses that come from underestimating implementation time or cost and failing to deliver sales promises.
If it matters to build before selling in a mature company, it matters even more in a start-up / solo business / consulting feasibility discussion / etc.
It just doesn't invalidate the point the article is making.
Your point - which I'll paraphrase as don't sell something you can't build - is valid and important.
The article's point - which may be paraphrased as don't build something you can't sell - is also valid and important.
Neither is more important than the other; like basically everything in business there is a tradeoff, and the ones who succeed will be the ones who get the tradeoff right.
But the author makes their point because they see too many people over-optimising on the "build first" approach and failing, when they might have avoided failure if they'd done a bit more "sell first" - or, as the article actually says, "talk to potential customers to properly understand what they want first".
You're getting frustrated (indeed, coming across as enraged) and resorting to strawman and absurdist arguments because you're incorrectly seeing the article as making an absolutist point, and then responding to it with your own opposing absolutist point. If you just approach the topic with appropriate nuance you'll save yourself the need to be frustrated.
Edit: changing implied quotes to be clear they're paraphrased.
Why not use this time to "sell" us your function as a service platform? You keep saying its a function as a service platform, but I still have no idea what it is or why it would be useful. I think you're missing a perfect opportunity to tell us more and get feedback from your potential customers (considering the HN crowd is full of developers/managers).
My take is that the purpose is not to actually close a sale before building, but to make sure that you could actually close a sale.
The article makes the correct point that many people confuse "being sort of close to closing a sale" with actually closing a sale, and these people may waste time building a product that clients are only sort of interested in but aren't willing to actually pay for.
It's because sales, and in general any social activity, has inherently unpredictable and random results, while engineering is mostly deterministic.
Also, much easier to sell something that exists since obviously customers don't gain much by and thus don't care much about signalling whether they would buy something that they might be able to buy in the future, as opposed to just buying something they want and can get immediately.
67 comments
[ 3.0 ms ] story [ 115 ms ] threadThe whole thing wasn't built to become what it did. That's why you shouldn't build (too much) before starting to sell.
Maybe if you believe the limits of technology would be a blocker to solving your customer's vision of their problem, then a prototype before you have a stakeholder that would compensate you somehow is probably the right answer.
But I think you can easily confuse the business objectives with engineering objectives in making the assumption that the prototypical solution is representative of the customer's vision of the solution.
It's not that I think you or a business can't live with that dissonance, I think it may open you up to that problem.
But finding them is prohibitively costly.
I often will see the price of an API (cough Google maps) and roll my own solution.
But where the heck am I supposed to get all the data?
That’s exactly my point. Making a full replacement for an API (endpoint) is much more than writing some swagger.
In the end I shut it down (while keeping an instance running on a home server for my own use) because it was barely breaking even and wasn't worth the headache.
Trying to hunt for problem that others are facing won't is not at all motivating for a hacker mentality. And even if he is able to discover challenges of others he probably won't be able to execute the solution for it as neatly as he cad do for challenges of his own life.
Thanks for this comment. I think you articulated the thought process that this post aims to speak to beautifully. Builders do want to build, and finding an audience first and doing the type of tedious customer development work described in this post IS an impediment to building, which is precisely the point I wanted to make.
Assuming that the goal of building a product is to ultimately generate revenue, having a temporary impediment between conceptualizing a product idea and building the product is a good thing. This impediment allows for the builder to pause and objectively scrutinize his own idea, using feedback from potential customers as data about the extent to which the product hypothesis is correct.
You're right that stagnation is the worst outcome. And the inverse of stagnation is momentum, which will exist to the extent that people want what we're making for them, something that can be determined in advance of building simply by talking to potential users and customers.
I'll also add here that the process mentioned in this post in no way inhibits the type of creative and inspired thinking that developers use to envision game-changing products. It's quite the opposite - rigorous and merciless scrutiny of our own ideas is the distillation process that allows us to refine our ideas into their essence, then confidently build things with conviction, and be right.
The pitfall to avoid is investing large amounts of time, energy, and money building products in a vacuum based on assumptions about what people want and will pay for. I've heard this referred to as committing "assume-icide."
You have a higher chance of stumbling upon a perfect business model by speaking to the customers before / during product design.
You often won't get someone to really challenge your assumptions unless they have some meaningful motivation. So you may have to listen in a different way than you're used to, or push people a bit to get them really comfortable with telling you things they might think you don't want to hear.
Ironically, building because of being afraid that nothing will be built often leads to exactly that outcome: months or years spent on something that nobody ever uses. Now it's built, but it doesn't matter, which is essentially the same as if it had never been built. In my experience, this really often is a self-fulfilling prophecy. And it has a tendency to become a vicious circle when the fear becomes self-reinforcing.
"If 100 people in 30 days are interested with this ad spend, then I'll reach out engage them and build the thing."
Depending on your app/market, you can change that number accordingly, but I think 100 is just a great "feel good" number thats hard enough to hit as evidenced by my test.
One is highly possible and likely, the other is not. Most ideas will be somewhere in between.
It’s very much sales hubris to ever believe you know how to build something you’ve never built before, even in cases when it might seemlike a minor variation of something you built before.
The nice thing is that presentations shine a spotlight on you, and then potential customers will come to you rather than you having to go to them. Eventually you will need to do the latter, but your first customers are likely to be people in the crowd watching your presentations or their friends. When you do start having to go find more customers, you will have a much better idea who to target as well and have at least a small network to utilize.
http://www.pathsensitive.com/2015/10/the-prototype-stereotyp...
If you're trying to serve a previously completely unmet need, as many startups are, then this advice is spot on and you should print it out and pin it to your wall. But there are different cases. Sometimes you're trying to bring an incremental advance to a well-established market. In that case there may well already be established marketing and distribution channels, and the value of your product may be readily evident to users of the existing ones. This is especially true in cases where the primary barriers to improvement are technological. To take an extreme example, people working on fusion power don't need to validate the market at all; when they finally build a working plant, they'll just have to plug it into the grid and get paid. Some of the things we build have this character, at least to some extent.
Another exception has to be made for truly visionary products. Sometimes, as Steve Jobs famously pointed out, people don't know they want something until they see it. The Macintosh might be the best example; computer users in 1983 were not generally thinking that they needed a GUI-based OS. This is a dangerous one, though, because we all want to think we're visionaries. If you're going to go down this path, do it with your eyes open, and realize your vision may be wrong — or, more frustratingly, right but too early (e.g. [0]).
[0] https://en.wikipedia.org/wiki/VPL_Research
I feel that it's no longer a merit based but short term pump and dump in which private equity is traded but not without surrendering your control as the founder and that you are now on the dole on a community of investors that trade shares for pennies and have every legitimate reason to dump it to unsuspecting public market to reap profits.
Advices like #1, In 2018, honestly irrelevant, and increasingly sounding like the new telemarketer. For instance, I repeatedly get calls or emails from a variety of SaaS founders or other developers who started their product that I've grown to detune and avoid them.
The big marketing fields are prohibitively expensive so those with the pocket can bid up and essentially deny competitors access to the same consumers.
Trying to sell something that doesn't exist can be done, but not without compromises with unclear results. Why? The power dynamic is asymmetric due to the sheer capital and a hound of top tier lawyers ready to sink their teeth into your startup.
Meaning, they can even sign a memo or an agreement to express interest and then pull out. What the fuck are you gonna do, sue a Fortune 1000 company?
In general though I think most startup's have more go-to-market risk than technical risk. If you can out compete tesseract in OCR you're not going to fail because of market. And if you're Salesforce you're not go to fail because you can't build software to track leads. You're going to failed because you couldn't find enough users.
This is why investors spend so much more time looking at adoption rates, and so little time looking at the backing infrastructure.
#2 is interesting, I will do this by first selling to friends and talking to them in person to collect enough feedback to do an iteration on the product. I do agree that listening is key.
#3 The ideal situation for you is to have as many signed, legally binding customer contracts as possible
Meh, this is for one specific type of business, there's tons of business models that this doesn't apply to. If the product can collect money from day one, then you won't have the problem of mistaking interest for demand. What's even better is to turn people who are just interested into your advocates.
If you are just designing it, putting on a website and will only actually manufacture the shirts you sell, then the solution to #1 is already built in your business model (assuming you are not spending 6 months of coding with your ecommerce website).
But that advice directly means to skip engineering due diligence (which very often requires building before you sell). It doesn’t matter if the person implementing the advice would be an engineer or a sales person or anyone else.
Your comment comes off as if it is supposed to glibly (and I think also rudely) undermine what I wrote, but in fact I think you didn’t understand what I wrote, and you seem to suggest that it would be impossible for an engineer (using the article’s advice) to fail to consult an engineering estimate of technical feasibility prior to selling something.
Nobody reading this is building anything resembling a perpetual motion machine. Pretty much everyone in this post’s intended audience is building some combination of a database and a bunch of web forms and tables to undertake a routine business process.
Your comment is plain old reductio ad absurdum. It’s not clever.
Writers are entitled to favor conciseness over having to pre-empt any fallacious dismissal they’ll get from whichever random person on the internet needs to entertain themselves that day.
No, it is emphatically not a given. Not in the context of some new CRUD tool. Not in the context of latest & greatest self-driving cars. Absolutely not.
> “Pretty much everyone in this post’s intended audience is building some combination of a database and a bunch of web forms and tables to undertake a routine business process.”
You’re just simply extremely wrong about this. Even internally to a large company you often have projects spun up for face detection, natural language processing, complex workflow management tools, adtech tools, embedded systems, robotics, medical devices, systems dealing with personally identifying information, and on and on.
Expand to include start-ups and the breadth and scope of products being developed grows dramatically.
All the time, across all of these situations, you face engineers, product managers, sales people, and many others, who over-promise on product offerings during initial stage sales piloting. It happens all. the. time. And one of the most serious drivers of this huge and risky oversight is a lack of investment in building parts of the product in advance of attempting to sell it, in order to acquire knowledge that you did not already have regarding the cost and blockers of the engineering implementation.
That you dismiss this as implausible by saying “confidence that you are capable of building what you are selling is given” is nothing other than an indication you do not know what you’re talking about in this topic. I feel frustrated to receive such a rude comment that is self-evidently more focused on trying to undercut me, even mentioning wildly non sequitur things about concise writing as if it applied to the original article, than focused on the actual discussion of the thread.
If this was advice for starting some new initiative at BigCorp I might agree with you.
If it matters to build before selling in a mature company, it matters even more in a start-up / solo business / consulting feasibility discussion / etc.
It just doesn't invalidate the point the article is making.
Your point - which I'll paraphrase as don't sell something you can't build - is valid and important.
The article's point - which may be paraphrased as don't build something you can't sell - is also valid and important.
Neither is more important than the other; like basically everything in business there is a tradeoff, and the ones who succeed will be the ones who get the tradeoff right.
But the author makes their point because they see too many people over-optimising on the "build first" approach and failing, when they might have avoided failure if they'd done a bit more "sell first" - or, as the article actually says, "talk to potential customers to properly understand what they want first".
You're getting frustrated (indeed, coming across as enraged) and resorting to strawman and absurdist arguments because you're incorrectly seeing the article as making an absolutist point, and then responding to it with your own opposing absolutist point. If you just approach the topic with appropriate nuance you'll save yourself the need to be frustrated.
Edit: changing implied quotes to be clear they're paraphrased.
The article makes the correct point that many people confuse "being sort of close to closing a sale" with actually closing a sale, and these people may waste time building a product that clients are only sort of interested in but aren't willing to actually pay for.
Also, much easier to sell something that exists since obviously customers don't gain much by and thus don't care much about signalling whether they would buy something that they might be able to buy in the future, as opposed to just buying something they want and can get immediately.