I type this sitting in Kramers Books (formerly KramerBooks) in Dupont Circle, Washington DC.
Kramers Books is a funny place: part independent bookstore, part upscale restaurant, part cafe, and part.... barbershop?
The store is famous for its David-vs-Goliath court battle against Kenneth Star during the Monica Lewinsky trials (Kenneth Star wanted Lewinksy’s reading list and Kramers said “no”).
Anyway, it’s a fine place to work and eavesdrop on beltway journalists. And I feel very safe should Kenneth Star come after me and my literature.
But don’t let the laid-back idea of a local bookstore fool you. In my last post, I wrote about the joy of early-stage meandering. Boy, did I not see how quickly that would end.
Almost immediately after clicking “publish” on my last post, several pokers — which I had pushed into what I was sure was wet mud — miraculously nudged a flame into existence. Well, 2 little flames. Both in the form of consulting projects.
In this post, I’ll tell you why consulting is not a detour so much as an on-ramp for a software-minded founder, and how I found my first consulting projects.
To set the table: I am not new to consulting. I worked at a consulting firm before joining Silver Lake, performed consulting-like work at Silver Lake, and since March I’ve worked on 6 small consulting projects (all were in-bound requests, I didn’t fight for them, and they aren’t the focus of this post).
But this past month was the first time I’ve worked as a contract consultant on a large project, and its also the first time I’ve secured a project in the problem space I’m chasing: ultra-remote teams (likely starting in late July / August).
It’s probably obvious why a founder would benefit from consulting in the “problem space” they are trying to build a product. Here are my reasons:
Product research: Solving a problem the non-software way is a great way to figure out where you (and your client) are experiencing pain and frustration.
Domain expertise/credibility: Consulting helps you develop a rich and deep perspective on your problem space. It’s also easy to leverage the experience for content marketing (e.g. webinars or white papers) as well as “grey hair” gravitas in pitches to investors or customers.
Referencability: A few happy consulting customers can help convince a software customer to take a chance on you (“this guy knows his stuff, shoots a straight arrow, and if he says he’s going to knock your socks off with service, he will”).
Prototype implementation opportunities: At the end of consulting projects, you should have the right relationships to broker a conversation about beta-testing or even paying for a rough prototype. These conversations take months to curate without a pre-existing relationship and are frequently impossible to “cold sell” out of the gate.
Lower barrier to entry than software implementation: You can price the project for pennies, scope it for a few days rather than months, and derisk the whole shebang for your customer. Ripping out technology is hard. Ripping out a consultant is as easy as sending an email.
Cash flow: Consulting projects pay in USD, not “user engagement.” You don’t need to raise money to run a profitable consulting project. Consulting projects can pay 2-4X the rate of the parallel full-time job. Of course, you earn less gross because you aren’t working 52 weeks/yr. But that’s a feature, not a bug: your main focus should be product development anyway.
Why might you want to do a consulting project outside your problem space? Here were my reasons:
Consulting platform credibility: Some consulting projects are won on platforms with credibility metrics (Catalant, Upwork, etc.). Getting a few under your belt can increase your likelihood of winning the “right” projects (i.e. the ones in your problem space) down the road.
Being-your-own-Partner experience: Winning and managing consulting projects is a different skill than building frameworks, market models, conjoint analyses, interview guides, surveys, and slides, that is: different from all the skills a good associate masters in a hierarchical, structured firm like Bain, BCG, or McKinsey. Like anything else, takes reps to get good.
Cash flow. See above.
In terms of how to win a consulting project, in my experience there are 4 basic steps:
Arranging an introductory meeting: Getting an intro meeting with a decision-maker is critical if there isn’t an RFP. For me, this required a combination of cold outreach through LinkedIn, mentorship development meetings through the University of Chicago’s Polsky Center, and warm outreach to people in my network. Referrals are key. “Do you know anyone else who is grappling with this same issue?” should be the last question of every conversation.
Introductory meeting: 30-45 minutes of pure fact finding. It’s not an interrogation; you can flash small glimmers of expertise. But, for the most part, you should listen deeply and take great notes. Your goal is to discover the unique contours of your potential client’s problem. Even within a single problem space, there are huge variations. Remember that businesses don’t make decisions, people do. And so you also need to figure out what the individual’s incentives and constraints are, their traumas and memories, and the relationships they have with other stakeholders.
Proposal submission: Sometimes, you have an introductory meeting and the answer is a resounding: “we do not need or want your help.” Listen when you hear this; do not invest further work. On the other hand, if there is an opening/opportunity, I found that the cover-letter style proposal worked quite well. Here is one example of an initial proposal document for an engineering firm in Colorado. Tight but clear.
Back and forth: After sending a few proposals, you will experience a tsunami of rejection/ghosting — sometimes you aren’t the right person, but more often, your timing is just off and no project is going to happen at all. By way of example, of the 25-30 proposals I created and submitted over the past few months, ~10 have been officially rejected and over half were “we decided not to pursue any project” type of rejections. That said, when a proposal isn’t rejected, you will often be asked to modify the proposal, provide more information, etc. Here is an example of a follow-up proposal I wrote upon request for a software company in San Francisco.
One thing to keep in mind: selling a consulting project takes a long time. The project likely to kick off in July/August was — poetically — my very first proposal, and a Valentines Day one too:
February 14th: Initial outreach email
February 25th: Introductory meeting
March 9th: Initial proposal submitted
March 23rd: Follow up to confirm the proposal has been received/read
April 8th: Second meeting, scope refined, presentation to CFO requested
April 18th: CFO presentation delivered
May 9th: Client confirms interest in Phase 1 project to kick off in Q3
June 9th: Third meeting, scope and timing refined, NDA signed, kickoff penciled in for late July
So it’s a long game, and one that requires some level of equanimity and stoicism. But the rewards are significant, and — for now — the right puzzle piece as I continue to scramble through prototypes and product development.
If you are considering freelance consulting yourself, check out Kramers Books!
Just kidding: feel free to reach out to me. Always happy to chat in more grotesque detail, and cheer you on.
More to come!