[j45]

15 years of consulting left me dreading reading this article a little.

There is no set formula that I've found. I'm open to finding it. Until then better I get at business, the better I get at all these different ways of "earning" formulas.

You exist to help the customer get the result they want, who usually don't know what they want.

If you don't know what you're doing, or worse, don't know how to help the customer find what they need, the meter can be run up hourly, or lose your shirt fixed price. Both are poor delivery of value for the customer in retaining a sustainable, no-surprise-giving, stable business partner.

The second we are in consulting, we're in business, not an hourly employee. It's a comfort net to say otherwise of not having to learn business skills.

Still, businesses are great customers. They're a lot more logical than consumers. They especially listen to anything that adds value to their business.

What's this hokey "add value" thing?

One definition is:

Saving or making your customer money, or time.

Time? Yes. The cost of their employees is the #1 cost in their business.

So, if person x spends 5 hours a week generating a spreadsheet at $15/hour, and there's 50 working weeks a year, this spreadsheet cost them $3750 in 1 year.

That's just $15/hr!

If I spent 10 years learning to do something in 2 hours, should I charge the customer the 2 hours, for the 10 years it took to learn, or say.

"This is costing you $4000 a year, I can get rid of it for $1000 permanently".

If it's a large company, you can even look at the savings over 2 or 3 years.

See? You're saving your customer money. Get the sign-offs on any solution from the ground up to the signing authority and put good decisions in front of them.

One reality is you end up doing a bit of both fixed and hourly. The better you understand your clients business, data and processes, the more fixed you can go.

With new clients, for example, I do small fixed price projects to minimize risk for the client and to build small momentum building wins.

When customers see the value themselves, instead of trying to trick them into liking you, what they pay me becomes far less of an issue. Some still prefer hourly so I just quote the total number and let them imagine what the hourly rate is. Some still want to know the hourly rate and I let them know we work extremely fast and have 15 years of experience each.

Regardless of hourly or fixed, if at the end of it they look at it and say "yes, they built what I asked but it wasn't what I wanted", customers will start doubting good decisions in the future because your inability to guide the canoe better. This is a bigger threat to your business than anything, especially if you want to stay in consulting.

Help your customers spend their money with the care as if it was your own, and you'll find yourself with as many long term consulting customers over the years that you can handle.

[iktorn]

Mentioned it before in another thread here: This makes sense when you have a well established business that's tweaking it's processes. Impossible when building an MVP and/or experimenting with a new product/service.

[j45]

Disagree. Absolutely possible.

I currently build MVP's, in 30-90 days if it can be pushed that fast. I'm a lean practitioner for over 10 years starting in manufacturing.

You want to help your MVP's become long term customers by helping them grow and make money. If they don't get this, it's a real risk to their business, let alone your relationship with them.

For MVP's: You have to invest in understanding your tools and how long it will take to identify and build only the features that customers can't live without.

My original consulting business is for established businesses, but they were all smaller 4-7 years ago.

[iktorn]

"build only the features that customers can't live without" - who makes this call? What if you disagree on this? What if the customer learns something new after 2 weeks and needs to change the scope?

[j45]

Who makes the call?

If it's truly a lean MVP, the end user/paying customer. Is it an MVP is if no one is getting out of the building and talking to customers/users before designing or writing a line of code?

Completing the problem solution fit, product market fit, and engaging in customer development prior to writing a line of code has to happen if we are wanting to be honest when using a term like MVP.

If you feel this is a binary issue: ultimately the person signing the cheques make the call, and you have a choice on whether to accept said cheque for managing said potential headache.

The grey area in between:

If the customer wants to do whatever they do and call it an MVP by sprinkling the lean dust on it to justify it, you have to recognize it for what it is and either adjust your approach, or decide if that kind of work is something you can live with. No process can correct development pagentry, management/design by committee, and failing to get out of the building.

Building an MVP requires getting through the build - measure - learn loop as quickly as possible.

Interrupting you mid-cycle if it's that ground breaking (customers are saying I'm trying to find a way to give you money) requires answering "Did we really understand anything before hallucinating an MVP ourselves"?

It leaves a few options:

- Change the scope

- Change the deadline

- Change the budget

- Trade features -- something that was important can no longer be important as a result of what was traded.

Avoiding this is the business skills development we all constantly need that I mention to in my initial post.

For me, I try to make sure I understand, and the customer understands why we're doing the things we want first and hopefully minimize the above.

I don't rush customers into building something, but rather rush into understanding what our experiment is, and why we're testing those things. It helps create a checklist to test our assumptions/discoveries against when the next great insight comes in.

[kubaf]

Dont you think that what you are describing sounds like a huge overhead. Rather then tweaking the product you have to "trade features" with customer.

It's also something that is very difficult to scale. It's hard to expect that every person who is good on the job is also good in negotiating with customers.

[j45]

Project management is a real part of software development.

I make no statements about whether the developer should do the project management -- only when a good process happens, results are good.

The developers who can manage a process that they're a part of is a skill that we should all aspire to, though, because people aren't hiring us for just our technical prowess, but rather, our ability to interface those skills to finding and completing business goals.

I do agree that avoiding the scope changes while doing an iteration is essential, and can be often lessened or deferred until the next .. sprint.

[ramayac]

Love this quote: "The second we are in consulting, we're in business, not an hourly employee. It's a comfort net to say otherwise of not having to learn business skills."

Great comment, thanks for sharing!