Impress your CTO (3)

Imagine the following conversation between a product owner and developer

Product Owner: “I want a CRM system”
Developer: “What does that do?”
PO: “It’s a customer database that lets me manage and report on my communications with my customers”
Dev: “That sounds easy, I’ll build you one this iteration”

One week later …

Dev: “Here you go. You log in here and here’s a screen where you can add a record for each customer. When you click into a customer record you can also add some notes for each time you’ve talked to them”
PO: “Wow, you did all that in a week, awesome. Now let’s add in the ability to make some notes for future calls that I need to do and a screen to show what tasks I have upcoming”
Dev: “No problem”

One week later …
PO: “This is so cool”

Brand new projects often start like this. But it doesn’t take long for fatigue to kick in. A few more iterations and all of a sudden you’re getting bogged down in details like:

• Download to Excel
• Upload from Excel
• The fact that you should really be validating postcodes
• And show the location on a map
• And have better collaboration facilities
• And handle customer segmentation
• Ability to handle email templates
• And initiate voice calls
• And route incoming calls to an appropriate agent
• And let someone apply a credit to a customer’s account
• etc, etc, etc

At this point you start to realise why no-one sane would build their own CRM.

The Importance of Unspecified Requirements

You see you have functional requirements and you have non-functional requirements. But beyond all of these you have the unspecified requirements. These last ones are really important because your product owner considers them so obvious that they aren’t worth mentioning. Of course your CRM system has to handle loading records from Excel – only a buffoon would not know that!

The solution isn’t to insist on 100% detailed specifications before you start building. That way another type of madness lies. Nor should you consider your job well done because each week you have built what your customer asked for. The best developers are the ones who deliver the best working software, which is not as simple as building what was written down in the spec.

Worry about their unspecified requirements before you get too far down any path. It doesn’t have to involve much coding (if any). If someone asks you to build a CRM then do a sort of throwaway prototype first. Not one that involves any coding. (I’ve seen some great throwaway prototypes written using Excel). Why not get a one-month license to Salesforce (or whatever). This is a great way to get to see really what features they value, where their frustrations are etc. Then if you discover that Salesforce is the right answer for them then thank your lucky stars that you’ve had a narrow escape from attaching a massive bespoke millstone round your neck for the rest of the time with your company. And if you discover that there is something really special about your requirements, well, then you can build a truly great application that really addresses the real problems your users are facing.

 

How to make 3000 look like 8000, or #marketing

See below how CarGiant, a UK-based retailer of used cars does it.

First off, the organic search results:

If you search for Car Giant they have already anchored in your mind that they have over 8000 vehicles

So now you land on the home page and note how the “over 8000” has now changed to “up to 8000”. That could be a whole lot of a smaller number. So let’s do a search for all vehicles up to the maximum price available.

And there you go, just under 3000 cars. Which is definitely “under 8000” as promised, but by this time you’ve still got in your head that Car Giant is a truly giant organisation with 8000 or more vehicles to sell you.

See also https://en.wikipedia.org/wiki/Anchoring#In_negotiations