4 ms·

As developers we often assume ”build it and they will come”. Or that marketing or sales is something that is bolted on afterwards. What we forget is that market

As developers we often assume ”build it and they will come”. Or that marketing or sales is something that is bolted on afterwards. What we forget is that marketing is a full time job that requires a full set of skills, experience and intuitions to do well. If you build something for 6 months and THEN start the marketing, its like starting from scratch all over again. You have zero experience to work from or iterate on and havent built any of the foundation. It’s like waiting to build the backend until the frontend is 100% complete. While building assumptions change based on things you learn. Marketing for your product works the same way. By putting the effort into marketing (meaning any form of reaching out: blog posts, direct sales, social media or even paid) you might even avoiding building features that nobody wanted anyway.

jakequade 7y ago
I think you're both giving marketing too much credit in the product's creation, and inverting the creation process in general. > It’s like waiting to build the backend until the frontend is 100% complete It's more like building a backend, then realising that the data structures could be improved when you're building the front. Marketing at best provides enhancements, not core changes (unless your product itself was incorrect to begin with). Honestly, if your marketing affects your product as much as you're suggesting, you have a pretty unstable product.
- rapphil 7y ago
  But marketing can help the dev team focus on the core functionalities that the customer really want.
  - watwut 7y ago
    No, marketing as driver will cause massive feature creep.
    - speedplane 7y ago
      > No, marketing as driver will cause massive feature creep. Marketing is about exposing your product to your target customers. It's relatively orthogonal to product features.
- erikrothoff 7y ago
  I disagree. Marketing gets people in. Users guide product development and thus the product. If an ”unstable product” is one that users actually want to use, then I guess an unstable product is a good thing?
  - watwut 7y ago
    Treating marketing as requirements gathering gets you overly complicated internally inconsistent requirements. The instability is side product. Marketing is not making trade-off between bugs and features, they are unaware of trade-off. When the "buggy" part happens, they treat it as "we have incapable developers" and not as reason to change something in process and requirements gathering. By overly internally inconsistent I mean that at some places they will be impossible to fulfill. The code will always breaking at edge cases. The ui will do three things at the same time, will be incoherent and will be complicated for user to understand and learn. By complicated I mean that you will have to code super complicated hard to maintain structures to fulfill everything at the same time. Marketing can not be requirements gathering, because marketing is motivated to promise everything to everybody and to exaggerate. I dont use exaggerate here as euphemism for "lie" through that happens too. Exaggerating itself is a problem. Marketing is not motivated to build coherent analysis. I know because I worked on projects where marketing was driving requirements . It did not led to happy customers, because customers were unhappy over instability and our inability to fill their requirements in a reasonable way.
    - erikrothoff 7y ago
      I’m pretty sure we are talking about different things. The marketing I’m talking about is in the context of sole developers or small developer only teams where the goal is to launch a successful product. Be it on a hobby scale or the start of something bigger. These developers/hackers gone founders need to evolve their marketing skills at the same pace the product is built. I feel what you are talking about is a siloed approach where developers build what the marketing team promises to customers. If these teams are the same people you are the developer and marketing team, and thus over-promising things to customers is only shooting yourself in the foot.

jakequade 7y ago

I think you're both giving marketing too much credit in the product's creation, and inverting the creation process in general. > It’s like waiting to build the backend until the frontend is 100% complete It's more like building a backend, then realising that the data structures could be improved when you're building the front. Marketing at best provides enhancements, not core changes (unless your product itself was incorrect to begin with). Honestly, if your marketing affects your product as much as you're suggesting, you have a pretty unstable product.

rapphil 7y ago
But marketing can help the dev team focus on the core functionalities that the customer really want.
- watwut 7y ago
  No, marketing as driver will cause massive feature creep.
  - speedplane 7y ago
    > No, marketing as driver will cause massive feature creep. Marketing is about exposing your product to your target customers. It's relatively orthogonal to product features.
erikrothoff 7y ago
I disagree. Marketing gets people in. Users guide product development and thus the product. If an ”unstable product” is one that users actually want to use, then I guess an unstable product is a good thing?
- watwut 7y ago
  Treating marketing as requirements gathering gets you overly complicated internally inconsistent requirements. The instability is side product. Marketing is not making trade-off between bugs and features, they are unaware of trade-off. When the "buggy" part happens, they treat it as "we have incapable developers" and not as reason to change something in process and requirements gathering. By overly internally inconsistent I mean that at some places they will be impossible to fulfill. The code will always breaking at edge cases. The ui will do three things at the same time, will be incoherent and will be complicated for user to understand and learn. By complicated I mean that you will have to code super complicated hard to maintain structures to fulfill everything at the same time. Marketing can not be requirements gathering, because marketing is motivated to promise everything to everybody and to exaggerate. I dont use exaggerate here as euphemism for "lie" through that happens too. Exaggerating itself is a problem. Marketing is not motivated to build coherent analysis. I know because I worked on projects where marketing was driving requirements . It did not led to happy customers, because customers were unhappy over instability and our inability to fill their requirements in a reasonable way.
  - erikrothoff 7y ago
    I’m pretty sure we are talking about different things. The marketing I’m talking about is in the context of sole developers or small developer only teams where the goal is to launch a successful product. Be it on a hobby scale or the start of something bigger. These developers/hackers gone founders need to evolve their marketing skills at the same pace the product is built. I feel what you are talking about is a siloed approach where developers build what the marketing team promises to customers. If these teams are the same people you are the developer and marketing team, and thus over-promising things to customers is only shooting yourself in the foot.