“Copperr” – My API-Wrapper R Package for Copper™ CRM

copperr is an R package that connects to the Copper™ CRM Platform APIs using tidy principles. The package implements most key actions from their REST API described on Copper’s developer portal here. The package includes what you’d expect to see in an API wrapper:

  • Basic (Username/API-key) Authentication methods, and caching for API details
  • CRUD (Create, Retrieve, Update, Delete) methods for records
  • Query a set of records
  • Retrieve metadata Resources (Custom Fields, Sources, Pipeline Stages, etc.)
  • Retrieve User profiles
  • Helper functions to simplify some common record lookups and manipulations

You can download the package and read the “Getting Started” guide on Github here

I’ll probably provide some examples of the kind of sales data analysis and data cleansing I am using this package for in subsequent posts. Leave a comment if you’re interested in this?

A Comparison of Programming Languages I’ve Used

Comparing programming languages has been a popular sport for many years.

I love the quote from Antoine de Saint-Exupery who once said “If you want to build a ship, don’t tell people to collect wood, or assign them tasks, but rather teach them to long for the endless immensity of the sea“. 

So let’s see how each of the dozen-or-so programming languages I’ve used over the last few decades support that epic vision of empowerment: Continue reading

Starting a Negotiation? Got your BAFO and BATNA in your Pocket?

This subject came up again recently when a mate’s startup was raising fresh capital. I advised him be prepared in case the VCs you’re negotiating with lead you into a take-it-or-leave-it situation, knowing you’ll be under time pressure as your cash runs out. 


The BAFO is a commonly-used acronym for your Best And Final Offer – a.k.a. your “Bottom Line”. What is the worst deal you will still accept? 

The value of deciding this ahead of every negotiation comes from taking emotion out of this decision. In a negotiation situation, there are any number of pressures, expectations, fears, and cognitive flaws that can lead you to accept a deal you will regret in the cold light of day. This is why auctions exist. 

BAFO sounds trivially simple, but you may find it harder than it seems. You may have to push yourself to decide on this in advance. I find people are often reluctant to even discuss, let alone choose, a BAFO. They’d of course prefer to be positive, to imagine the best possible outcome, and the probabilities of getting that, than face the buzz-kill of looking at worst-case scenarios. Whichever of these routes you take, just make sure its a conscious choice.


Your BATNA is a less well-known term, but one of my favourite concepts. It’s your Best Alternative To a Negotiated Agreement. It’s a more positive way to frame a “fall-back” option, and can remove a lot of pressure going into any negotiation.

What options are open to you if this deal doesn’t get made? What are the potential upsides of not getting this deal? 

  • Would not signing this deal free you up to concentrate on winning more profitable deals? 
  • Are there alternative uses for the resources this deal would consume?
  • Would not being tied to the commitments you’ve offered to make give you more flexibility ahead?
  • Could not getting this job open you up to exploring alternative opportunities elsewhere?

Your BATNA should be an option with no external dependencies, such that it is entirely within your control to choose it.

Your BATNA is your most valuable tool to control the cognitive bias that is equating not reaching a mutually-acceptable deal with “losing”. The bias pushing you to forget your BAFO and take any deal you can get, or to choose between two unpalatable offers. 

Get comfortable with your BATNA, visualize life with it, until you can say to yourself: “I know that whether this deal comes off or not, I’ll be OK.”

If nothing else, walking away sends a signal to your sales team internally and to partners or customers externally that you may be flexible but you do have a bottom line and you’re happy to say no to a deal that doesn’t work for your business. 

In that example at the beginning where my mate was raising capital, his BATNA could be to keep his equity, cut costs and finance growth out of sales – growing organically.

How to Interview Sales Reps – Building your bullshit Filter

In case you’re reading this because you’re hiring for sales, and your idea of a great salesman is DJ Trump, then stop reading here. I got nothing for you. 

“WTF? The dude’s clearly a genius salesman – he sold the whole country the idea that he’s who they need!” 

