The purpose of agile development is to create software successfully by adapting to changes during the development cycle. Unfortunately in practice, agile can wander from the outcome the customer needs. Wes McClure believes a commitment to value and agile development can coexist when you combine a strategic objective that does not change with flexibility in the manner necessary to achieve it.
This episode is Part 2 of a two-part series. Listen to Part 1: Why Value Is Important in Software
- Are value pricing and agile development in conflict?
- What is exposure therapy?
- What is “Marco Polo” development?
- How do you hold the customer accountable when you guarantee the results?
About Wes McClure
Wes McClure is a software developer whose purpose is to help people improve how they create software. He applies the principles of value to software development. He studied computer science at the University of Nebraska and has been a .NET developer for many years.
- Full City Technology (Company)
- WesMcClure.com (Blog)
- @g0t4 (Twitter)
I just found this and previous episode, and it was great! However, it does leave me a question about billing: How do you handle billing when it comes to this value based guarantee? Do you bill at the end of the project once the results have happened? Some kind of milestone system? Do you offer a money-back guarantee if you can’t get to the results you promised?
Kirk Bowman says
Glenn – Thanks for listening to the show.
Re: payment terms, I recommend asking for at least 50% upfront. You can also ask for 100% upfront, and you will get it more often than you think.
Re: the guarantee, I do offer a money-back guarantee. In reality, there is a money-back guarantee either way. You either include it in the proposal upfront (more value), or the customer will demand it later (called a lawsuit).
Whether you link the guarantee to the results or not depends on a) having a quantifiable way to measure success, b) how confident you are you can deliver and c) whether the customer does his part. I will also invite Wes to comment on this.
Hi Glenn, ask for the money upfront. Or at least a portion of it. Being paid upfront is a sign that the buyer trusts you and that the project is important. Remember trust and priority are critical components of a value based approach to investments and pricing. So this is a good double check too.
The psychology works wonders too. You get the money part of the conversation over with upfront. All that’s left is to focus on results. When you leave payment to the end, especially with first time customers, there’s going to be doubt in your mind. Especially if you are moving from an hourly billing model to a value pricing approach. Have you ever had a customer not pay when all was said and done? Why let something like this detract from your focus on value.
Also, asking for payment upfront provides an opportunity to provide even more value. I’ve had customers who really want to make an investment, but not have the cash flow to immediately pay for it. In these situations alternative payment schemes can be a win-win. You may find yourself in a situation to delay a final payment for 3 or 6 months and if you trust you’ll be paid, go ahead with a project that would otherwise go unfunded.
As for the guarantee, I put it in writing. I make it obvious that I’m concerned about results. I, like Kirk mentioned, would rather find out my customer is unhappy directly than indirectly through a lawsuit.
Tie this back to the measures of success and joint accountability (see Alan Weiss for more).
Also, a satisfaction guarantee is not a blank check to cancel the project should your customer change their mind after you’ve invested substantial work. That said I personally would let them cancel if they did it relatively quickly after signing, but that’s just because I don’t believe in taking people’s money if I’m not helping them. If however, we’re half way done, then a customer wanting to cancel is probably a sign of another problem, perhaps something I can help address.
Again, the satisfaction guarantee is just an extension of your focus on value. If you truly understand what’s valuable and have built a relationship with trust, then there’s really no way a customer would be anything but thrilled upon completion. Maybe the return is 8 to 1, instead of 10 to 1. No body in their right mind is going to walk away unhappy with that outcome.
George Brooks says
Fantastic show, and excited to read/hear more. I have a small design/development product firm based in KC. I have been thinking about this idea of Value based pricing in an iterative agency environment a lot lately. Can you give an example of a set of value statements that you worked from, and how you managed the clients expectations. Our experience is that so much of this is so subjective. We all know the end of the project never really ends when the results are subjective. Questions we are constantly asking…. What is finished? What is success? When do we start considering the next set of work. Or I guess, when do we start considering the next set of values.
Thanks for your great thoughts on the subject!
Kirk Bowman says
George – Thanks for your question and feedback!
There are two broad categories of value, tangible and intangible. Tangible is something you can quantify like increased sales, decreased turnover, etc. Intangible is something that is qualitative like morale, reputation, etc.
It is common in the design space to have a project that is intangible like logo or brand development. While it is harder to quantify these, you can talk in broad terms of why does the customer want it, what will the customer be able to do once he has it. In my experience, intangible value is worth more than tangible value.
Regarding project completion, you have to establish a clear scope. As part of the scope, we define how long the revision/bug period will be. For example, there will be two rounds of logo revisions. The customer will have one week to submit minor revisions to the first iteration. Then the customer will have 3 days to submit minor revisions to the second iteration.