You could write a book on this. Heck, I probably should - I've done it a few times :)
A short list (but by no means anywhere near complete!):
- Find as many blogs in your niche as possible. Pitch them properly (a lot could be written on that point alone) DON'T JUST GO FOR THE BIG ONES! The smaller blogs are more likely to link to you if you're friendly to them and develop rapport.. I run blogs with over 10,000 subscribers and I love helping people who are FRIENDLY and GENUINE.
- Use your social network.. you've been building one up, right? Make sure all your Twitter and Facebook followers know about what you're doing. Lean on your Linked In contacts.
- Find places where users of competing applications gather (forums, Google Groups, etc) and work your way into their attention zone.
- See if there's a sub-Reddit that's specifically for your niche. Find people to charm there, post ancillary links regarding your app, etc. Don't over-do it.
- Post it on HR (as someone said above)
- Find your way in to interviews, podcasts, etc. A lot of content providers are dying for more content - you might make a great interviewee. The media is less opaque than it seems.
- Go to events! Make sure you have an elevator pitch. Get excited. Wear schwag featuring your logo, etc, if you want to. Don't just focus on the big-wigs - get anyone who might find your service useful excited.
- Does your design rock? Get on to the "CSS design", and "Web design" show case type sites. There are hundreds of them around. Not amazing exposure, but the more links the better and any one of your visitors might turn in to a serious contact.
- Start your own blog for your company / startup. Make it really interesting. Be candid. Show off new features. Show off stuff you're working on. Show off your team or your technology. Build up your own tribe of followers. They will make all the difference when it comes to saving you on del.icio.us, Digg, Reddit, and so forth.
- Make sure you stay on top of your e-mail. Customers might test you with e-mails - responding quickly and completely can make the difference between sales and no sales - or life and death with a startup.
- Find ancillary reasons to get your service mentioned in blog posts and tutorials. For example, if your startup is an RSS mashup generator of some sort, you need to have tutorials out there that recommend your service. Get those tutorials and posts on to Reddit, Hacker News, Digg, etc.
- If people write about your site, write tutorials that mention you, etc, PROMOTE THAT CONTENT EVEN IF IT'S NOT YOURS! Get people reading stuff that's about you - not by you!
- Remember that bigger sites like TechCrunch and ReadWriteWeb (if applicable to your sector) love exclusives. Don't bother mass pitching those - focus on one, whichever you can get best rapport with, and offer an exclusive. Your product needs to be AWESOME for this to work though.
- Follow a search.twitter.com search on terms related to your service (and even the name of your service) .. get in touch with people who might be interested, respond to all comments about your service.
- Write a bog standard press release and submit through the standard channels. This will not help much but at least your company name/service name will end up with a ton of results in Google - this can help you look bigger than you are. You /may/ even get some offline coverage if the press release is actually kinda good (but not too crazy). It's cheap to do this.
- Build ancillary "fun" services that tie into your main web app. Something fun, free, perhaps something that you can relate to sites people find interesting, such as Twitter. Let's say your main service is an online graphics editor. Perhaps you could create a separate site where people can create avatars for Twitter / Facebook from a small set of templates.. separate project but promoting the first.
- Hustle, hustle, hustle! Make sure you know as soon as someone blogs about your service. Follow Google Blog Searches, etc. Keep Googling. Get commenting on blogs (not in a spammy way - just get your name and service out there). If someone needs to do something your service offers, you need to be there!
I believe Jason Calacanis wrote an interesting piece on doing PR for a startup recently. Find that article and read it - I recall it was very good.
..
BTW, if anyone thinks I might be able to turn this into a good book, resource site, or similar, vote this up and I might give it a try! :)
Broken record: startups are also probably rejecting a lot of engineering candidates that would perform as well or better than anyone on their existing team, because tech industry hiring processes are folkloric and irrational.
I co-manage a consultancy. We operate in the valley. We're in a very specialized niche that is especially demanding of software development skills. Our skills needs also track the market, because we have to play on our clients turf. Consultancies running in steady state have an especially direct relationship between recruiting and revenue.
A few years ago, we found ourselves crunched. We turned a lot of different knobs to try to solve the problem. For a while, Hacker News was our #1 recruiting vehicle. We ran ads. We went to events at schools. We shook down our networks and those of our team (by offering larger and larger recruiting bonuses, among other things).
We have since resolved this problem. My current perspective is that we have little trouble filling slots as we add them, in any market --- we operate in Chicago (where it is trivially easy to recruit), SFBA (harder), and NYC (hardest). We've been in a comfortable place with recruiting for almost a year now (ie, about half the lifetime of a typical startup).
I attribute our success to just a few things:
* We created long-running outreach events (the Watsi-pledging crypto challenges, the joint Square MSP CTF) that are graded so that large numbers of people can engage and get value from them, but people who are especially interested in them can self-select their way to talking to us about a job. Worth mentioning: the crypto challenges, which are currently by far our most successful recruiting vehicle (followed by Stripe's CTF #2) are just a series of emails we send; they're essentially a blog post that we weaponized instead of wasting on a blog.
* We totally overhauled our interview process, with three main goals: (1) we over-communicate and sell our roles before we ever get selective with candidates, (2) we use quantifiable work-sample tests as the most important weighted component in selecting candidates, and (3) we standardize interviews so we can track what is and isn't predictive of success.
Both of these approaches have paid off, but improving interviews has been the more important of the two. Compare the first 2/3rds of Matasano's lifetime to the last 1/3rd. The typical candidate we've hired lately would never have gotten hired at early Matasano, because (a) they wouldn't have had the resume for it, and (b) we over-weighted intangibles like how convincing candidates were in face-to-face interviews. But the candidates we've hired lately compare extremely well to our earlier teams! It's actually kind of magical: we interview people whose only prior work experience is "Line of Business .NET Developer", and they end up showing us how to write exploits for elliptic curve partial nonce bias attacks that involve Fourier transforms and BKZ lattice reduction steps that take 6 hours to run.
How? By running an outreach program that attracts people who are interested in crypto, and building an interview process that doesn't care what your resume says or how slick you are in an interview.
Call it the "Moneyball" strategy.
Later: if I've hijacked the thread here, let me know; I've said all this before and am happy to delete the comment.
Here's the recommendation I give to students when they ask me this question (it's a common one!):
You come up with a brilliant idea, you obsess over it, you Google some info, and on your screen lies your idea, being done by someone else, for the last two years. You’re all too familiar with that sinking feeling in your stomach that follows. You abandon the idea almost immediately after all that excitement and ideation.
First (as already mentioned), existing solutions prove your idea — their existence proves that you’re trying to solve a real problem that people might pay to have solved. And it proves that you’re heading in a direction that makes sense to others, too.
Second, and this is the biggie: The moment you see someone else’s solution, you mar and limit your ideas. It suddenly becomes a lot more difficult to think outside the box because before, you were exploring totally new territory. Your mind was pioneering in a frontier that had no paths. But now, you’ve seen someone else’s path. It becomes much harder to see any other potential paths. It becomes much harder to be freely creative.
Next time you come up with that great idea, don’t Google it for a week. Let your mind fester on the idea, allow it to grow like many branches from a trunk. Jot down all of the tangentially related but equally exciting ideas that inevitably follow. Allow your mind to take the idea far into new places. No, you won’t build 90% of them, but give yourself the time to enjoy exploring the idea totally.
When I do this, once I do Google for existing solutions, I usually find that all the other things I came up with in the ensuing week are far better than what’s already out there. I have more innovative ideas for where it could go next; I have a unique value proposition that the other folks haven’t figured out yet. But had I searched for them first, I never would have come up with those better ideas at all.
Finally, I’ll say this: if you see your idea has already been done and you no longer care about it, then it probably wasn’t something you were passionate enough about in the first place; it was just a neat idea to you.
I'm the founder of a company that is ~250 people, remote first, and still fully remote. We do have an office in SF, but ~10% of our employees are present, almost no full teams are centralized, and all our processes revolve around remote work. Important to note that we're a US-founded company (this comes along later).
I'm going to use this comment as a way to talk about remote hiring generally, rather than respond directly to your comments. I want to help others understand some of the challenges it has been being one of the larger (relatively) fully distributed companies.
I think there is a common misconception that the world is mostly flat and that our company can hire from anywhere. I am commonly criticized when tweeting job postings (almost always remote) when the countries we can hire from is limited to a select few. "Not real remote" "first world remote only" "remote != 8 countries" etc. are common criticisms.
Disclaimer for the remainder: I am not a lawyer and my exact details because of that may be wrong. Please consult your own legal team.
When hiring remote, there are a few things to keep in mind:
1.) You have to adhere to employment laws within the country you're hiring from. Employment laws vary widely between countries and getting them wrong can be very expensive. For example: vacation time will vary, holidays will vary, the ability to let someone go will vary, what you can/cannot expect from an employee varies. In one country, emailing an employee outside of work hours is legally considered harassment; when working with multiple timezones that's a challenge because "in work hours" for one country may be "out of work hours" for another country.
2.) To employ someone full time, many countries require you to have a legally entity within that country. Establishing a legal entity takes a lot of time and a lot of money.
In the past 12 months, we've had at least one member (more now) on our HR/finance teams establishing legal entities _full time_. I've had my signature on at least 8 incorporation documents in the past 6 months. By the way, most incorporation documents require a "wet" signature so if you're remote like we are, be prepared to be FedExing a lot of sensitive legal documents around.
Beyond just paperwork, there are often requirements to establish a legal entity: a real, physical, local address is one. In one country, we had to pay out of a local bank account in local currency (which has its own red tape), and this country also required we maintain a minimum balance to pay 3 months salary in the local account in local currency at all times. For a startup, that much cash "not working" can be problematic depending what stage you're at.
In one country we're establishing an entity in, the process just takes a LONG time. We've been responding to any inquiries and sending paperwork immediately and we're 8 months in and still probably 2 months away from completing the process. Meanwhile, we still can't legally hire there.
A lot of legal paperwork is understandable in the local language of where you're creating the entity. This means that you also have to pay lawyers fluent in that language to vet the paperwork. We employ full time lawyers, but primarily in English, so this requires us to go to expensive outside counsel.
Finally, this is all expensive. There are fees to creating entities but also recall that we have multiple full time employees that spend their entire day establishing legal entities. So we have our own full time salary costs plus filing costs plus legal costs.
3.) Hiring contractors DOES work around some issues, but has its own downsides. First, we can't offer options/stock to contractors and we'd like all our employees to benefit from this. Second, we often can extend the same full time benefits we want all our employees to share such as healthcare, 401K, etc. Put another way: we want all HashiCorp employees to be employees, we don't want to create second class citizens.
Legally, some countries have legal limits on the hours a contractor can work or length of time they can be contracted before they're considered an "employee" by default and regardless of what you SAY the relationship is, the country will consider it employment and points 1 and 2 above all take effect immediately.
So we certainly DO hire contractors but our point of view is that we intend to hire those people full time over time. We'll often hire contractors if we know that we'll have a legal entity established to hire them within X months, and we're up front with the new hire about this. We'll also pro-rate option/stock vesting for their contractor period when they are hired.
4.) We prioritize countries where we have the most interest. We get asked a lot "please hire in X" but if the number of times we've heard X is much lower than Y, then we'll prioritize Y first.
This creates somewhat of an imbalance, since more countries with a more established tech ecosystem generally have more qualified candidates and therefore get prioritized higher.
We WANT to hire from everywhere, but as a startup with constrained capital and timelines, we have to be pragmatic about choosing the locations where we'll probably be able to hire the most roles while we continue to expand our entities.
5.) We are also open to relocating employees into countries where we do have entities. We've done this multiple times, we pay a relocation fee, and its a great way to hire someone from a country where we can't [yet]. Also note they're "relocating" but are still working remote.
Of course, this is highly dependent on the individual and it is unfair of us to ask or force someone to do this if they have an established family, friend circle, and generally just a life in their existing country. So this only works some of the time!
6.) Despite building process around remote-first, we try to a keep a healthy timezone overlap in each of our teams (3 to 4 hours out of the working day is best). We find that teams that have a team member with a non-overlapping TZ struggle for multiple reasons. So, even though we can hire in many countries now, we'll restrict some job postings to certain countries so we can have that overlap.
EDIT, some additions:
7.) Each US state ALSO requires a legal entity in addition to adhering to state-local employment laws, taxes, and more. At this point HashiCorp has entities in ~30 US states.
Further, there is a tax consequence to the business outside of employment taxes. If you hire an employee in a state, you also now have to pay sales tax on revenue from there. You may argue for/against whether that makes sense, but for a startup this can be VERY expensive.
Our corporate tax obligation would be hundreds of thousands of dollars [less] if we didn't employ people in New York state. We've had to weigh this in cases because the tax obligation from hiring _one_ individual could suddenly be that you can't afford to hire _multiple_ other individuals.
Note we don't want to avoid taxes, that's not what we're doing. But startups are capital constrained and we have to determine long term how we continue to grow and hundreds of thousands of dollars can make a difference.
Finally, I want to note that we're 100% dedicated at HashiCorp to remaining fully remote. We WANT to hire from everywhere. We're establishing the entities and process to hire in new countries full time. 18 months ago we could only legally hire in 2 countries, today we can hire in 8. By the end of the year it should be at least 4 more. We'll continue from there.
I could write a LOT more about culture and process within the company. But this comment is already getting very long and I think I'll keep it to this. Maybe in the future I'll write more about "chat literacy", the importance of decision inclusion, things that definitely don't work, keeping people motivated/happy, managing people you can't physically see, the lack of body language for signaling, and a lot more.
These comments from "How to come up with monetizable side projects ideas" post.
----------------------------------------------
1. Find a popular SaaS product. Like Intercom, Algolia, Segment. Make sure it doesn't have a free plan. This guarantees there's a market for the tool. Check out GetLatka for ideas. https://getlatka.com
2. Build your own take on the product. Find the minimum set of features that make it valuable. 10% of the work for 80% of the value.
3. Sell it at a 50-90% discount. There will be price sensitive customers that want the popular product, but don't want to or can't afford it.
4. Target bottom of funnel marketing channels: Targeted quora questions. Paid/organic search queries. Set up retargeting ads on Facebook. Product hunt launch it. That should get you a steady stream of customers.
I don't think this is a great way to build a million dollar business, but is a very easy way to make a few hundred. Shoot me an email if I can be helpful.
Don't exactly copy another product. It's damn important to reinvent defensible products that either, and hopefully do all of:
a) solve a slightly different problem
b) target different users
c) solve the problem in a 10x better, compelling way
-------------------------------------------------
TIME. Time is the MOST precious commodity. Help users SAVE TIME. Save time finding something of value to the USER. You can't "presume" how much to charge. You have to "TEST" pricing then keep jacking it up until your customers don't pay. How can you pay for something what does not offer value. Stay small. Stay NICHE. Grab a slice from a BIG market. Forget millions. slap-yo-self with fury with delusions of becoming a millionaire, and make a goal of making enough to avoid being trapped in a 9-5 lifer situation. It take a LOT of luck + skill + market segment expertise. Like you have to KNOW the market you are going to be competing in. Assisted living , senior care , retirement calculator is VERY hot now. You'll be at it after your day gig 6pm-2am testing / building / iterating. Good LUCKY. launch a free beta version learn what customers value and how much they will pay ( ask them) THEN when you have enough people crack addict addicted to your service / app start charging. Be merciless. But offer excellent customer service. Always be honest.
------------------------------------------------
While I agree with some of the tactics here (make a twist on similar ideas, contact businesses, buy a business, brush up an existing product you built)
I'm going to suggest an alternative method that has worked for me.
Start with the money.
If you want monetization to be guaranteed you need to prioritize that first.
Take this method and rinse/repeat for you and your skills.
1) How much do you really want to make from this a month, what would make you happy?
Let's say you decide $1k a month would make it worth it after time, expenses and payment processing fees.
2) You then decide how many customers you really want to have to find and how much support email you want to answer.
Usually developers pick prices like $6 and wonder why no-one buys. This low price screams a lack of confidence in the product. That you aren't taking it seriously. That you may not be around in 8 weeks.
Starting without monetization in mind or equally, pricing low is the death of a product because for someone who dislikes marketing you just set yourself a huge marketing mountain to climb.
At $6 each, finding and selling to 150+ customers - when you don't even have one yet is a huge trek to your $1k happy place.
Let's say you feel more confident about finding and serving 10 customers really well. That seems achievable, right?
So with just 10 customers we're looking at a $100 a month product, right?
Whoa, you're thinking you could never build something that's worth that much.
Maybe you're worried it's enterprise level costs now and that's not the type of product you want to build.
Don't worry, a $100 product can be really simple.
Often developers think that a big cost means solving a big problem and that a big problem needs a big solution. Not true at all.
A big problem can be solved with a small elegant solution.
3) Now we know how much we want to make and how many customers we need and how much we are going to sell it for.
We now need to find the problem we are going to solve.
So how big of a problem needs a $100 per month solution?
Not very big at all really.
Let's say a business owners time is super-conservatively worth $50-$100 an hour.
So to add value, we are looking at saving someone between 2-4 hours a month on a task they normally have to do manually. That's not too bad!
Or maybe you want to help them reduce their business costs by $200-$400. Also, very possible. Now we have the value proposition.
We know what kind of problem we are looking for, so value will be clear for the customer.
4) Now we decide _who_ this is going to be for.
Don't pick people the same as you. They have the same skills and can solve the same kinds of problems that you can.
Pick a group of people :-
- That are easily identifiable by what they call themselves on social media (blogger, podcaster, videographer, designer, public speaker etc)
- Make sure they are a group you like interacting with, that you have some experience of working with already in some way (please pick a group you like and care about)
- Make sure they are the decision maker in their own business (don't pick employees of big corps)
- What tech skills have you worked with that overlaps with this customer group?
Let's say you've worked on a few video platforms in the past so you know that space well, so you choose to help YouTubers.
5) What is the issue that we are solving?
Ok, so now we're helping YouTubers to either save 2-4+ hours a month or reduce costs by $200+ - for your $100 MRR product.
This is where we breakdown what it takes to run their business.
What stops them being more profitable?
What tasks do they do everyday?
What can be automated?
What do they hate doing in their business?
If you know this space even a little, you will have answers here.
Maybe video storage is a huge expense.
Perhaps running their community takes up too much time so they can't scale.
Is just publishing a video end to end super time consuming? Look at why.
If you don't know what matters to them, ask. Make a hypothesis and see if it's true.
In just a couple of DM's you might find that they spend a whole day a week on something repetitive. Or are spending money on something that you can optimize. Write a few possibilities down.
6) Make an offer
In just a day or two you can go from no idea, to identifying a significant pain point for a group of people that's easy to reach.
Now you consider a couple of small technical solutions for the problems you've found.
You go back to a couple of your ideal customers and make them a proposition.
Something like - "You said you spent X hours on this particular problem. If I built something to solve that, this week, would that be worth $100 to you?"
If it's a huge pain point they will bite your hand off. If you get weak responses - no worry, you've not built any code yet. You can use the conversation to get to a deal.
They might say it's worth less so you find out what features would be needed to make it worth the $100.
Maybe they suggest a different problem that is more urgent for them.
After a few conversations you should have at least a couple of paying customers and a clear solution.
8) Building
Now you know exactly what you need to build and have customers waiting. There is no excuse but to launch. This will help you focus on the truly essential code.
As you build, reach out to a few more potential customers. (we made sure they were easy to find earlier) Ask them if they have the same problem. Show them what you have.
Go through a few cycles of building and feedback. Make sure people are paying you what you set out in the beginning - or close to it.
Ask your starting customers for referrals. You'll reach your 10 customers with zero marketing spend.
You then have all of the elements needed to scale further if you wish!
Remember that code comes last in this method for a reason. Only build when you have paying customers.
Usually you offer a connect button with the most popular providers. You could also detect a login with somename@whateverapplemaildomain in order to passthrough for those addresses. There are some discovery mechanisms that can be added for DNS/http(s) services as well against different tlds.
In the end, probably would just add an apple-logo button next to twitter, google and facebook auth buttons.
----
Aside, in terms of data storage, separate the account, user and login/auth details. An account is related to activity inside the system. A user is a person authorized to use/act on or as that account. A login is an authority and related information to enter as a given user. Logins can be an OpenID reference, AD Integrated User, an API token, a local password entry (salted/hashed of course).
If you make the separations above, you'll have far fewer issues if/when you need to make your application more flexible in terms of users/authentication against accounts. It also is very helpful when you will have "individual" accounts and "business entity" accounts, which may have variances in UI/UX.
Beyond this, would separate the actual API/UI systems from auth systems relying on integrated tokens (like RSA signed JWT on an internal authority). In this way, your API systems only need to worry about "allowed" signers, and the roles assigned in the token's claims. Of course then there are issues with token lifetime, refresh and revocation to consider.
Sorry for the blathering on this, literally working on an authentication management system (fairly barebones initially) right now. MVP at end of day after 4 months work.
* Basic Monitoring, instrumentation, health checks
* Distributed logging, tracing
* Ready to isolate not just code, but whole build+test+package+promote for every service
* Can define upstream/downstream/compile-time/runtime dependencies clearly for each service
* Know how to build, expose and maintain good APIs and contracts
* Ready to honor b/w and f/w compatibility, even if you're the same person consuming this service on the other side
* Good unit testing skills and readiness to do more (as you add more microservices it gets harder to bring everything up, hence more unit/contract/api test driven and lesser e2e driven)
* Aware of [micro] service vs modules vs libraries, distributed monolith, coordinated releases, database-driven integration, etc
* Know infrastructure automation (you'll need more of it)
* Have working CI/CD infrastructure
* Have or ready to invest in development tooling, shared libraries, internal artifact registries, etc
* Have engineering methodologies and process-tools to split down features and develop/track/release them across multiple services (xp, pivotal, scrum, etc)
* A lot more that doesn't come to mind immediately
Thing is - these are all generally good engineering practices.
But with monoliths, you can get away without having to do them. There is the "login to server, clone, run some commands, start a stupid nohup daemon and run ps/top/tail to monitor" way. But with microservices, your average engineering standards have to be really high. Its not enough if you have good developers. You need great engineers.
This is a great post and so spot on. At some point in my career my 'review prep' (which was the time I spent working on my own evaluation of my year at a company) became answering the question, "Do I still want to work here?" I categorize my 'review' in four sections (which are each rated at one of five levels, needs improvement, sometimes meets expectations, meets expectations, sometimes exceeds expectations, or consistently exceeds expectations)
I start by reviewing how I'm being managed, I expect someone managing me to be clear in their expectations of my work product, provide resources when I have identified the need to complete jobs, can clearly articulate the problem I am expected to be solving, and can clearly articulate the criteria by which the solution will be evaluated.
Second I review my co-workers, using a three axis evaluation, can I trust what they say to be accurate/honest, can I count on them to meet their commitments, and are they willing to teach me when I don't understand something and conversely learn when their is something they do not know.
Third I review what level of support do I get to do my job. Am I provided with a workspace where I can get work done? Do have have the equipment I need to do what is being asked? Is my commute conducive to the hours required? And finally and most important, does this job allow me to balance work obligations and non-work obligations?
Fourth I review whether or not the company mission, ethics, and culture is still one that I wish to be a part of. Am I proud of the company's mission? Do I believe that the leadership will make ethical calls even if doing so would mean less profit margin? Can I relate to and am I compatible with the values that my co-workers espouse and the actions they take? (this is the "company culture" theme, is it still a company that fits me culturally)
A company that receives lower than a 3.0 rating I put on a 90 day "company improvement plan" (CIP). I bring issues to the leadership who are in a position to address the situations that I've found wanting and try to secure their commitment to change. If after 90 days they haven't been able to (if they choose not to they're done right away), then I "fire" the company and work to process my exit as expeditiously as possible.
Hasura by far, lets you point-and-click build your database and table relationships with a web dashboard and autogenerates a full GraphQL CRUD API with permissions you can configure and JWT/webhook auth baked-in.
I've been able to build in a weekend no-code what would've taken my team weeks or months to build by hand, even with something as productive as Rails. It automates the boring stuff and you just have to write single endpoints for custom business logic, like "send a welcome email on sign-up" or "process a payment".
It has a database viewer, but it's not the core of the product, so I use Forest Admin to autogenerate an Admin Dashboard that non-technical team members can use:
For interacting with Hasura from a client, you can autogenerate fully-typed & documented query components in your framework of choice using GraphQL Code Generator:
Then I usually throw Metabase in there as a self-hosted Business Intelligence platform for non-technical people to use as well, and PostHog for analytics:
Yes, there are tons of resources but I'll try to offer some simple tips.
1. Sales is a lot like golf. You can make it so complicated as to be impossible or you can simply walk up and hit the ball. I've been leading and building sales orgs for almost 20 years and my advice is to walk up and hit the ball.
2. Sales is about people and it's about problem solving. It is not about solutions or technology or chemicals or lines of code or artichokes. It's about people and it's about solving problems.
3. People buy 4 things and 4 things only. Ever. Those 4 things are time, money, sex, and approval/peace of mind. If you try selling something other than those 4 things you will fail.
4. People buy aspirin always. They buy vitamins only occassionally and at unpredictable times. Sell aspirin.
5. I say in every talk I give: "all things being equal people buy from their friends. So make everything else equal then go make a lot of friends."
6. Being valuable and useful is all you ever need to do to sell things. Help people out. Send interesting posts. Write birthday cards. Record videos sharing your ideas for growing their business. Introduce people who would benefit from knowing each other then get out of the way, expecting nothing in return. Do this consistently and authentically and people will find ways to give you money. I promise.
7. No one cares about your quota, your payroll, your opex, your burn rate, etc. No one. They care about the problem you are solving for them.
There is more than 100 trillion dollars in the global economy just waiting for you to breathe it in. Good luck.
Hmm... that aligns somewhat with my own thoughts on the actual cause of depression. I've spent a lot of time thinking about since I spent a significant portion of my life depressed, and I find the current approach to it in health care unsettling.
Allow me, if you will, to engage in some inexpert speculation. If you read the following, please keep in mind that I am just some idiot on the internet and not in any way qualified to give advice.
It seems to me that depression is not a disorder, disease, or abnormality, but a necessary and purposeful reaction of the mind and brain to certain stimuli. Of course this is not always the case, and the same symptoms can be triggered by other factors that affect our neurochemistry or mental function, but in a normally functioning mind and brain I think this is true. When examined in this context, what do we find?
Depression makes us apathetic, reluctant to act, and unconfident. A while back there was an article on HN spitballing that depression and mania were related to our mind's assessment of its own ability to predict outcomes. Overconfidence in its own predictive ability manifests as mania, and low confidence manifests as depression. This makes some sense. If you are confident in your predictions you are more likely to act on them, and if you are not you are less likely to. Given this, I submit that it's possible that what depression really is, much of the time, is a philosophical problem.
Philosophy is our model of reality, and we use that model to make predictions and decide how to act in the world to affect change. When that model is known to be broken, we lower our confidence in it and act less. Over time, as more and more of our model is revealed as flawed and our confidence in it continues to plummet, we enter a state of learned helplessness. Finding ourselves unable to predict the results of our actions, we are unable to determine how to effect the changes we desire in our lives, leading to interesting contradictions like being bored and at the same time unmotivated to do things we used to enjoy. We don't want to be in this state, but we lack the ability to see a path out of it, so we become frustrated, angry, and/or sad. It can eventually reach a point where the only path out of the suffering that we're confident in, is death.
In fact, this model-breaking occurs many times in our minds' development. As we grow up we form several different models of reality, all of which are inevitably revealed to be flawed. This is the reason you find children who believe they are hidden just because they can't see you (their model of reality doesn't include the concept of different perspectives), and why the terrible twos are so terrible (the young mind is dealing with its model of reality failing), for instance. With children, however, there are plenty of people around them operating with better models of reality to help them work out a new one. Societies can also be modeled this way, and if we look at the past we find that human cultures also go through a similar pattern of forming a stable model of reality, eventually finding it flawed, suffering through process of dealing with that, and ultimately resolving the crisis. I say resolving because, in actuality, there are two solutions to the problem of realizing your model is broken: forming a new, more accurate, one; or ignoring the information that contradicts it.
This is the important point, I think: When an individual's model of reality is broken, and society cannot guide them towards a more accurate one because society itself is still operating on the model that individual has determined to be flawed, then chronic depression is a likely result. Our current societal philosophy, the one our health care system is also based on, see's this individual's suffering not as a transition period in which they form a new model, but a severe disorder. To them, the rejection of the model is a form of insanity, and unclear thinking. This is why you sometimes see people tell a depressed person an obvious platitude in an attempt to cheer them up, only for it to further frustrate the depressed individual: they are aware that the platitude is part of a flawed model.
Further, the health care system is, like most of current western society, firmly implanted in empiricism. Science and measurement are the hammer, and everything else is a nail. Society as a whole forms its model of depression on measurements and manipulation of the neurochemical and behavioral aspects of depression, the social side effects, etc, but without regard for its greater reason for being. They are witchdoctors, sacrificing chickens to drive out the demons and bloodletting to balance the humors. Sometimes it works, because even a broken clock is right twice a day, but a lot of times it doesn't.
If one were to assume that this assessment is accurate, then reason we get depressed is so that our mind is motivated to take a step back and build a more accurate model of reality. The thing to do, then, is to help the sufferer realize why they are suffering. There's nothing wrong with them, they don't have a chemical imbalance of the humors, they aren't bad people for feeling the way they do or for not having faith in what society tells them is true. They have in fact taken a step toward growth, and nearly all growth comes at the cost of suffering. They need to look hard at where reality has shone the light on their flawed conception of it, reason through the problems, and build a more accurate replacement, and we may not be equipped to help them.
We've been working on migrating from Oracle to Postgres for a few years now. We are about 2 weeks from being finished. It is not for the faint of heart, but it is totally worth it. The documentation is much much better, performance is equivalent or better, the sql dialect is saner, etc. Other than moving the data itself (ora2pg was invaluable for this), rewriting the queries is what has taken the most amount of time. Some of our tips on differences between oracle and postgres sql:
replace nvl with coalesce
replace rownum <= 1 with LIMIT 1
replace listagg with string_agg
replace recursive hierarchy (start with/connect by/prior) with recursive
replace minus with except
replace SYSDATE with CURRENT_TIMESTAMP
replace trunc(sysdate) with CURRENT_DATE
replace trunc(datelastupdated) with DATE(datelastupduted) or datelastupdated::date
replace artificial date sentinels/fenceposts like to_date(’01 Jan 1900’) with '-infinity'::date
remove dual table references (not needed in postgres)
replace decode with case statements
replace unique with distinct
replace to_number with ::integer
replace mod with % operator
replace merge into with INSERT ... ON CONFLICT… DO UPDATE/NOTHING
change the default of any table using sys_guid() as a default to gen_random_uuid()
oracle pivot and unpivot do not work in postgres - use unnest
ORDER BY NLSSORT(english, 'NLS_SORT=generic_m') becomes ORDER BY gin(insensitive_query(english) gin_trgm_ops)
Oracle: uses IS NULL to check for empty string; in postgres, empty string and null are different
If a varchar/text column has a unique index a check needs to be made to make sure empty strings are changed to nulls before adding or updating the column.
PostgreSQL requires a sub-SELECT surrounded by parentheses, and an alias must be provided for it. - SELECT * FROM ( ) A
any functions in the order by clause must be moved to the select statement (e.g. order by lower(column_name))
Any sort of numeric/integer/bigint/etc. inside of a IN statement must not be a string (including 'null' - don't bother trying to use null="" it won't
work).
Concatenating a NULL with a NOT NULL will result in a NULL.
Pay attention to any left joins. If a column from a left join is used in a where or select clause it might be null.
For sequences, instead of .nextval use nextval('')
Dependencies (coupling) is an important concern to address, but it's only 1 of 4 criteria that I consider and it's not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code.
The reason I put stateless code as the highest priority is it's the easiest to reason about. Stateless logic functions the same whether run normally, in parallel or distributed. It's the easiest to test, since it requires very little setup code. And it's the easiest to scale up, since you just run another copy of it. Once you introduce state, your life gets significantly harder.
I think the reason that novice programmers optimize around code reduction is that it's the easiest of the 4 to spot. The other 3 are much more subtle and subjective and so will require greater experience to spot. But learning those priorities, in that order, has made me a significantly better developer.
(3) As you work for clients, keep a sharp eye for opportunities to build "specialty practices". If you get to work on a project involving Mongodb, spend some extra time and effort to get Mongodb under your belt. If you get a project for a law firm, spend some extra time thinking about how to develop applications that deal with contracts or boilerplates or PDF generation or document management.
(4) Raise your rates.
(5) Start refusing hourly-rate projects. Your new minimum billable increment is a day.
(6) Take end-to-end responsibility for the business objectives of whatever you build. This sounds fuzzy, like, "be able to talk in a board room", but it isn't! It's mechanically simple and you can do it immediately: Stop counting hours and days. Stop pushing back when your client changes scope. Your remedy for clients who abuse your flexibility with regards to scope is "stop working with that client". Some of your best clients will be abusive and you won't have that remedy. Oh well! Note: you are now a consultant.
(7) Hire one person at a reasonable salary. You are now responsible for their payroll and benefits. If you don't book enough work to pay both your take-home and their salary, you don't eat. In return: they don't get an automatic percentage of all the revenue of the company, nor does their salary automatically scale with your bill rate.
(8) You are now "senior" or "principal". Raise your rates.
(9) Generalize out from your specialties: Mongodb -> NoSQL -> highly scalable backends. Document management -> secure contract management.
(10) Raise your rates.
(11) You are now a top-tier consulting group compared to most of the market. Market yourself as such. Also: your rates are too low by probably about 40-60%.
Try to get it through your head: people who can simultaneously (a) crank out code (or arrange to have code cranked out) and (b) take responsibility for the business outcome of the problems that code is supposed to solve --- people who can speak both tech and biz --- are exceptionally rare. They shouldn't be; the language of business is mostly just elementary customer service, of the kind taught to entry level clerks at Nordstrom's. But they are, so if you can do that, raise your rates.
A sentiment among members of a former team was that automated tests meant you didn't need to write understandable code - let the tests do the thinking for you.
This, and stuff like your story, are why I don't trust people who promote test-driven development as the best way to write clean APIs.
A short list (but by no means anywhere near complete!):
- Find as many blogs in your niche as possible. Pitch them properly (a lot could be written on that point alone) DON'T JUST GO FOR THE BIG ONES! The smaller blogs are more likely to link to you if you're friendly to them and develop rapport.. I run blogs with over 10,000 subscribers and I love helping people who are FRIENDLY and GENUINE.
- Use your social network.. you've been building one up, right? Make sure all your Twitter and Facebook followers know about what you're doing. Lean on your Linked In contacts.
- Stumbleupon advertising (if appropriate, 5 cents a visitor). Adwords advertising (if appropriate).
- Find places where users of competing applications gather (forums, Google Groups, etc) and work your way into their attention zone.
- See if there's a sub-Reddit that's specifically for your niche. Find people to charm there, post ancillary links regarding your app, etc. Don't over-do it.
- Post it on HR (as someone said above)
- Find your way in to interviews, podcasts, etc. A lot of content providers are dying for more content - you might make a great interviewee. The media is less opaque than it seems.
- Go to events! Make sure you have an elevator pitch. Get excited. Wear schwag featuring your logo, etc, if you want to. Don't just focus on the big-wigs - get anyone who might find your service useful excited.
- Does your design rock? Get on to the "CSS design", and "Web design" show case type sites. There are hundreds of them around. Not amazing exposure, but the more links the better and any one of your visitors might turn in to a serious contact.
- Start your own blog for your company / startup. Make it really interesting. Be candid. Show off new features. Show off stuff you're working on. Show off your team or your technology. Build up your own tribe of followers. They will make all the difference when it comes to saving you on del.icio.us, Digg, Reddit, and so forth.
- Make sure you stay on top of your e-mail. Customers might test you with e-mails - responding quickly and completely can make the difference between sales and no sales - or life and death with a startup.
- Find ancillary reasons to get your service mentioned in blog posts and tutorials. For example, if your startup is an RSS mashup generator of some sort, you need to have tutorials out there that recommend your service. Get those tutorials and posts on to Reddit, Hacker News, Digg, etc.
- If people write about your site, write tutorials that mention you, etc, PROMOTE THAT CONTENT EVEN IF IT'S NOT YOURS! Get people reading stuff that's about you - not by you!
- Remember that bigger sites like TechCrunch and ReadWriteWeb (if applicable to your sector) love exclusives. Don't bother mass pitching those - focus on one, whichever you can get best rapport with, and offer an exclusive. Your product needs to be AWESOME for this to work though.
- Follow a search.twitter.com search on terms related to your service (and even the name of your service) .. get in touch with people who might be interested, respond to all comments about your service.
- Write a bog standard press release and submit through the standard channels. This will not help much but at least your company name/service name will end up with a ton of results in Google - this can help you look bigger than you are. You /may/ even get some offline coverage if the press release is actually kinda good (but not too crazy). It's cheap to do this.
- Build ancillary "fun" services that tie into your main web app. Something fun, free, perhaps something that you can relate to sites people find interesting, such as Twitter. Let's say your main service is an online graphics editor. Perhaps you could create a separate site where people can create avatars for Twitter / Facebook from a small set of templates.. separate project but promoting the first.
- Hustle, hustle, hustle! Make sure you know as soon as someone blogs about your service. Follow Google Blog Searches, etc. Keep Googling. Get commenting on blogs (not in a spammy way - just get your name and service out there). If someone needs to do something your service offers, you need to be there!
I believe Jason Calacanis wrote an interesting piece on doing PR for a startup recently. Find that article and read it - I recall it was very good.
..
BTW, if anyone thinks I might be able to turn this into a good book, resource site, or similar, vote this up and I might give it a try! :)