Exactly. The only commodity Trump has ever been able to sell – himself. He is exactly the rooster you’re trying to weed out of your interview process. 

Bear with me…

Continue reading

Cut the bullshit – Sales unmasked for Tech Founders, Engineers and other Rationalists

You’re an engineer. Selling is alien to you, right? It’s the dark side. It certainly sounds like black magic when sales managers talk about it. Better hire someone who knows how to do it.

Look, it’s really not. You can do it, even if you don’t want to. And you can also manage a sales team.

Continue reading

B2B SaaS Sales in a Nutshell : a Startup-sized Framework to cut out and keep

A Startup founder asked me today “Can you help me put some structure around our sales process, but I’m also wondering – do we even need one? since we’re intending selling through channel partners”
Um.. the answer to each of those questions could fill a book. And for that matter does fill several hundred. How long have you got?

Anyway, I thought I’d write down how I really answered, in case it’s of use for anyone else. I basically sketched out for him the key elements of a lightweight framework for a scalable B2B sales model for any SaaS startup based in a location remote from its target markets. Continue reading

A Node.JS Application on Amazon Cloud. Part 4: Launching your webserver

And finally, launch your webserver for continuous operation

When you’re ready to launch your webserver and leave it running, you need to start it as a background process.

If you don’t, then when you logout or close your SSH session, you inadvertently kill your webserver because you ran it in the foreground – ie as a child of your SSH process. To avoid this behaviour you could of course simply run the server in the background by appending & to your bash command:

node server.js &

However, the node server may still die when you close your SSH session, because even though the node process is running in the background, it’s standard console outputs stdout and stderr are still pointed at the terminal. That means that if the node server tries to write a message to console.log or console.error it will encounter a  pipe error and terminate. This can be avoided by piping the output of your process to logfiles:

node server.js > stdout.log 2> stderr.log &

You will also want to log in later and review the contents of the logfiles to diagnose any problems you may get using your API.

If you still get problems then you can try standard commands like nohup, which can be used to run all types of processes  in the background.

Or try this solution developed specifically for Node, which has a number of advantages :

First, install the forever node package using npm:

sudo npm install -g forever

And then start your application:

forever server.js


forever start server.js

You don’t need to pipe stdout and stderr to files now, forever itself writes any output to these streams to log files.

you can define the log file location and names using the -o and -e command line arguments, or just use the default. To find the location of the log files forever has created, use the command

forever logs

An added benefit of using forever is that forever can automatically restart your app when it crashes or stops for any reason. To restrict the number of restarts to, say, 10 you could use:

forever -m10 server.js

forever has a number of other useful commands, such as :

To list all running processes:

forever list

Then, to stop a process, take a note of the process id number within the brackets and use it as following command:

forever stop 0

Restarting a running process goes:

forever restart 0

If you’re working on your application file, you can use the -w parameter to restart automatically whenever your server.js file changes:

forever -w server.js

Back to Part 1

My Dev Env – remote access to a Raspberry Pi

You have three UI options for logging into your Raspberry Pi:
1. The “standard” way: connect a USB keyboard and HDMI monitor directly to the Pi.
2. connect a PC or Mac to the Pi by plugging a USB-to-serial console cable like the Adafruit 954 into the Pi’s GPIO header, and use the Terminal app on your laptop to connect and login to the Pi as described here.
3. connect your Pi to your local network and then use the SSH app on your Mac to open a remote session on the Pi as described here.
I  use all three methods, and each has its benefits in different situations.
Once I’ve initially setup my Pi for networking using option 1 or 2, I find the third option – connecting via LAN – most flexible, since it doesn’t require the Pi to be tethered to my Mac or any other equipment. I can power up the Pi on my workbench, and as soon as it’s connected itself to the WiFi, I can SSH into it from anywhere in the house. Or even over the Internet if I open a port in my router for the purpose.

Continue reading