07 Apr 2017
In 2008, I was still in college. I had just landed my first job with a small consultancy as their first iOS developer replacing their outsourced Ukrainian team. Within my first week on the job, the CEO asked me to jump on a sales call as the technical lead. This absolutely terrified me. I remember doing things like ensuring that I had a full glass of water so my throat wouldn’t get so dry (it still did). I also stumbled over my words, almost costing the team many sales. Eventually, I learned.
Since that day, I have taken hundreds of software sales calls. Each time trying to improve my process by testing out what works and what doesn’t. Now that I run my own company, I have found that one of the most beneficial things that I have done is implemented a standard call flow.
There is a reason that call centers require their employees to memorize call flows. When you have a call flow in place, it does a few things.
1. It allows you to practice and refine your pitch over and over again.
Practice makes perfect. Definitely cliche, but it makes a lot of sense here. As you give your pitch over and over again, you will start to pair it down to something that works for you and your team.
2. It builds confidence
Many people are nervous speaking to strangers. Software developers are no exception to this. As I mentioned above, I was terrified on my first few sales calls. This had a lot to do with the fact that I was ‘shooting from the hip’ and just trying to make things up as I went along.
Once I finally got a script in place, I was able to lean on it during future calls. This gave me the confidence that I was gathering all of the right information and representing myself in the best way possible.
Now when someone says “Could I see an example of your work?”, I can quickly shoot them a link or list rather than nervously trying to get the words out “well…uh…I made an app about catz, and I’ll find the link and…uhhh… send it to you later…”.
3. It’s so easy a ‘sales guy’ can do it
This is the part that I’m starting to experiment with. I want my pitch for my company to be so tight, that I could give it to any ‘sales guy’ to deliver and him represent Pixegon in much the same way I would. I have already done this with some of my engineers as I don’t always have time to make every single sales call and it has proven to be a huge success.
4. It removes emotion
This is a big one. When we are nervous, we tend to say dumb things. I remember a few times on sales calls when I was nervous (often because I really wanted/needed the contract), that I would seriously compromise on my rate just because the client suggested it. Had I had a call flow in font of me, I would have been better prepared to field such a request.
I now replace emotion with process and it usually ends up better for both parties.
Here is a rough outline of my sample call flow:
- Client Introduction - Ask the client about their background
- How did you find us? Good to find out what advertising channels are working
- Give my background - This is to establish credentials so they trust me
- Ask the client to give a 10,000’ overview of the project - Be careful here, they love to get in the weeds
- The 3 most important questions
- What’s your budget? This will let you know right away if you want to continue much further based on your budget tolerance and rough guess on how much the above will cost.
- What’s your timeline? Every single client will say ASAP. But really this is to find out if there are any conferences, holidays, etc… that are hard deadlines for them
- How are you funding this project? Self, Company, VC, Family, Startup, etc… This will also help you assess risk.
- Ask more detailed questions about the project (If timeline / budget are somewhat ok). Determine things like backend requirements, UI/UX, Staff aug vs full solution, etc…
- Don’t give them a $$$ estimate. They will usually ask you and it will usually cost you in the end if you give them a number here.
- If all goes well, ask them to send over any assets/wires/requirements and tell them you will follow up with a rough scope and estimate. Again, don’t estimate on this call
- Thank them for their time and let them know you will be in touch.
This is definitely a good starting point. Sometimes I will copy and paste these flows into a new document and tailor them based on the client that I am about to speak to.
Sales is something that I am constantly working on and refining. I hope to continue to share my findings with you as I learn along the way.
06 Mar 2017
As developers, we hear the echo chamber on Hacker News and others shouting at us to raise our rates. We are worth it. In theory they are right, we are worth it and we should be charging an industry standard rate. However, there are some instances when it’s OK to lower your rates.
Here are 3 times when you should consider lowering your rates:
1. Building Your Portfolio
This is definitely the case when you are first starting out. If you don’t have a solid portfolio, why should a client trust you to build their project at full rate. You have no credibility and they would be better off using a large shop that charges the same rate, but has hundreds of apps under their belts.
Even if you are not just starting out, this can be a great strategy to employ if you are wanting to land a client that will “look good” in your portfolio. We have done this in the past when we have wanted to break into certain markets. We found some of the leaders in those markets, given them a killer deal (or built small projects for them) so that we were able to put their logo on our website.
This strategy has proven to be incredibly successful for Pixegon
2. Longer Term Engagements
Our overall goal is to make money and provide sustainability as indie software developers. If you get an opportunity for a longer engagement on a project you enjoy working on, this often times can be much more valuable than trying to get your full rate.
3 month gig at $125/hour VS 6 month gig at $100/hour
- 3 months * 172 hours * $125 = $64,500
- 6 months * 172 hours * $100 = $103,200
In my opinion, I would MUCH rather be working on a larger contract at a lower price than a shorter one at a higher price. At the end of the day, it’s all about the contract value and sustainabilty.
3. On The Job Training
As students of computer science, we should be able to build anything right? Well, sort of. In the past, there have been instances when clients have asked me to work in unfamiliar territory. Whether that is using a programming language I have never written in, or working in a field that I don’t know much about.
Rather than just declining these types of contracts and pigeon holing yourself into one area of practice, try giving the client a discount while you come up to speed. This benefits both you and the client. You, get on the job paid training to learn new concepts and expand your area of expertise, and the client gets their product built for a significantly lower cost.
Rates are a weird thing. I would encourage you to constantly experiment. Raise them, lower them, exchange some for equity. Find out what works for you and your clients.
06 Feb 2017
Over at Pixegon, I really try to encourage my developers to have their own side projects. Often times, employers look at side projects as competition and try to own the works that their developers produce. Some will even go as far as to include this in their employee handbooks.
In my opinion, this stifles creativity and creates a feeling of contention between the employee and company.
People start side projects all of the time for a variety of reasons:
- To make some extra cash
- To learn a new technology
- To sharpen one’s skills
- Just for fun
From an employer’s standpoint, these are all great. It allows my developers the freedom to learn new things, make mistakes, and even earn extra cash. All without me fronting the cost.
While this might now sound selfish, it’s obviously a two-way street. Developers greatly benefit from this type of arrangement.
Getting started with a side project
This is one I struggle with all of the time. Sometimes it’s a motivation issue, sometimes I lack an idea, and sometimes I’m just feeling lazy and end up reading Hacker News instead due to my analysis paralysis.
The best bet is to just start. Whether your idea is big or small, stupid or world changing, just start writing some code. I try to utilize this tactic in all areas of my life from code, to writing, to working out, to minimizing, and even saving money. Once you get some momentum going, you will quickly find out what’s working and what’s not.
Here are a few Hacker News Posts that I found particularly inspiring to get you started:
Dont’ have any idea to start on? Try cloning something in one of the above posts. There are tons of ideas in here large and small and there’s plenty of room on the web for variances of differenct products. I probably stole most of this post from somewhere…
If you found this post helpful and want to hear more, make sure to subscribe to my newsletter. It’s not spammy, just let’s you know when I post.
02 Jan 2017
Every single year since the beginning of time (at least since the beginning of this blog), I have resolved to “blog more”. And every single year, I have absolutely failed at that.
So, in favor of systems over resolutions, I am attempting to do something different this year. Over the holiday, I blogged 12 posts related to my experiences as an independent software developer as well as business owner that I feel could benefit the community. These share everything from selling contracts to hiring friends, mistakes made, and more.
I plan on releasing one post a month on the first Monday of every month. Given that I already have these posts written, it should be a no-brainer to blog consistently. I also intend on writing in-between posts, but at this point that’s probably wishful thinking.
If you have any interest in this sort of thing (software development consulting), then be sure to add yourself to the mailing list.
Wishing you a successful and exciting 2017.
11 Apr 2016
A while back, I made a flagrant comment on Twitter about how I assumed the world worked. It was something to the effect of “The internet levels the playing field, so someone without a job is without excuse”. Not shortly after I hit “Tweet”, did I receive an array of Tweets back from people I highly respected. I was immediately humbled, and it was pointed out to me that I had a severe lack of empathy.
I’m sure I was just lamenting from a previous encounter with someone who I felt was acting entitled and felt they deserved something unearned. We tend to take situational experiences and generalize them. I’d imagine this is how stereotypes are formed. But this conversation really opened my eyes to something I had never thought about before: empathy.
the ability to understand and share the feelings of another.
As software developers, it is our job to see things from other people’s perspectives. Without practicing empathy, we end up wasting our time trying to solve problems that don’t really exist. We also miss huge niches/opportunities simply because a problem that needs solving doesn’t relate to us.
So, how can you practice and develop empathy?
First, start by listening, a lot. You can’t expect to understand another person’s perspective without fully hearing what that is. In relation to this, you need to set aside your own viewpoint or opinion. Simply, hear the other person’s point of view without judgement.
Second, go outside of your comfort zone. Spend some time with people you might not normally encounter. These could be people with opposing politics/religion/world views/etc… Another good place to start is with people who are in need. I have learned many valuable lessons from visiting soup kitchens, elderly care facilities, and mission trips to impoverished countries.
Finally, attempt to understand the needs of the people around you whether you’re in the coffee shop, grocery store, or the office. There is always opportunity to learn and to grow if you are simply mindful.
Practicing empathy on a day to day basis will not only allow you to see and solve problems others don’t, it will also make you a better human.