

What Product Companies Can Learn From Consulting Companies - rdudekul
https://training.kalzumeus.com/newsletters/archive/products_vs_services

======
bdunn
_(I loved phrasing this as "You could certainly have your engineering team do
this, if you want to write a $10,000 payroll check with the memo 'Reading free
information on the Internet'.")_

This is probably one of the best arguments for niche specialization that
you'll find. Say you're a Ruby developer, but you know a lot about CPA, ARPU,
LTV, churn, and other terms SaaS types care a lot about.

Yes, you might cost significantly more per week than a peer Ruby developer who
might be employed by a prospective client of yours, but the cost of getting
that employee's knowledge to around where yours is outweighs the difference.

Additionally, clients want to lower the risk that a project will fail (note:
this doesn't mean _technically_ fail, as in the code doesn't work.) By
"leveling up" in a niche specialty, you'll lower the risk that you'll fail
when a project in that niche comes your way. (Clients also have a tendency to
reach deeper into their pockets when the risk of failure is lower.)

~~~
paul_f
Beware that some companies calculate the cost of existing employees at zero.
If someone else is paying the employee, but you come out of their budget. Find
out how the money flows.

~~~
lifeisstillgood
Then you are talking to someone too low down the tree.

The person who signs the cheques as big as you want them to be will be the
person with P&L for employees and contractors Possibly across IT and marketing
or accounts or ...

------
wslh
The general recommendation is to be both following a hybrid approach. Read for
example "Business Models That Last: Balancing Products and Services in
Software and Other Industries (2003)"
[http://ebusiness.mit.edu/research/papers/197_Cusumano_ProdSr...](http://ebusiness.mit.edu/research/papers/197_Cusumano_ProdSrvcsBusMod.pdf)

It can be a little bit outdated but the main points remain the same.

I experienced it first hand: We realized that the "energy" to spend in selling
USD 100K/yr on a specific product is one or two orders of magnitude of selling
a service using/embedding that product. And there are cases where there is a
dilemma and products can eat your service profits.

~~~
patio11
Thanks for that recommendation. I'm going to sit down with that paper and have
time to digest it in detail, since it seems like likely the most relevant-to-
my-interests link I've seen on HN this month.

------
thaumaturgy
Wow. The writing here is concise, and easy to understand. Just a few
paragraphs in I realized I've been doing my consulting wrong (which makes the
hopeful transition to a products & services company even more challenging).

In terms of benefit-per-sentence, this is right up there with the best books
on business I've ever read.

~~~
patio11
Thanks, that is one of the best compliments I've ever gotten for my writing.
(Since I tend to write 4,000 words at a time, my biggest worry is always that
I'm fluffing up one good idea into excessive length. I aspire to always
covering something in enough meaty depth to justify the length, not to have
the length pre-fixed and need to pad to hit my quota.)

~~~
thaumaturgy
The impact of the writing -- the frequency with which I read something and it
made me sit back and go, "hmm" \-- is comparable to Rules for Revolutionaries,
still my favorite book on business.

I don't give out enthusiastic compliments easily.

Seriously, if you enjoy doing this, you might consider turning it into a book.
With your writing style, your domain expertise, and your marketing acumen,
you'd probably make a mint.

------
nodally
Excellent article. I've worked in product companies ranging from startups to
the top 5 over the years, and also spent a few years in consulting
organizations so I can really appreciate the insights here. Product companies
(in general) create cost centres while consulting companies are profit
centers. So the attitude toward cash flow is quite different. Consulting
companies tend to "invest" their money while product companies tend to
"spend". What else, product people tend to take their time to build things
that they feel the customers will need, instead of building exactly what the
customers need. Sense of urgency is a trait that a product company can learn
from the consulting business. Consultants work with customers directly and
they always possess domain knowledge learnt from experience while product
people rely on research to pick up a subset of the knowledge. Imagine the
power of a large product organization that can run more like a consulting
organization!

------
crazygringo
I wish I had something more to say, but this is phenomenally good. It may be
the most genuinely informative and well-written piece I've seen on HN in
months, for the startup crowd.

------
adrianhoward
_" Actually call them and ask how they're doing"_

I'm amazed at the number of product companies that don't do this. Or stop
doing it as soon as they think they've found product/market fit.

If I had to pick between A/B testing and talking to my customers (and it
would, of course, be dumb to pick only one of those options) I'd pick talking
to my customers without hesitation.

A/B testing let's me optimise. Talking let's me discover my customers'
problems.

~~~
rgbrgb
On the other hand, I am incredibly annoyed when hosting companies give me
personal phone calls to ask how I'm doing or tell me about their new service.
There's probably a middleground but I just don't really like talking to
salespeople.

~~~
mgkimsal
Agreed. Rarely has someone called me who _really_ really wanted to know my
experience with something, and nothing more. I think I've had one call like
that in the last year, and even it was sort of a... well, not salesy. I'd
signed up for an Azure test drive. 1 month in someone called to ask what I was
doing with it. Based on what I said, they assigned a support person to me,
sent me that person's info, and said to contact them if I had any support/tech
questions. No sales pitch, no upsell.

Pretty much every other thing I sign up for, if someone calls, it's inevitably
a salesperson who _does not understand the tech behind the tech they 're
selling_, trying to push the latest version of something they don't know.

Please - call me and ask me if I'm using it. If say 'no' \- as in, 'no, I
don't use subversion, and I've not worked in an enterprise situation for 9
years' \- that should be enough to take me off your list. If I say yes, and
have feedback, take it, listen, record it, say 'thanks', and get it to the
right people. If I'm using something, and it sucks, and I tell you it sucks, a
followup from someone telling me you'll make it better would net a customer
for life. No one has yet done that for me.

Wait - I did have a service company in town that was in startup mode take
their site down, then proceed to call a few of the really early adopters (me
included), do moderately long interviews by phone, and then tell us they're
pivoting the company based on our feedback. Time will tell if that works out
for them, but it was unexpected.

tldr = if you're calling for feedback, call for feedback, take it, and act on
it. do not try to sell me something at the same time.

~~~
lifeisstillgood
Oh yes.

I love the idea of actually just asking for feedback. And _then_ putting a dev
in front of the ones who actually have something constructive to say.

------
ValentineC
Loved the post. I just signed up for the newsletter so that I'll get more of
these pushed to my inbox in the future.

Patrick: do you think it's a good idea to add a date of publication to your
articles? Most people wouldn't care, but I found myself trying to find it to
see how current the content was.

~~~
patio11
No, in fact I think this would be a terrible idea, because if I put 6/21/2007
people would perceived it to be sharply less valuable _without changing a
single word of the article or a fact about reality as it exists in 2013_.
Dating it is just asking people to discount my advice after a 48 hour window
from publication.

~~~
dennisgorelik
No. Date of writing article adds brief, but important piece of information
about that article.

Date is very helpful in digesting article (by putting it in context).

If you make it harder to digest your articles - you directly subtract it from
your karma.

