“How much email do you send?” “We have a newsletter.” “What else?” “Welcome to free trial email. “What else?” “Nothing.”
I write proposal.
You should:
1) Have a pre-sales drip campaign positioned as a “free course about X delivered over email” w/ 8 emails arriving over the course of a month. This will push people at purchasing the product in 2 of the emails.
2) You should email people 4 times during the trial depending on their level of engagement with it. Here’s a decision tree.
3) You should email people within 80% of their monthly quota offering a discount to move to the next higher plan.
4) You should email your entire userbase and upgrade as many as possible to annual billing for a 10% discount to the cost of their current plan.
You can tell your engineering team to do this for you, but there is 0% chance they schedule this because it is boring scutwork and they’d rather do those features you have scheduled this quarter. Or you can have me just do it. I need a commit bit and probably two weeks. It will cost you $30k per week.
Probabalistically this makes you $2 million in next 12 months but your results are your results; you keep all the upside and my invoice is due regardless.
Businesses, to a first approximation, don’t care about their tech stack except to the extent that it drives business outcomes. Can you articulate those pros/cons in a way a business cares about? Can you impact your deliverables to reduced costs or (much better) increased revenue? Then you, too, can look forward to a bright future where HN tells you you’re not really an engineer anymore because your rates are too high.
All of the recommendations you gave were related to selling the product, not improving it. That's not a bad thing; it just means it was a marketing consultation.
a) to have a lot of marketing expertise
b) to be known well enough for your marketing expertise that people will take your suggestions as valid
Most tech people have neither one. Hell, most marketing people have neither one, half of the rest on my have b) but are actually incompetent in their recommendations, and only the last little bit have both.
If you want to make the big bucks, you have to do what businesses care about, not what you care about.
For instance, even though the root cause might be high latency, the actual problem is that the high latency is killing your retention.
If the business is sophisticated enough to value technical expertise, often they value it so much that they are willing to hire experts full-time, or they're so small that they can't afford to. So as a technical expert, you end up caught in a weird uncanny valley (in my experience). I think that patio11's advice is, as always, spot on here; the skills needed to become a technical consultant that charges $N/week are way higher than the technical skills needed to become a business consultant at $N/week, for any value of N. That isn't to say that technical skills aren't value, just that it's a tough sell to make, for a number of reasons that patio11, and others, have written at length about.
How do you make sure the company won't just take your advice and hire a guy to do this for 90k/yr instead of letting you work on it for three weeks?
People occasionally took my proposals and productionized them with existing or (much more annoyingly) new staff. Oh well. That’s one reason I charged what I charged; the sales process assumes 1 to 3 “actually nope we decided we don’t need you” per engagement which happens.
However the indisputable fact is that these companies are willing to shell out for this stuff, whether because they think it’s temporary work (cheaper to hire Patrick than an FTE who you then have to keep paying or dispose of) or they’re paying for the top-of-Hill expertise (eg. paying a Big 4 where you get 10 hours of a partner’s time/expertise at 1k/hour and then 300 hours of 23yo grunt labor).
Is it easier to work for a consulting company as an “employee” before venturing out alone?
At first he undercharged, not as a tactic to start consulting but because he didn’t have confidence in what he was selling. I believe he started off at $5,000 and stopped consulting when he was charging $30,000 a week.
But most of his work came from pitching people. Write an email or make a call to a company that seems a good prospect and follow up. If five percent convert you’re doing pretty well. You also get referrals from previous satisfied customers.
As well as that Patrick wrote a lot on his website about what he did and how to do it, which functioned as a proof of competence and lead to some people contacting him to ask him to work for them. Authority, Nathan Barry, is all about this publicising proof of competence tactic.
> You should email people 4 times during the trial depending on their level of engagement with it. Here’s a decision tree.
Do you have a link to an example decision tree for a typical SaaS app?
That’s consulting.
The entire purpose of selling a product is to scale through volume rather than customization.
To me the big divide is how superlinear your revenue:employee ratio is. If it's linear or close to it, then you're a consulting org. You make money based on the hours of work you are able to bill for in one way or another. If it's a "product", but you as the product developer are doing heavy customization, then you've just transitioned from an hourly billing model to something resembling fixed bid, but with a fiction of a product in the mix.
I am in the middle of another marketing consulting gig right now with a SaaS company. I was hired to help them drastically reduce their sales cycle. They sell to enterprise companies and the sales cycle takes forever.
I'm working on a new front-end website for them, with better copy, more testimonials, white papers/case studies, and a live demo of their product. (Today, potential customers have to request a demo--having people be able to see the product for themselves should shave at least a week off the sales cycle.)
I have both a technical background and a marketing background, so I can write both copy and code, though I'm stronger on the marketing side these days.
When I worked with Patrick at WP Engine, I was also lead on deploying a new front-end website, with a better tagline. My most important contribution there, though, was that I came up with the "10 sites for $99" pricing structure, which is a huge component of what made them so successful.
I am also working on a better pricing structure with my current consulting gig.
I spoke more about what I do for SaaS companies in this talk at Microconf: https://vimeo.com/72456666 (Notably, I did this talk, and it was posted here on HN, several months before pg wrote his "Do things that don't scale" blog post.)
Although a lame story, Let's say you are responsible for initiating and managing a new software project in your company with complex bureaucracy and management. You have found that it is highly feasible to work with Agile methodology instead of Waterfall.
But Waterfall has been how the things had always been done, yet you know that the team is ready for Agile and project is an exact type of work that would benefit from some "lean" approaches. Worse still, management won't listen, also because "The Board" won't listen.
What you do is that you go to that well-known, highly-paid consultant, discuss the situation and he basically says, "OK, You are right. Also this and that."
Then in your presentation to the board while pitching Agile, you say, "Agile is the way to go. I asked Patrick Kalzumeus, and he said it was a good idea."
And that's it.
That "credibility" is one of many ways how a business consultant may "add value" to a highly organized company.
1. What's the proposed issue/improvement?
2. What are the recommended options?
3. How much time will it take to get done?
In other words, all you really need to communicate is why we're doing it, and when it will be done.
In my experience, they're not interested in challenges faced in implementation. Keep things simple, and deliver on time, and you'll be speaking the "language which management can understand". That's basically all there is to it.
Your line manager may be interested in a technical issue / improvement and understand its value without further explanation -- for instance, we're using a brute force algorithm that takes exponential time to foo the bar in the Baz module. It's got test coverage and the problem has a known logarithmic solution, so we could rewrite that in a week to be more efficient, and still be confident it's accurate.
Your department head may be willing to consider fixing a problem that affects efficiency or security or expected timelines -- we've identified the likely cause of at least one class of those outage events you've raised concerns about. If you want to fix it immediately, we would have to push back delivery of the Quux feature by a week while we rewrite a portion of the Baz application, but other risks are minimal.
The C-suite is mostly interested in problems/solutions framed as "how does this save us money" or "how does this make us money" -- we intend to invest a week in technical maintenance work that will allow us to save 25% of our monthly hosting costs by scaling back hardware requirements, and reduce the frequency of outage events that we have to pay out for on under our SLAs by 75%. That would cost $10,000 in developer time and delay our product schedule by a small though measurable amount, but I estimate it would save us an average of $48,000/year in costs.
The other piece I've seen is being able to handle "I want Foo by X". It's easy to take on the engineer mindset and say "Sorry, that's not possible. The whizbangs alone would take more than that time!", but what do you do when they simply repeat "I want Foo by X"?. Picture the various Star Trek series where the engineer would say it'd take 5 hours to fix something and the captain retorts "you have 2". It's real.
The skill which really makes me jealous are the folks who are able to read between the lines and get at why they want Foo and why they need it by X. Instead of saying "Sorry, no can do!" they're able to offer Bar instead, and because they understand the deeper motivations of why Foo is being requested they understand why the manager is likely to accept Bar instead of Baz.
This is pretty similar to your C-suite descriptions, now that I reread it. But it's a different spin on it.
One tactic I can suggest (if your manager isn't a totally unreasonable cartoon tyrant) is to simply be explicit about it and ask "can you explain more about why you need Foo?" and then "what's driving the deadline of X?" Understanding the business case is generally necessary - though not always sufficient - for coming up with an alternative solution.
I suspect that part of the gap between people who are and are not good at this is how well apprised they are of the general conditions, initiatives in other departments/teams, and short-term strategic goals of the company.
Some of that is on the person who may or may not put in the effort to remain informed; and some of that is on the company's management that may do a good or a poor job of communicating those things proactively between departments/teams and from senior management down to junior management and line workers.
Depends on the individual, not on the job title. In my experience, managers of any level value information as simply put as possible. If they ask questions, then you answer them, but otherwise just tell them what they need to know.
i.e., "the expensive consultant said it was okay, so don't fire anyone in management, or our technology team, if it goes sideways."
in other words, they're actually helping you do your job because they can compare your recommendation to other companies and teams in the industry and make sure everyone is doing things sanely. in your case, you were smart, and made the right recommendation, so they agreed with you. good job, you're competent, and aren't putting an established company into a risky situation like you would at a startup, which generally does not hire consultants, because they have nothing to lose and everything to gain.
you probably didn't see it that way, i'm guessing.
(More seriously, being unable to trust your employees to give useful feedback is a sign that your culture is a disaster)
I was hired to come in and assess the software that they were developing - they were working with some contractors, some vendors, and a smattering of other people, and wanted to know if their current method was working, how to address some concerns they had, and whether their current vendor was doing a good job.
I discussed it extensively with them, looked over the code and repositories, their current deployment, their backlog, looked at their priorities and basically told them "They seem like they are doing a good job, with the caveat that using contractors and vendors means you will never develop those skills in house, so I would hire at least one competent programmer internally to work with the vendors/contractors you hire, in order to develop that expertise, if you intend to use custom software as a core part of your business on a continuing basis".
This was conveyed via a written report with citations and via a meeting with the C-level executives of the company.
For this review and strategic suggestions they paid me about $1200 for an afternoon's work. That doesn't count time that went into acquiring the gig, scheduling, following up, or billing, just billable hours.
Probably most important is the the company externalizes the decision so there is less internal responsibility.
If a client is uncertain about something and feels risks, you could be contrarian but otherwise no.
I do enterprise software consultancy, which means that those big companies that don't think twice about buying Oracle or Visual Studio Ultimate, hire companies like my employer to come in and develop software for them, instead of having an internal R&D department.
Usually because for those companies software is a by product, something that they need for their real business, the one that they earn money with.
Then you have business consultants, than come in, evaluate the current set of working processes and provide optimization guidelines based on a specific set of targets.
There are other variations.
You're a software consultant working with an enterprise company? Congrats, you're an enterprise software consultant.
I know that places I've worked have had management consultants, who came in, worked with our teams for a few sessions, and wrote us up some recommendations as to how we could better work together.
We also hired DB Performance consultants, who came in and helped us optimize some gnarly queries and do a DB "Double check" to verify that the path we were on was good.
Another time we hired a pricing consultant, who helped us come up with a strategy to change our pricing and avoid pitfalls.
Basically, They are subject matter experts who may come in and actually be on-demand teachers in my experience.
> can be anything from a written recommendation to a turn-key, green field system.
Sometimes, we are there:
- to propose a set of tools or architecture.
- to migrate legacy systems.
- as staff aug (AKA "butts in seats").
- to do green field development.
Usually, it's some combination.
> contractor with some specialized experience that somebody values more highly than software development alone.
At least in our group, we definitely distinguish ourselves as different from contractors. At our core, we can do the contract work (and often do), but we also help out with the business side of things. Basically, we are contractors who know how to interface the technical side of things with the core business.
Oftentimes, we end up at a client who knows they want to build a system to help them do a thing, but that's step 10. They might know steps 1-3, but need our help figuring out and accomplishing steps 4-7 (e.g. defining actual requirements, organizing a good dev team, etc.).
EDIT: formatting.
Employee: Does what the boss says, and works when the boss wants them to work.
Contractor: Does what the client asks them to do, but has the flexibility to do it on their own schedule and according to their own way. In the US, the IRS may want to reclassify you as an employee if you dictate too much of how the work is done.
Consultant: They review what the client is doing and recommends what they should be doing, often performing that work too. The key difference to me is the client accepts they may not be the most knowledgeable in what change they want to make.
To give examples for programmers:
Employee: works on a app in the office from 9-5 adding the features requested.
Contractor: adds requested features to the app.
Consultant: reviews the app and proposes some features to add.
They come in to do a specific job, then leave.
Since I started selling myself as a "Mobile Consultant" I made significantly more money than selling myself as a "Front-End Developer", "Freelance Developer" or such.
Seemingly it's all in the wording these days.
"contractor" is the replacement status for permanent employees. They are outside of normal payroll and company benefits, they usually do 1 to 6 months repeatable contracts.
"consultants" is the experienced people who need to be called by up-the-chain to perform important matters and take critical decisions.
I am not a freelancer because I work for a larger company.
I am not a contractor because, while that is a good chunk of what I do, I provide more than just software development. Oftentimes, I end up working with clients to actually determine what they need and how to build it. Then I help build it. Contractors typically just build it.
Of course, this was different type of consulting than what Patio11 did, but there are a lot of different kind of consultants.
For example: reviewing someone's database configuration and providing general recommendations for improvement is consultation, but so is directly modifying those settings for them and not actually telling them what changed. The expectations and deliverables are set by agreement between the consultant and the consultee.
The top global management consultancy firms are McKinsey, Bain and Boston Consulting Group.
The most important part to realize is that a consultant is a vendor and as such certain policies that the company has may not apply.
For some further research, read up on "process consulting"[1], for example.
True consulting is almost like being a psychologist for an organization. Technology consulting varies, but true technology consultants are not technology specific, they are more like experts in knowing how organizations use systems and technology and assisting organizations with technology selection, architecture, hiring, training, organizational development, change, politics, psychology and/or complex situations that require additional outside expertise or brainpower.
I think a good example where technology and business consulting intersect is data warehouse consulting. If you have or want an enterprise data warehouse, you need likely need dimensional modeling. Dimensional modeling is a technique not a specific technology, many organizations don't have specialists with that knowledge. The best data warehousing consultants I have seen will come in when requested, determine the organizational situation through observation, propose a conceptual solution in concert with the organization, designed to fit the way the organization works, help with training staff on necessary techniques (such as dimensional modeling, if the organization chose to adapt it), and act as an expert for tough questions during implementation and after. Assist the organization with identifying data warehouse technology solution options that fit the need and budget, staff and skills, data migration, etc. as needed and desired by the org.
I think one key difference between a consultant and a contractor is, a consultant is more like an architect/engineer advisor "thinker and recommender", but a contractor is often more like the engineer/builder "thinker and do-er". Both are external experience for hire. Of course you get blends/crossover people who are both.
I also think consulting is more prevalent when there are a smaller pool of people with knowledge and experience that needs to be shared. Scarcity of skill creates demand that requires compensation due to competition for that limited resource.
Skills wise, I think you need a mix of soft skills and specialized knowledge in such an area, combined with the ability to communicate, market, network and run a business. Education -wise, I have a degree in information systems and one in organizational studies. I think combining organizational studies plus any specialty area is a great combination. You can also achieve this through an MBA+specialty area.
* I get on calls with potential clients to see if we can solve one of their needs. Their needs can be broad: auditing code or specific implementations; reading and vetting pages of protocol design; advising on third party products or libraries; documenting the risk of the latest X attack... Sometimes I can do it, sometimes someone else should do it, sometimes no-one can do it.
* If nobody can do it but it's an interesting problem and it's relatively reasonable to tackle I (or someone else) will spend X weeks researching the subject so that we can provide the service in the future. We've done this with ethereum smart contracts recently for example (it's been pretty fruitful and I'll be giving a talk at Black Hat Asia in a few months on the subject).
* When the job starts, I'll be talking to the client to make sure we're on the same page, see what kind of claims they want to make, what they're more scared of, etc... This helps a lot, but of course the client is not always right or not always aware of what might go wrong. Most often companies do not even have a threat model and have no idea what they should really defend against.
* Most of my engagement are remote, but depending on the field you might have to go on-site. In any case, you always try to be close to the client so that you can get responses relatively fast (consulting is expensive, you don't want to lose your time trying to find answers they can provide). (Unfortunately it is not always possible as some of them are really busy or just do not want to spend the time answering questions.)
* Whatever the type of job is, you always spend a few days internalizing everything you're reading or hearing (I call that drowning). You try to get an idea of what the product/protocol/solution/app is (if it's your first time working on it), you read papers or articles about it if you're rusty/missing some pieces, you go through the codebase and ask questions to see what is what and what is where.
* Then you dig in, you do what you're best at. In security/cryptography we try to break things, find gotchas, discover flaws :)
* Eventually, you need to provide some product to the client. It is often some document or a presentation (or both) of your findings. You want your client to understand what you did, like really, this is after all the product they're paying for. You also want to give out recommendations on how they can fix things, sometimes you will want to fix things yourself as well. It all depends on what you can do or what the client wants you to do (if you agree).
Anyway, these are my 2 cents. It's a field that mingles expertise with client satisfaction. You need to know something that can help one or several of their problems, and then you need to do your best to convey your explanations.
(I just wrote this huge comment because I felt inspired after reading a large 2000 day-old tptacek comment.)
If anyone here on HN could share some insights, I would highly appreciate it.