12 ms·

Web developer's love of programming is what wins them (potentially) fantastic salaries in regular work; it's also what cripples their attempts to diversify thei

Web developer's love of programming is what wins them (potentially) fantastic salaries in regular work; it's also what cripples their attempts to diversify their income. Time and time again, I see programmer friends investing 6+ months of their time getting an "MVP" out the door. Instead they should be applying their problem-solving skills to figuring out how to test their market hypothesis an order of magnitude more quickly. For my business, that meant a plain HTML website — no JS, no backend — and a PayPal button. (If you care to hear the full story, I have a video and transcript here: https://www.semicolonandsons.com/episode/MVP-&-Origin-Story https://www.semicolonandsons.com/episode/MVP-&-Origin-Story)

halfmatthalfcat 6y ago
I’ve heard this a couple times but it still makes no sense to me. How do you test your product hypothesis without a product? You’re essentially testing the viability of an idea with what you’re proposing, which is vastly different than having an actual product with features that you can iterate on when given feedback. I think for very niche categories, a landing page might be the only thing you need but I honestly believe that if you’re pitching a product with features, people want to see that product, not a page with text.
- KarimDaghari 6y ago
  Not GP, but here's my 2c: > How do you test your product hypothesis without a product? You can't. Actually... it depends on how you define a product. The way I think of it is: a product is merely a vehicle for the added value. With that understanding it becomes easier to decouple the value from the actual product. Therefore the MVP is no longer a stripped down version of the product but rather the simplest tool you can build to provide [that] value.
- fuball63 6y ago
  This is right up there with the "to gain users, build a product that users like by talking to users" paradox.
  - scollet 6y ago
    It seems strange to me that you would build without already having a problem to solve.
- rfrey 6y ago
  I believe you are entirely correct: it is testing an idea rather than testing and iterating on features. That's the point: people who love programming might skip directly to testing features without testing the idea. Testing the idea is essential and can be done 10x faster and cheaper than testing the first feature.
  - AlchemistCamp 6y ago
    Okay, let's take Roblox as an example since they're about to IPO. They've clearly made an incredible product and built a developer ecosystem around it. When they were starting several years ago, how would have tested "the idea"?
    - cinntaile 6y ago
      That's just survivorship bias though. A lot more ready-coded ideas fail which means a lot more wasted time (if making money is the point). I agree that not all ideas can be tested that way, some ideas just have to be experienced. For the ones that can be tested in their idea phase, it seems like a good way to prevent doing too much when the interest just isn't there. At the same time you'll probably miss out on some ideas that need a bit of a runway first, but you're minimizing for downside risk instead of maximizing for upside potential.
      - AlchemistCamp 6y ago
        How is my question survivorship bias? Other than the sense that any question asked is one of a multitude of candidate questions that "survived" the decision process and made it out into the world, I don't see how asking how a company's "idea" may have been tested is survivorship bias.
        cinntaile 6y ago
        You are right, that sentence and the one after that are irrelevant. My mistake!
- andi999 6y ago
  I think I read about it in Eric Ries 'Lean Startup' or so. He narrated his experience of building a product, making a signup page for that product. Nobody pressed the sign-up button. In this case the signup page with the button (and then transfering to 'get notified when it is ready') would have been enough.
- WJW 6y ago
  I mean, you just make up features and ask customers if they want them before writing a line of code. Check out https://buffer.com/resources/idea-to-paying-customers-in-7-weeks-how-we-did-it/ https://buffer.com/resources/idea-to-paying-customers-in-7-w... from buffer.com for an example. It was literally the landing and pricing pages first, functionality came a few weeks later and only after people were clicking on the (non-functional) pricing plans because they wanted to buy the product.
  - halfmatthalfcat 6y ago
    How do you translate product efficacy by an anonymous person clicking a buy link on a pricing page? All you are doing is gauging this ephemeral, uninformed click which has no direct correlation to what the product will actually _do_. It seems more of a crap shoot to gauge interest off of random clicks on a buy page versus having an actual product with actual user feedback that is actionable.
    - WJW 6y ago
      Well, obviously. But there is more to it than just those two in isolation. First off, one anonymous person clicking a link is just noise. But if you have hundreds clicking a link per day that gives you a much better indication you might be onto something. Further, how much time do you spend on making a basic landing and pricing page? Two hours? Four maybe? The original comment was talking about programmers working for 6+ months on a MVP product before showing it to people. You could launch hundreds of landing pages in that time, only limited by how many ideas you have. Even though the chance of a "hit" per landing page is probably lower, the sheer volume can more than make up for it. The landing plus pricing page model also immediately informs you how much people are actually willing to spend on it, which (if higher than zero) is a much higher indicator for product success than "I think this is a super cool feature". Finally, I notice that you are talking about "product efficacy" while the original comment is interested in making money. The two are related but not the same, since there are tons of crappy products making a boatload of profit (comcast anyone?) and also tons of great products that struggle to make money (see the ongoing troubles of open source developers on this very forum). Either goal is fine, but optimizing for one while thinking you are then also optimizing for the other is a recipe for disappointment.
- schwartzworld 6y ago
  I did a little focus group work years ago. Companies pay people to listen to a pitch or watch a demo and give them feedback.
- PragmaticPulp 6y ago
  It's a false dichotomy. In the real world you can't fully test your product hypothesis before building anything, but you also can't build a complete product before testing the market. Instead, it needs to be an iterative process. Build a little bit of product, tease it to the market, gauge interest, engage with customers, adjust trajectory as necessary, and continue to iterate. Testing your business hypthesis before building anything is prone to generating false signal. Some times your customers don't realize they need what you're building until they see it and use it. Many times your customers will praise an idea, right up until you ask them to use it or pay for it. A good example might be the recruiting company started by a famous HN commenter around 2015 that tried to use programming games as a recruiting filter. The idea received huge amounts of praise on HN and large numbers of waiting list signups before they released anything. The demand and hypothesis appeared to be validated. Then they switched to the other extreme, building enormously complex systems for years without actually selling anything to their customers. Eventually they shut down because they realized the market didn't actually want what they were building. The initial signal was misleading, but going heads-down to build a product according to the initial signal was also misleading. A better approach would have been to start recruiting up front and slowly iterate on improving it with programming games, rather than going off in the weeds to build a product that no one actually wanted.
  - mushbino 6y ago
    This is not true. There are many many mockup tools that you can use to test without building anything. It's a good way to separate the technology decisions from the business decisions.
    - PragmaticPulp 6y ago
      Mockups are part of the iterative process. Building a mockup to test is part of what I was describing. The point is that you can't simply make a mockup, assume it proves your hypothesis, and then go heads-down building the exact product shown in the mockups for 6-24 months and expect great results. Instead, you need to iterate both the mockups and the product in parallel, engaging with the market along the way. As in the example I provided, sometimes customers will claim to love your mockups but then decline to pay for the product when it arrives. It's one of the first things every product manager learns in the real world. > It's a good way to separate the technology decisions from the business decisions. Trying to separate technology from the business decisions is a mistake. At the start of the process, you need technology, product, sales, and business to be tightly intertwined. Dividing the labor and sending different roles in different directions is a mistake at an early stage company. You need to get everyone working together to iterate over and over again.
- gamerDude 6y ago
  At the end of the road, you still have to make a landing page showcasing what your product does, what problem it solves and why people should sign up. Usually that landing page doesn't actually have any features, just shows people what features they will get. So build the landing page first. Showcase the features you are going to build and see if you can get people to sign up.
vmception 6y ago
Exactly! Single page websites with a call to action! Its always entertaining getting some 23 year old programmer on later after the project has made some traction, and they are like “noooo this code is so bad, what, jquery!? An old version of jquery at that!?” because I’ve been copying my same landing page template for 8 years. it is so just like the meme because I’m like “haha money printer go brrr” translation: I just made a million dollars who gives af. turn your ideas into money, it has nothing to do with the stack you used, whatever level of discipline you’ve honed or anything.
- andi999 6y ago
  How much tax did you have to pay on that?
  - vmception 6y ago
    In US the highest combination is around 55%, you have to reduce it from 55% to 0% Typical strategies are using leverage - borrowing - and spending on more business growth stuff. You deduct more than you earned and also deduct the interest payments. The mere use of a business entity gets you a 20% tax deduction up to $120,000 (unincorporated sole proprietors can get this too, just easier to challenge and audit to fail) and then you can pump another $57,000 into a solo 401k. An S-Corp designation can somewhat mitigate the self employment taxes. You can also try paying people in shares/membership interests, parts of specific revenue streams or other noncash things (like free access to your service), so that you can keep your cash position while still making tax deductions. Just dont run for office, or do, I dont care. Tax code is very understandable to me, it is just a reading comprehension issue.
- jiofih 6y ago
  What field are your products in?
  - vmception 6y ago
    SaaS
mushbino 6y ago
Or make a prototype in Figma and use that to validate the hypothesis. Significantly less time and commitment.
- buzzerbetrayed 6y ago
  Figma is no faster than HTML/CSS to make a simple landing page for a lot of devs. Not because they are slow at Figma, but because they are fast at HTML/CSS.
  - monoideism 6y ago
    A landing page != a prototype.
    - smnplk 6y ago
      A landing page ~= a prototype.
      - monoideism 6y ago
        Are you advocating for that alternative syntax for "not equals to", or did you have some other point?
        oneoffcoder 6y ago
        That means almost/approximately equal to.
        monoideism 6y ago
        It also means “not equal to” in at least one common programming language: https://www.lua.org/pil/3.2.html https://www.lua.org/pil/3.2.html And usually, “approximately equal to” is expressed in this way: “n = ~3”. Which is why I asked. If that is what they meant, then I strongly disagree. A landing page is nowhere near a prototype. A landing page could be an advertisement for a prototype, but not a prototype.

halfmatthalfcat 6y ago

I’ve heard this a couple times but it still makes no sense to me. How do you test your product hypothesis without a product? You’re essentially testing the viability of an idea with what you’re proposing, which is vastly different than having an actual product with features that you can iterate on when given feedback. I think for very niche categories, a landing page might be the only thing you need but I honestly believe that if you’re pitching a product with features, people want to see that product, not a page with text.

KarimDaghari 6y ago
Not GP, but here's my 2c: > How do you test your product hypothesis without a product? You can't. Actually... it depends on how you define a product. The way I think of it is: a product is merely a vehicle for the added value. With that understanding it becomes easier to decouple the value from the actual product. Therefore the MVP is no longer a stripped down version of the product but rather the simplest tool you can build to provide [that] value.
fuball63 6y ago
This is right up there with the "to gain users, build a product that users like by talking to users" paradox.
- scollet 6y ago
  It seems strange to me that you would build without already having a problem to solve.
rfrey 6y ago
I believe you are entirely correct: it is testing an idea rather than testing and iterating on features. That's the point: people who love programming might skip directly to testing features without testing the idea. Testing the idea is essential and can be done 10x faster and cheaper than testing the first feature.
- AlchemistCamp 6y ago
  Okay, let's take Roblox as an example since they're about to IPO. They've clearly made an incredible product and built a developer ecosystem around it. When they were starting several years ago, how would have tested "the idea"?
  - cinntaile 6y ago
    That's just survivorship bias though. A lot more ready-coded ideas fail which means a lot more wasted time (if making money is the point). I agree that not all ideas can be tested that way, some ideas just have to be experienced. For the ones that can be tested in their idea phase, it seems like a good way to prevent doing too much when the interest just isn't there. At the same time you'll probably miss out on some ideas that need a bit of a runway first, but you're minimizing for downside risk instead of maximizing for upside potential.
    - AlchemistCamp 6y ago
      How is my question survivorship bias? Other than the sense that any question asked is one of a multitude of candidate questions that "survived" the decision process and made it out into the world, I don't see how asking how a company's "idea" may have been tested is survivorship bias.
      - cinntaile 6y ago
        You are right, that sentence and the one after that are irrelevant. My mistake!
andi999 6y ago
I think I read about it in Eric Ries 'Lean Startup' or so. He narrated his experience of building a product, making a signup page for that product. Nobody pressed the sign-up button. In this case the signup page with the button (and then transfering to 'get notified when it is ready') would have been enough.
WJW 6y ago
I mean, you just make up features and ask customers if they want them before writing a line of code. Check out https://buffer.com/resources/idea-to-paying-customers-in-7-weeks-how-we-did-it/ https://buffer.com/resources/idea-to-paying-customers-in-7-w... from buffer.com for an example. It was literally the landing and pricing pages first, functionality came a few weeks later and only after people were clicking on the (non-functional) pricing plans because they wanted to buy the product.
- halfmatthalfcat 6y ago
  How do you translate product efficacy by an anonymous person clicking a buy link on a pricing page? All you are doing is gauging this ephemeral, uninformed click which has no direct correlation to what the product will actually _do_. It seems more of a crap shoot to gauge interest off of random clicks on a buy page versus having an actual product with actual user feedback that is actionable.
  - WJW 6y ago
    Well, obviously. But there is more to it than just those two in isolation. First off, one anonymous person clicking a link is just noise. But if you have hundreds clicking a link per day that gives you a much better indication you might be onto something. Further, how much time do you spend on making a basic landing and pricing page? Two hours? Four maybe? The original comment was talking about programmers working for 6+ months on a MVP product before showing it to people. You could launch hundreds of landing pages in that time, only limited by how many ideas you have. Even though the chance of a "hit" per landing page is probably lower, the sheer volume can more than make up for it. The landing plus pricing page model also immediately informs you how much people are actually willing to spend on it, which (if higher than zero) is a much higher indicator for product success than "I think this is a super cool feature". Finally, I notice that you are talking about "product efficacy" while the original comment is interested in making money. The two are related but not the same, since there are tons of crappy products making a boatload of profit (comcast anyone?) and also tons of great products that struggle to make money (see the ongoing troubles of open source developers on this very forum). Either goal is fine, but optimizing for one while thinking you are then also optimizing for the other is a recipe for disappointment.
schwartzworld 6y ago
I did a little focus group work years ago. Companies pay people to listen to a pitch or watch a demo and give them feedback.
PragmaticPulp 6y ago
It's a false dichotomy. In the real world you can't fully test your product hypothesis before building anything, but you also can't build a complete product before testing the market. Instead, it needs to be an iterative process. Build a little bit of product, tease it to the market, gauge interest, engage with customers, adjust trajectory as necessary, and continue to iterate. Testing your business hypthesis before building anything is prone to generating false signal. Some times your customers don't realize they need what you're building until they see it and use it. Many times your customers will praise an idea, right up until you ask them to use it or pay for it. A good example might be the recruiting company started by a famous HN commenter around 2015 that tried to use programming games as a recruiting filter. The idea received huge amounts of praise on HN and large numbers of waiting list signups before they released anything. The demand and hypothesis appeared to be validated. Then they switched to the other extreme, building enormously complex systems for years without actually selling anything to their customers. Eventually they shut down because they realized the market didn't actually want what they were building. The initial signal was misleading, but going heads-down to build a product according to the initial signal was also misleading. A better approach would have been to start recruiting up front and slowly iterate on improving it with programming games, rather than going off in the weeds to build a product that no one actually wanted.
- mushbino 6y ago
  This is not true. There are many many mockup tools that you can use to test without building anything. It's a good way to separate the technology decisions from the business decisions.
  - PragmaticPulp 6y ago
    Mockups are part of the iterative process. Building a mockup to test is part of what I was describing. The point is that you can't simply make a mockup, assume it proves your hypothesis, and then go heads-down building the exact product shown in the mockups for 6-24 months and expect great results. Instead, you need to iterate both the mockups and the product in parallel, engaging with the market along the way. As in the example I provided, sometimes customers will claim to love your mockups but then decline to pay for the product when it arrives. It's one of the first things every product manager learns in the real world. > It's a good way to separate the technology decisions from the business decisions. Trying to separate technology from the business decisions is a mistake. At the start of the process, you need technology, product, sales, and business to be tightly intertwined. Dividing the labor and sending different roles in different directions is a mistake at an early stage company. You need to get everyone working together to iterate over and over again.
gamerDude 6y ago
At the end of the road, you still have to make a landing page showcasing what your product does, what problem it solves and why people should sign up. Usually that landing page doesn't actually have any features, just shows people what features they will get. So build the landing page first. Showcase the features you are going to build and see if you can get people to sign up.

vmception 6y ago

Exactly! Single page websites with a call to action! Its always entertaining getting some 23 year old programmer on later after the project has made some traction, and they are like “noooo this code is so bad, what, jquery!? An old version of jquery at that!?” because I’ve been copying my same landing page template for 8 years. it is so just like the meme because I’m like “haha money printer go brrr” translation: I just made a million dollars who gives af. turn your ideas into money, it has nothing to do with the stack you used, whatever level of discipline you’ve honed or anything.

andi999 6y ago
How much tax did you have to pay on that?
- vmception 6y ago
  In US the highest combination is around 55%, you have to reduce it from 55% to 0% Typical strategies are using leverage - borrowing - and spending on more business growth stuff. You deduct more than you earned and also deduct the interest payments. The mere use of a business entity gets you a 20% tax deduction up to $120,000 (unincorporated sole proprietors can get this too, just easier to challenge and audit to fail) and then you can pump another $57,000 into a solo 401k. An S-Corp designation can somewhat mitigate the self employment taxes. You can also try paying people in shares/membership interests, parts of specific revenue streams or other noncash things (like free access to your service), so that you can keep your cash position while still making tax deductions. Just dont run for office, or do, I dont care. Tax code is very understandable to me, it is just a reading comprehension issue.
jiofih 6y ago
What field are your products in?
- vmception 6y ago
  SaaS

mushbino 6y ago

Or make a prototype in Figma and use that to validate the hypothesis. Significantly less time and commitment.

buzzerbetrayed 6y ago
Figma is no faster than HTML/CSS to make a simple landing page for a lot of devs. Not because they are slow at Figma, but because they are fast at HTML/CSS.
- monoideism 6y ago
  A landing page != a prototype.
  - smnplk 6y ago
    A landing page ~= a prototype.
    - monoideism 6y ago
      Are you advocating for that alternative syntax for "not equals to", or did you have some other point?
      - oneoffcoder 6y ago
        That means almost/approximately equal to.
        monoideism 6y ago
        It also means “not equal to” in at least one common programming language: https://www.lua.org/pil/3.2.html https://www.lua.org/pil/3.2.html And usually, “approximately equal to” is expressed in this way: “n = ~3”. Which is why I asked. If that is what they meant, then I strongly disagree. A landing page is nowhere near a prototype. A landing page could be an advertisement for a prototype, but not a prototype.