Short answer: It depends. You can look at the MEDDIC sales process if you've never heard of it.
Longer answer: We're a tiny boutique consultancy that builds entire products for large organizations, but we also have a product we built internally for ourselves that we're starting to offer companies, so I have some experience both selling product, and consulting (that leads to building a product).
One of the things we did for consulting is refining the way we do it. We didn't have much trouble with qualifying, but more with scoping and helping organizations that come to us understand what upstream efforts and conditions lead to downstream success. In other words, do you have data, is this a problem, who is this a problem for, can we get them at the table please, no we really insist please get the people we'll build this for at this table.
Having gone through this many times, we constantly refined this by auditing our past projects: what worked, what didn't, why, how can we test these hypotheses.
We then came up with a template to scope these projects that we give our clients: this saves both of our teams from a lot of meetings initially, and practically everyone told us that it has really helped them narrow down and understand their own problem better, and the criteria for success better.
Next, for consulting, we dive into the problem domain. We've worked with different sectors (energy, multi-modal transportation, health, luxury, ecommerce, public relations, banking, telecommunication, retail, etc), and it has helped us to have prior knowledge on that domain in order to talk with precision with their experts.
Before we build a product, we have to nail down the problem they're having. The "Jobs to be Done", if you will. The reasons of "non-consumption", what they're doing, why, how they're doing it, how much it's costing. "Desirability, feasibility, and viability".
When building the product, we prototype, we talk with their experts and users, we constantly invalidate hypotheses. You don't want to work for a year building a product that will not be used by anyone (even if you're paid for it: I call them the bitterest dollars, and having gone through that earlier, I really don't like that, hence changing our process after taking over to insisting and insisting that their people get involved in this: I'm building for your engineers/marketing/sales? Please get them at the table so we could talk without an executive being present).
For the product side, I'm having a lot of calls and interactions to qualify people: there are many who request access to the platform, but I'll have calls with them to know if it's really a fit and to come up with a pricing for what we offer (real-time collaborative notebooks to train, track, deploy, and monitor machine learning models). Many request access but they don't really have the pain, or work on projects that have stakes, so we orient them to other products. The products makes sense for people for whom non-productive time is really imporant and who don't want to waste hours or days with problems in their ML lifecycle.
So, for consulting: we don't really do qualifications because most of the organizations we talk with are large organizations that can afford our services, and we mostly do conversations so we all are on the same page and they get the whole picture [is my problem a machine learning problem at all? what problem do I need to solve? Is machine learning a good fit for this? etc].
For product, right now, I do many conversations both to make sure it's a good fit, and come up with pricing plans that suit different people. Yesterday, I was talking with a PhD student who didn't have the means, but I extracted problems they were having and were trying to come up with a solution for them [including changes in the product and changes in pricing]. I've also been talking with CEOs/CTOs of companies undergoing acquisitions. All in all, everyone was rather generous with their time to talk about their problems and come up with solutions.
Comments
Short answer: It depends. You can look at the MEDDIC sales process if you've never heard of it.
Longer answer: We're a tiny boutique consultancy that builds entire products for large organizations, but we also have a product we built internally for ourselves that we're starting to offer companies, so I have some experience both selling product, and consulting (that leads to building a product).
One of the things we did for consulting is refining the way we do it. We didn't have much trouble with qualifying, but more with scoping and helping organizations that come to us understand what upstream efforts and conditions lead to downstream success. In other words, do you have data, is this a problem, who is this a problem for, can we get them at the table please, no we really insist please get the people we'll build this for at this table.
Having gone through this many times, we constantly refined this by auditing our past projects: what worked, what didn't, why, how can we test these hypotheses.
We then came up with a template to scope these projects that we give our clients: this saves both of our teams from a lot of meetings initially, and practically everyone told us that it has really helped them narrow down and understand their own problem better, and the criteria for success better.
Next, for consulting, we dive into the problem domain. We've worked with different sectors (energy, multi-modal transportation, health, luxury, ecommerce, public relations, banking, telecommunication, retail, etc), and it has helped us to have prior knowledge on that domain in order to talk with precision with their experts.
Before we build a product, we have to nail down the problem they're having. The "Jobs to be Done", if you will. The reasons of "non-consumption", what they're doing, why, how they're doing it, how much it's costing. "Desirability, feasibility, and viability".
When building the product, we prototype, we talk with their experts and users, we constantly invalidate hypotheses. You don't want to work for a year building a product that will not be used by anyone (even if you're paid for it: I call them the bitterest dollars, and having gone through that earlier, I really don't like that, hence changing our process after taking over to insisting and insisting that their people get involved in this: I'm building for your engineers/marketing/sales? Please get them at the table so we could talk without an executive being present).
For the product side, I'm having a lot of calls and interactions to qualify people: there are many who request access to the platform, but I'll have calls with them to know if it's really a fit and to come up with a pricing for what we offer (real-time collaborative notebooks to train, track, deploy, and monitor machine learning models). Many request access but they don't really have the pain, or work on projects that have stakes, so we orient them to other products. The products makes sense for people for whom non-productive time is really imporant and who don't want to waste hours or days with problems in their ML lifecycle.
So, for consulting: we don't really do qualifications because most of the organizations we talk with are large organizations that can afford our services, and we mostly do conversations so we all are on the same page and they get the whole picture [is my problem a machine learning problem at all? what problem do I need to solve? Is machine learning a good fit for this? etc].
For product, right now, I do many conversations both to make sure it's a good fit, and come up with pricing plans that suit different people. Yesterday, I was talking with a PhD student who didn't have the means, but I extracted problems they were having and were trying to come up with a solution for them [including changes in the product and changes in pricing]. I've also been talking with CEOs/CTOs of companies undergoing acquisitions. All in all, everyone was rather generous with their time to talk about their problems and come up with solutions.