<i>(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'.")</i><p>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.<p>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.<p>Additionally, clients want to lower the risk that a project will fail (note: this doesn't mean <i>technically</i> 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.)
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)"
<a href="http://ebusiness.mit.edu/research/papers/197_Cusumano_ProdSrvcsBusMod.pdf" rel="nofollow">http://ebusiness.mit.edu/research/papers/197_Cusumano_ProdSr...</a><p>It can be a little bit outdated but the main points remain the same.<p>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.
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).<p>In terms of benefit-per-sentence, this is right up there with the best books on business I've ever read.
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!
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.
<i>"Actually call them and ask how they're doing"</i><p>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.<p>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.<p>A/B testing let's me optimise. Talking let's me discover my customers' problems.
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.<p>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.