You're mistaken about why VCs want firms to focus on product rather consultancy, it's not for the short-term as you suggest but rather the long term.
Time spent on consultancy today gets you revenue today but time spent on product gets you revenue tomorrow. Focusing on product rather than consultancy is the long-term play because you're focusing on what maximizes your value 5-10 years down the line rather than what pays the bill today.
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 they're both the same thing that great but doesn't happen that often in practice).
There's also a distinctively different mindset between product and consultancy companies. At a consultancy the consultants are seen as the revenue generators and the product developers as a cost base; at a product company developers are seen as revenue creators. It's easy to underestimate the cultural impact that has on companies.
- 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.
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.
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?
"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.
Time spent on consultancy today gets you revenue today but time spent on product gets you revenue tomorrow. Focusing on product rather than consultancy is the long-term play because you're focusing on what maximizes your value 5-10 years down the line rather than what pays the bill today.
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 they're both the same thing that great but doesn't happen that often in practice).
There's also a distinctively different mindset between product and consultancy companies. At a consultancy the consultants are seen as the revenue generators and the product developers as a cost base; at a product company developers are seen as revenue creators. It's easy to underestimate the cultural impact that has on companies.