Captain’s log, stardate 20171205
Sent by Jonathan Stark on December 5th, 2017
Long-time reader Brent Giesler wrote in a little while back to ask my advice about some market research he's been doing.
Brent is a web application consultant and he's been considering niching down on the custom home builder market. He has interviewed a number of builders and came up with two different potential “expensive problems” from his interviewees.
Yesterday, I tackled the first one so let's look at the second one today:
Another builder said he'd love a way to be able to adjust his project milestone dates, in real time, as materials or labor is delayed. That would keep him from ever missing his project end date and causing problems for his buyers
Imagine yourself in Brent's shoes. How would you respond to this? What would you ask next?
When you are interviewing a non-technical business person about their business problems, the interviewee will have a tendency to muddy the waters by including a self-diagnosed solution alongside their expensive problem.
If we break this builder's answer into two parts, you can see what I mean:
When I was younger, my first reaction to hearing a muddy answer like this would be to fixate on the self-diagnosed solution provided by the client.
I would start thinking about building a custom project management software application that allowed teams of people to keep a custom home build project timeline updated.
The stuff I'd be imagining would include the UI, the system architecture, the data model, the backend, and so of.
If you're like me, this line of thinking would lead you to ask questions like:
This line of questioning is meant to determine scope. Which is to say that it is the software developer trying to get a sense how much it will cost (in time) to build the application so that he or she can estimate a price.
Older, wiser me wouldn't ask any of these questions. Instead, I'd ask things like:
A conversation driven by this line of questioning could reveal things like:
To me, only a handful of these possibilities suggest a software solution. Which means that there's a good possibility that Brent's interviewee self-diagnosed an ineffective (and probably expensive) solution.
One of the true beauties of value pricing for project work is that it protects the client from spending a bunch of money and wasting a bunch of time on a self-diagnosed solution that won't solve their problem.
This is because you have no way to calculate a price if you don't know what the client's perceived value is.
So you're forced to have a Why Conversation where you drill into the problem the client is experiencing, the business outcome they want to achieve, and a ballpark value of what the outcome is worth to them.
Furthermore, you can set your price much higher than you'd ever estimate at some hourly rate when you find a project that is enormously valuable to a client.