December 5, 2017

Reader question about market research, expensive problems, and developing an LFPS (part 3)

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:

• A possible expensive problem (i.e., “missing project end dates”)
• A “self-diagnosed” solution (i.e., “adjusting project milestone dates in real time”)

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:

• Who needs to access the system? Employees, contractors, vendors, and/or customers?
• In terms of permissions, who should be able to see what? Who should be able to modify what?
• Could a vendor ever also be a contractor? Or a vendor also be a customer?
• Will you need of have e-commerce built-in so you can take payment from customers?
• Would the system need to integrate with your accounting software?
• Should it have push notifications?
• Will in need to be localized in multiple languages?
• What reports will it need to generate?
• Do you need to generate PDFs?
• What would you want on the dashboard?
• Any unusual security or regulatory concerns?
• etc etc etc

Sound familiar?

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:

• How often to you miss deadlines?
• How big a deal is it when you miss a deadline?
• What happens when you miss a deadline?
• Who sets the deadlines?
• How are deadlines selected?
• When are deadlines set?
• Why do materials and labor get delayed?
• Are certain types of projects more likely to miss deadline than others?
• How would adjusting milestone dates prevent you from missing deadlines? Wouldn’t it just let you know earlier than you were going to miss a deadline?
• Is it okay to miss a deadline if you’re able to warn the customer way in advance?
• etc

A conversation driven by this line of questioning could reveal things like:

• Missing deadlines doesn’t have a very large business impact on the builder.
• Missing deadlines is fine if the builder can manage customer expectations better during the project.
• The real problem is estimation, not project management.
• Blowing deadlines only happens on a certain type of project, so one solution might be for the builder to stop taking that type.
• Blowing deadlines is caused by one particular vendor, so one solution would be to change vendors.
• Blowing deadlines happens most often at a particular time of year, or in a particular weather, or a particular region, so one solution would be to plan around that.
• The brand damage of missing deadlines could be mitigated by instituting some sort of guarantee.
• The financial damage of missing deadlines could mitigated by buying insurance against unforeseen project delays.
• The likelihood of missing deadlines could be decreased by changing the financial incentives for the involved parties.

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.

Win win!

Yours,

—J

BackRandomNext