4 ms·

If you're building something with the goal of selling it, sell before you build. This applies in at least 99% of cases. Just go to potential customers and tell

If you're building something with the goal of selling it, sell before you build. This applies in at least 99% of cases. Just go to potential customers and tell them "hey, in [a few months/years], I'm going to launch a thing that can do this and that for you. Would you like one at prelaunch price?" If customers don't like your initial pitch and don't buy, why would you give up? Iterate on what you're selling. You don't need to build to iterate. Then you can build something people want. I like to phrase that as "as a software consultant, I'm in the business of not writing code. The first rule of this business is to never write code until somebody definitely wants to use it". Of course, if you're building it just for fun, iterate on the code all yu want before you sell it.

01acheru 4y ago
Your comment is the essence of why I totally hate software consultants. "Hi customer, after months of meetings and calls and briefings and checklists and ... here is my final 76 page presentation about an ideal not buildable extremely expensive software that if finished will look like Homer's car" Never had experiences different from the above, be it from big or small players.
- SonOfLilit 4y ago
  I have never delivered slides as my deliverable. I take projects where the deliverable is either running code written by me (when the code is really tricky to get right) or a product/feature launched by the team I'm supporting. There are consultancies in the CYOA business, and consultancies (or, usually, single consultants) in the delivery business. Both have high customer demand, for different reasons. Admittedly, the first kind usually make a lot more money, but I live nicely.
  - 01acheru 4y ago
    You sound much more a freelance developer or a single person development agency than a software consultant, I guess we simply describe those roles differently and don't assume the same thing when talking about "software consultancy". The thing you are describing sounds like the first phase of a project where you are gathering the requirements, in a one-to-one business relationship with a single customer. "Sell before you build" as far as I understand is usually used in a one-to-many scenario, where you start selling (or better, marketing) a product before building it.
    - SonOfLilit 4y ago
      As of today, I have an employee, so definitely not a one person agency anymore. And it's very rare that I'm engaged to write a complete system, because I'm quite expensive. However, from the way I approached the answer you can easily tell I'm a software person and not an MBA/salesman by birth. Usually I work with startup CTOs (which I was myself until half a year ago) to solve very complex business or technology problems or support the design and development of a complex project. For example, you might engage me to perform design reviews with your team, or to dive into the code of a system written in a language nobody in the company knows and add a complex feature that sends ripples across the codebase, or to design a critical system and then write the most complex module myself and stay involved enough in the development of the rest that I can ensure what the team delivers is what the organization actually needs. I really am a consultant, just a software consultant, not a "management consultant", like McKinsey or Deloitte. "Sell before you build" means before you waste resources building something, have expectant customers waiting for them to exist, with money already committed to buying it once it exists. There are many ways to structure this commercially. Of course you should sell one-to-many, not just one-to-one. Many times the first thing I tell a potential customer on a sales call is "wait, you want to build this before you have paying customers? Why take all this risk? Go out and sell it (or market it, if it's a B2C product) and then build it without the product-market-fit risk!" I then go into the many strategies that exist for selling things before they are built, as they apply to their specific industry and business. This can save my customers millions of dollars or years of their lives if they're at the first stages of a startup. This kind of thing is a major reason I can charge consulting rates and not freelancing rates, and is essential business advice that every serious entrepreneur either learned the easy way or the hard way.
      - 01acheru 4y ago
        We are converging :) I guess it is just a matter of terms, I would have never called what you just described as a "software consultancy" since you mentioned building, developing, code reviewing and such terms a lot of times. By talking to you I understand that the meaning I give to the word "consultancy" is not as universal as I have thought. For me consultants never dive into anything "practical", they limit themselves to aspects of the software that stay all around the actual development. From my point of view you I would call you an experienced freelance developer, or a development agency (congrats on growing BTW, going from 0 to 1 employee is a big step). Mind that developing is not simply coding, so IMHO you are still a developer even if you "stay involved enough in the development of the rest that I can ensure what the team delivers is what the organization actually needs". You happen to advice your customers about stuff not strictly related to the actual development process, and that would be a consultancy, but it doesn't sound from all your comments that this is your main focus so from my strictly personal point of view I wouldn't call you a consultant. Developer: code, output, stuff that works and implements some business logic. Consultant: advices, indications, expectations... and then it is up to someone else to make it work. (and they don't care if ever, how, when, why, who) Anyway don't take it personally, and by the way I didn't mean to be disrespectful towards you. Maybe my first comment was a little harsh, so I'm sorry if you felt it as an attack on your person or your professionalism :D
XCSme 4y ago
> 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".
- SonOfLilit 4y ago
  You don't have to trick them into buying. You can just convince them to buy, eyes open. > doesn't mean that you can actually deliver on that promise It's very rare that the big risk in a problem is technical feasibility. And you should definitely be, or partner with, someone who can tell the difference between a spec that can be built to a spec that has real technical risk, and only sell things that you can deliver. > The problem is that you don't know what people want. People don't know what they want Indeed, and the only real way to tell is to build it. But you can de-risk by selling a few first and then building, instead of just investing years of your life completely blindly. And there's no reason not to. It's very rare that a product idea can be sold once it's built but not before, and there are other, less risky, products you could build instead of that one.
  - XCSme 4y ago
    Kickstarter is filled with "fake" projects that are only selling an idea which is often impossible to implement. It's not only about being able to create that product but also matching the promised delivery times, R&D costs, manufacturing costs, etc.

01acheru 4y ago

Your comment is the essence of why I totally hate software consultants. "Hi customer, after months of meetings and calls and briefings and checklists and ... here is my final 76 page presentation about an ideal not buildable extremely expensive software that if finished will look like Homer's car" Never had experiences different from the above, be it from big or small players.

SonOfLilit 4y ago
I have never delivered slides as my deliverable. I take projects where the deliverable is either running code written by me (when the code is really tricky to get right) or a product/feature launched by the team I'm supporting. There are consultancies in the CYOA business, and consultancies (or, usually, single consultants) in the delivery business. Both have high customer demand, for different reasons. Admittedly, the first kind usually make a lot more money, but I live nicely.
- 01acheru 4y ago
  You sound much more a freelance developer or a single person development agency than a software consultant, I guess we simply describe those roles differently and don't assume the same thing when talking about "software consultancy". The thing you are describing sounds like the first phase of a project where you are gathering the requirements, in a one-to-one business relationship with a single customer. "Sell before you build" as far as I understand is usually used in a one-to-many scenario, where you start selling (or better, marketing) a product before building it.
  - SonOfLilit 4y ago
    As of today, I have an employee, so definitely not a one person agency anymore. And it's very rare that I'm engaged to write a complete system, because I'm quite expensive. However, from the way I approached the answer you can easily tell I'm a software person and not an MBA/salesman by birth. Usually I work with startup CTOs (which I was myself until half a year ago) to solve very complex business or technology problems or support the design and development of a complex project. For example, you might engage me to perform design reviews with your team, or to dive into the code of a system written in a language nobody in the company knows and add a complex feature that sends ripples across the codebase, or to design a critical system and then write the most complex module myself and stay involved enough in the development of the rest that I can ensure what the team delivers is what the organization actually needs. I really am a consultant, just a software consultant, not a "management consultant", like McKinsey or Deloitte. "Sell before you build" means before you waste resources building something, have expectant customers waiting for them to exist, with money already committed to buying it once it exists. There are many ways to structure this commercially. Of course you should sell one-to-many, not just one-to-one. Many times the first thing I tell a potential customer on a sales call is "wait, you want to build this before you have paying customers? Why take all this risk? Go out and sell it (or market it, if it's a B2C product) and then build it without the product-market-fit risk!" I then go into the many strategies that exist for selling things before they are built, as they apply to their specific industry and business. This can save my customers millions of dollars or years of their lives if they're at the first stages of a startup. This kind of thing is a major reason I can charge consulting rates and not freelancing rates, and is essential business advice that every serious entrepreneur either learned the easy way or the hard way.
    - 01acheru 4y ago
      We are converging :) I guess it is just a matter of terms, I would have never called what you just described as a "software consultancy" since you mentioned building, developing, code reviewing and such terms a lot of times. By talking to you I understand that the meaning I give to the word "consultancy" is not as universal as I have thought. For me consultants never dive into anything "practical", they limit themselves to aspects of the software that stay all around the actual development. From my point of view you I would call you an experienced freelance developer, or a development agency (congrats on growing BTW, going from 0 to 1 employee is a big step). Mind that developing is not simply coding, so IMHO you are still a developer even if you "stay involved enough in the development of the rest that I can ensure what the team delivers is what the organization actually needs". You happen to advice your customers about stuff not strictly related to the actual development process, and that would be a consultancy, but it doesn't sound from all your comments that this is your main focus so from my strictly personal point of view I wouldn't call you a consultant. Developer: code, output, stuff that works and implements some business logic. Consultant: advices, indications, expectations... and then it is up to someone else to make it work. (and they don't care if ever, how, when, why, who) Anyway don't take it personally, and by the way I didn't mean to be disrespectful towards you. Maybe my first comment was a little harsh, so I'm sorry if you felt it as an attack on your person or your professionalism :D

XCSme 4y ago

> 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".

SonOfLilit 4y ago
You don't have to trick them into buying. You can just convince them to buy, eyes open. > doesn't mean that you can actually deliver on that promise It's very rare that the big risk in a problem is technical feasibility. And you should definitely be, or partner with, someone who can tell the difference between a spec that can be built to a spec that has real technical risk, and only sell things that you can deliver. > The problem is that you don't know what people want. People don't know what they want Indeed, and the only real way to tell is to build it. But you can de-risk by selling a few first and then building, instead of just investing years of your life completely blindly. And there's no reason not to. It's very rare that a product idea can be sold once it's built but not before, and there are other, less risky, products you could build instead of that one.
- XCSme 4y ago
  Kickstarter is filled with "fake" projects that are only selling an idea which is often impossible to implement. It's not only about being able to create that product but also matching the promised delivery times, R&D costs, manufacturing costs, etc.