> This brings up a very unusual business model for aspiring entrepreneurs. Work in a domain that is technologically challenged until you understand it profoundly. Then start a business that advances that domain by empowering its actors.
I wonder... is collaborating with someone who 'profoundly' understands the domain a way to short-circuit this process?
It's definitely how most people do things today. The way I did it, like everything else, has its pros and cons.
Some of the pros:
1. My buddies in the dealership domain are my customers. They call me up and ask me for a feature directly.
From my experience, this yields better quality features than talking to the domain expert that's probably trying to translate his conversation with the customer.
2. There's the advantage of you being in a domain where most people are your friends then your potential users. A lot of psychological walls are broken this way (what is he trying to sell me?). We trust each other by our reputation in the industry and this tends to extend to they quality of software they expect from us. Them knowing that we're developing it ourselves helps a lot.
Imagine cold walking into a business like a salesman would and offering your product. Now imagine walking into the business where you know the owner very well and you intend of having coffee with him first, then telling him about how you might be able to help him out. Big difference.
There are more, but these come to mind now.
So it's not only quality of software, but also how much easier it is to get your first paid user base that will enable you to create a good product that would hopefully scale beyond your paid-users-as-friends.
Muggles don't have a technically informed imagination.
If you've had a boss or consulting client asking for convoluted features (or more likely solving the wrong problem), you know what I'm talking about.
Can a supportive cofounder be better? If they listen to what you have to say. But there's another category of failure with a tech-biz duo: they won't know to ask for the really simple to implement but insanely lucrative features.
In my first tech job, I had a conversation with a person writing specs. He was explaining what he was going to put in for the next version.
-"Have you thought of Y?"
-"Maybe for the version after that, it would be really useful but I don't think we have time to do it before X"
-"Y is 10 times easier to implement than X"
-"Oh..."
Laziness and domain knowledge are a great combo. I'm sure several others here have had the same conversation.
Doing customer discovery recently a customer told me: "That would be the holy grail of retail". None of my likely competitors are showing any signs of tackling the same problem. Maybe my strategy is dead wrong. I'm betting my competitors are all techies with little in the way of domain knowledge.
Nice work.
One thing I dislike is the absence of PRICE until I fill out all the information. A lot of online fads ask for all your information (including credit cards) before they tell you how much they are going to charge. And this is really a bad practice. Just tell me upfront how much you want me to pay before you ask for my email/phone/name/address etc.
Good article and being domain-specific has allowed you to really focus. It looks from your FAQ that you're still in 'beta' (although that word is not used) from your pricing policy. Are you experimenting with different pricing here or are you just being secretive? Curious as pricing has always been something that I've struggled with setting with our products, so wondering how you're doing it
Nope, no secrecy. I really don't believe in it for most situations.
It's mostly my tendency (weakness) to focus on developing new features than to update the marketing site. I'll be updating this with pricing very soon since I finally hired a great developer to help out in some of my coding responsibilities and to help shape ZZA's policies and future.
-------------
Here's our current pricing:
10 cars or less $55.
70 cars or less $125.
200 cars or less $225.
No contract. No limit on features. No setup fee.
--------------
Here's what we did/considered to reach these prices
0. We wanted to serve the startup dealerships. We know how hard it is to start one up (we did it, after all), so we wanted to provide a cheaper entry point.
1. We looked at what competitors were charging and what features they were providing.
2. We talked to more than 10 dealers to get their input.
3. We definitely don't want to convey that we are competing on prices. We're not! We're competing on understanding of domain, features and quality.
4. I read some blogs regarding this subject. Like Joel's and some others.
5. Had tons of discussions with people who's judgment I trust.
6. Estimated at what volume of vehicles would a given price make the most sense.
After doing these things, I simply wrote down 10 @ 55, 70 @ 125, 200 @ 225. It felt right.
As you can see, it's very non-scientific and many would disagree with this way of doing it. But it's what we did.
Maybe when it's time to rethink our prices, we'll have more time for surveys and research.
Thanks for this and amusingly I've followed the same 'path' - what feels right. I majored in Business at university (and only subsequently taught myself to program so I could converse correctly with the programmers I employed) and we were taught to do a lot of market research before making a decision. I've never really done that though and just chose a price which is why I asked the question. Maybe the market ultimately decides by whether they buy or not. Thank you for sharing though - really appreciate it and I'm sure others on here do also. Best of luck with your venture
I've noticed in a few of these stories that the path the entrepreneur took wasn't optimal by their own standards (e.g. charging early), yet there is still success.
If you want success, should you follow what they did rather than what their advice says you should do?
A very valid point and it has come up in my head many times, not just in regards to entrepreneurship, but other issues with a similar pattern.
Before giving out the advice, I had to ask myself whether things started getting better because of charging customers, or did charging customers coincide with an unknown event that caused some success?
Everything points to the former, in my case. But I do believe this particular advice applies to many other startups, not just mine.
Edit: I'd like to add, that after charging and studying usage more closely we removed some unused 'cool' feature that we thought were awesome. Charging customers also prunes your app. If you pay attention.
Did these other sites permit you to post listings directly to their site using an API? How about extending this idea to motorcycles? You could add cycletrader or other motorcycle specific sites.
The sites that don't have an API, we simply provide an iframe and provide the user the tools to easily cut & paste into the iframe (Worst part in the app). 90% do have APIs though, which we use extensively.
Right now, my niche is only dealers with 200 cars or less. It's what I know. Later, when I feel like we've dominated this niche, we'll expand into other areas for sure.
Video sounds really cool, but our niche doesn't seem to care for it much. It's mostly the high end dealers that like them. Maybe one day when we target them.
In the last few months, my focus has been 90% on the software.
What I did with the dealership is Im more or less, followed the advice in E-Myth (http://www.amazon.com/E-Myth-Revisited-Small-Businesses-Abou...) and created position contracts for all our employees (7 of them now.) This has cut my involvement in the dealership tremendously. Now, I only put out fires, make sure management is going smoothly and handle some of the accounting.
At the head of the dealership is my brother, whom I trust. He makes sure that all manuals are updated and are followed. I make sure his position contract is followed.
This way of doing things will be much harder if you don't have a partner that you can trust to handle his part. Specially when things start growing.
I wonder... is collaborating with someone who 'profoundly' understands the domain a way to short-circuit this process?