Earlier quoted context omitted.
Prototype. Make a pen-and-paper version, pantomime the game, tell the story -- do something to test the game's excitement power before building it. http://www.pathsensitive.com/2015/10/the-prototype-stereotyp...
Not sure if angry birds would have made a great pen & paper game ;-)
Sales mistakes that software engineers make
191–200 of 204 posts
Re: Sales mistakes that software engineers make
#192> Sales Mistake #1 - Building Before you Start Selling (...) If you’re wrong, you’ll save time and money by not building something people don’t want. I fell into this trap often, so I know it well. The reason why we don't ask first is, we want to build something . Anything. If we're "wrong", we won't "save" time and money, we will delay the moment we start making, maybe indefinitely. What if we never find something p…
>> The reason why we don't ask first is, we want to build something. Correlation isn't causation. Please don't be too upfront about "why we don't ask first". Have you often encountered a situation where your non-tech boss didn't listen enough and you were right in the end? Or the cases when he even forgets a month later you were right in the first place? Or the times when you decided not to listen to your management…
My thought are usually; "I know no one wants it now... but that's because they can't see my vision..."
How many times do I have to destroy my ego...
Re: Sales mistakes that software engineers make
#193> Sales Mistake #1 - Building Before you Start Selling (...) If you’re wrong, you’ll save time and money by not building something people don’t want. I fell into this trap often, so I know it well. The reason why we don't ask first is, we want to build something . Anything. If we're "wrong", we won't "save" time and money, we will delay the moment we start making, maybe indefinitely. What if we never find something p…
True. Especially when I build something that solves one of my own problems. I think it's great and maybe others would like it too. Then I discover that amongst all of humanity, I have problems which are absolutely unique and shared by no one else, anywhere.
Re: Sales mistakes that software engineers make
#194Earlier quoted context omitted.
I don't understand down votes. I often will see the price of an API (cough Google maps) and roll my own solution.
An independent developer capable of making a replacement for the entire Google maps API on their own probably isn’t likely to remain poor for long.
But where the heck am I supposed to get all the data?
Re: Sales mistakes that software engineers make
#195Earlier quoted context omitted.
Don't be so hard on yourself. Someone else somewhere probably does have each problem that you have. But finding them is prohibitively costly.
And they're poor.
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.
Re: Sales mistakes that software engineers make
#196Earlier quoted context omitted.
An independent developer capable of making a replacement for the entire Google maps API on their own probably isn’t likely to remain poor for long.
Creating an API isn't that hard. Crafting system architecture to handle a reasonable amount of load isn't that hard nowadays either. 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.
Re: Sales mistakes that software engineers make
#197Earlier quoted context omitted.
The point isn't to finish selling before you build, the point is to start selling -- do market research -- before you build. You use the term "investment" -- do you invest in stock market / bitcoin / real estate by buying whatever looks cool, and chalking up your losses to the learning process, or do you research your choices and look for ROI opportunities??
I agree that your interpretation is right, but "start selling" is an extremely ambiguous phrase here. After all, "a sale" is most often understood to be a finalized sale; "to sell" is most often understood to be completed transaction. Yes, the idea here is, "understand who you're marketing to and what they're looking for before you start building," and the phrasing used is what it is because that's catchier, but it's…
That is certainly the understanding of laymen. However, if you talk to people who work in sales, and look at their "pipelines" for creating sales leads, followup, closing, and whatever else they do, you get the sense that "selling" is actually an extensive, multi-part process. At least I think that's the view most sales professionals would have.
Re: Sales mistakes that software engineers make
#198I fall into the "Build before talking to customers" trap constantly. Even though I know it's "wrong", it is hard to escape it because of the simple problem of not knowing who to talk to. The article suggests doing a search for potential companies, finding contacts on linkedin, and sending out some emails. But what about experimental technologies or developer tools? I wouldn't expect a lot of success with a slow movin…
> there's no way to search "startups using x" for a generic technology, like serverless or NoSQL. Smells like a side project waiting to be built.
Re: Sales mistakes that software engineers make
#199I'd venture to guess that a good litmus test for knowing if someone is ready to start a business is measuring their ability to deal with conflict.
When engineers aren't good at dealing with conflict, they are likely heading towards escapism when they start a project:
1) Engineers sometimes don't necessarily want customers, they want intellectual freedom. Having customers is scary, and if your subconscious goal is escapism, having customers is even scarier. 2) Listening to people may lead you down the road of doing something you don't want to do. See #1. This may mean not having the freedom to do what you think you want to do. Which likely is not making money.
Re: Sales mistakes that software engineers make
#200I sometimes don't understand why technical people seem resistant to "lean startup" methodologies. It's just the scientific method, applied to build a product! You build hypotheses, then try to prove them, and in the course of this, usually learn more information about the world. That simple. You think you have a product which is useful to someone? Prove it! Talk to people, ask them, build simple prototypes of the cor…