Hacker News Reader

I think you're mistaken on a couple of points:

- VCs aren't interested in "revenue tomorrow" unless you mean a 10x+ exit multiple. VCs want you you to focus on your product because there's an invisible( and sometimes not so invisible) clock running as soon as you take the investment.

- VCs aren't interested in 5-10 year tails on their investments. Most are looking for an 18mo.-3.yr ROI. If you can prove revenue and 'market traction' they'll extend your runway accordingly, however that's a constantly moving target and generally the types of VCs who are interested in the 'long tail' aren't the same that want to give you money at the infancy of your company.

- There is definitely a big difference between a traditional consultancy and a product focused organization but only in the sense of the 'end goal'. If your entire plan is to bootstrap your company by building a consultancy, it's easy to keep a separation of concerns between the two halves of your organization. Usually the "clash" that you're talking about is when a consultancy based/focused organization decides to build a product, not when a product company decides to do some consultancy.

Developers (in fact, all of technology) are considered cost centers at ALL businesses. There's not an MBA on the planet that wouldn't jettison the entire technology cost-center of their business in a heart-beat if they could figure out how to do it and still achieve their monetary objectives.

> Developers (in fact, all of technology) are considered cost centers at ALL businesses. There's not an MBA on the planet that wouldn't jettison the entire technology cost-center of their business in a heart-beat if they could figure out how to do it and still achieve their monetary objectives.

This is pretty funny because in a software company, devs are the only ones creating actual global value (as in, something that a customer could realistically derive value from). Every other instrument in the company is pretty much how to turn value into incoming cash flow or reduce outgoing cash flow.

It'd be like Apple trying to jettison its designers.

This is an extremely cynical comment. First, hard-line profit/cost center thinking is falling out of fashion at top MBA schools like Harvard and has been for years. But also, a reasonable MBA would be able to recognize when the tech team is actually creating value vs. when they are dead weight that could be outsourced. And, it's really myopic (and the kind of thing that people make fun of engineers for) to believe that tech is the only ones adding value. Value (perceived, communicated) is potentially created all up and down the chain.

Either they're dead weights or they're not. How does outsourcing change the equation? Certainly not by reducing cost -- not if you want to outsource to non-dead-weight development group.

Seriously? Take a bunch of do-nothing office drones, can them all and get a maintenance contract with some consultant in eastern Europe. What's hard to understand about that?

You will probably lose the same amount of money you thought you were saving in management and communication.

> (perceived, communicated)

Oh, I just meant value as it applies to the person who actually ends up using whatever the business is making. Of course perceived and communicated value is most important to a business. After all, if you could somehow convince people to just dump money on you without doing anything for them at all, you'd be the best business of all.

I have an MBA and I certainly do not think devs are a cost center.

"if they're both the same thing that great but doesn't happen that often in practice"

On one side you've got a customer who needs something badly enough that they're willing to pay you real money. On the other side you have a larger number of potential future customers. As they say "a bird in the hand is worth more than than two in the bush".

Of course the customer is never taking the product in exactly the direction you want it to take. But there are few things less valuable to a company than a close relationship with customers and visibility into their needs.

If your consulting clients' needs and your planned product's capabilities aren't aligning, how about adjusting the plan rather than dropping the clients? In my 20 years of experience in the industry, adjusting the plan has always been the better strategy.

> the customer is never taking the product in exactly the direction you want it to take.

This may actually a good thing. When you are developing a product, getting a good market fit is tricky. Consulting for your user allows you to precisely understand what your users expect of your product.

Yes, it may not be what you expected to build, but building what your users actually want is usually a good idea.

"The big difference between consultancy and product based development is that with consultancy you're building what the individual customer needs rather than building what your product needs strategically in the long term...."

If so, then focusing only on product development is going to be successful only if you know what your customers in aggregate need better than they do. Isn't that the whole 'agile' lesson?

Focusing too narrowly on immediate improvements can constrain scope to bug fixing and building the best version of the current product possible rather than adding new features and directions for the product. It makes the product vulnerable to competition that better meets the ever-changing needs of the market.

I'm not saying it can't be done, just saying that you have to be careful when managing scope. And that isn't even a unique concern to a consultancy-based model, it just has different pitfalls.

Keep in mind you don't know what the features and directions of your product should be until you talk to your customers and understand what roadmap will fit their needs. For every DropBox there are hundreds of failures that didn't get it right about whom we never heard about.

Let's say your consulting pays for the time of one engineer while your investors pay for another one. If you stop your consultancy, your workforce will have to be slashed by 50%. Unless the custom development job is focusing on features that add no value to the product for other customers, this is insanity.