[yungookim]

In my experience, scaling a consulting business is more to do with sales and building long-term relationships. Sales is a skill that can be acquired, and you don't have to be very good at it to get started. Learn the basics of business development and sales; try experimenting with different approaches. See what fits you best.

IMHO, I think the problem is "getting projects from 0 to POC/MVP state." These are projects that typically have an expiry. Either the MVP fails to validate its viability, or when it succeeds, the business will try to find someone who can commit full-time. It's hard to find something in the middle. More often than not, consultants who position themselves here spend more time on finding new contracts than doing the work. Since once a contract is completed, there is little continuity to it. Aside from a small maintenance contract, which is not enough to keep the light on. Doing the work pays, searching for work does not.

Another problem is, you are in the space where you have to compete the most, and therefore "building MVP" contracts become a pricing competition. Competing with offshore dev shops on price is hard to do.

So, to sum up, in my humble opinion, you need to spend time upgrading business development and sales skills. Think about what unique skills you can offer that are less price competitive in the market and offer you a long-term contract. I hope this helps.

[LaundroMat]

I wonder if building MVP contracts is a very price-competitive market, at least in terms of how I interpreted that domain as the the OP describes it.

I believe there is a lot of value in helping clients determine what an MVP should be (i.e. understanding of the business problem to be solved) and then help them validate solutions by building (or helping them build) an MVP. It appears the OP has the skillset to do both, and off-shore dev shops can't do that.

Plus, you need a good understanding of local practices, culture and market to be any good at this.

[yungookim]

Yes, this is a good point. Thanks!

[lpasselin]

I've done a few contracts as an independent in the last two years completely agree that sales is the most important and is also the hardest.

I disagree with you when you say problem is the 0 to POC/MVP (excluding sales). I think that is the easiest and most fun part of a project. The hardest is 0 to first line of code.

When you complete part of the POC/MVP and it seems to be working, clients understand what you are worth.

In my experience, after the POC, managers had no problem boosting the budget because you've proven you can do the job and there is low risk in giving you more work and freedom to continue adding features.

I might have been lucky to get along really nicely with all of my clients yet.

Finding the initial problem is the hardest for me. All of my contracts were from previous contacts and someone knowing someone...

If anyone has it the other way around, I'd love to learn more.

[edem]

Thanks for the insightful advice, this is very useful.

[kblev]

> upgrading business development

Any tips on that?

[yungookim]

I can only tell from my experience. It's probably not applicable to everyone, nor is it the best path.

In my case, I have been involved with many startups in the AI/ML B2B space from the early days of my career as a software developer.

At one point, I recognized that if you want to build something great, it really helps to listen to the customers and the prospects. So I started to shove myself into a hybrid role of sales engineering and software engineering. To get started on the sales engineering, I reached out to all the business developers friends and asked them to share their frameworks, processes, and learning materials. Also did a lot of Googling to educate myself. Then I asked the appropriate people in the company if I can join small-stake sales call. To start with small-stake calls and learn how things work. It did not take a long time to start receiving invites from the sales to help with high-stake customers. Since in most cases, people who can build and sell (you don't have to be the best at either) are rare and needed.

[edem]

This sounds really interesting. How would you define what Sales engineering is?

[yungookim]

In my view, it's the person who is able to understand the business problem the customer is trying to solve, then evalute if the problem is something you or your company can and want to solve. If the problem is something your company want to solve, provide the technical evidences during the due diligence process to the prospects that you can solve their problems. In my case, this also bridged nicely to help out the existing customers to get new things done quickly.

[edem]

Thanks, this sounds good.

[david-cako]

In cloud software at least, sales engineers/solutions architects work with the account manager to drive adoption of services. A lot about evaluating a customer's problem space or existing architecture, and proposing possible cloud-native architectures.

Sales engineers also do educational sessions and service-specific "immersion days" for the platform, which usually tie into the customer account manager's sales and advocacy for the platform, and helps to build relationships with the customer's engineering team.

[edem]

This sounds exactly my cup of tea.

[david-cako]

I worked in a customer facing role for a while it gave me a better sense for vendor relationships. I say it's worth it if you are curious.