Customers & Price Differentiation

Disclaimer: This has nothing to do with BA work.

While shopping for a new Moleskine recently (yes, I am that guy) I noticed that the more expensive/up-market the physical retailer, the cheaper their Moleskines were.

My father always used to tell me the same things about wine and scotch. Cases of VB (Cheap beer for any non-Australians) got more expensive as the neighbourhood went up-market, but prices for Glenlivet, Glenmorangie, and Penfolds (Expensive wine for the non-Australians) went down. My father and I had in common high-end tastes, and low-end budgets.

Why?

My father’s explanation was roughly this:

• In a lower-class area someone gets a bit drunk, wins some money gambling, and decides they going to buy something expensive and they’re going to buy it right now.
  
• In an upper-class area someone resolves to replenish their wine cellar or bar and thus decides to buy a specific item and they’re going to buy it when convenient
  

So the idea of a price-conscious consumer looking for the cheapest price for a product is turned on its head. They’ve decided to buy at a set price no matter what the item is. So there’s no point giving them a discount on 16 year old Balevines – because they’ve decided on a price-point so you maximise your margin by having high-margin product in every price range over the normal level.

The traditionally quality-conscious consumer on the other hand becomes price-conscious within his market. You can’t tempt him with a cheap Canadian Club when he wants Talisker, but a convenient and price competitive offering on the Talisker may do it. You need to be price-competitive in the higher end of your market, where people will shop-around, but can afford to have higher margins in the lower end.

As it is with Scotch, so it is with Moleskines.

The cheap-and-nasty stationery retailer in Sydney CBD has the Memo Pockets at almost $30 and hidden up the back; while the relatively up-market one has then at $23 and placed right at the front of the store. Even more interestingly the up-market retailed is even price competitive with EBay to within %10. Retail and price differentiation is so dammn interesting.

If there are any retail companies out there (especially in the rag-trade) that want a Business Architect please give me a yell. I would love to be part of empowering front-end retail staff to make pricing and product-mix decision at a micro-store level by delivering an awesome analytics and what-if analysis right to the register.

Focused Communication: If it's not on-topic, it's just off-putting.

Every box, arrow, and bullet-point that doesn’t directly give across the information you are trying to convey is worse than useless, it directly distracts from your message.

 

When a Use Case includes User Interface details, not only does the UI description suffer from being in the wrong form, but the use case suffers from having information that distracts and obfuscates the central point of a Use Case. A Use Case is mean to encapsulate the back-and-forth of interaction between participants, trying to cram in details about how information is presented and how the user gives feedback just hides this.

 

Processes are where people always get this wrong. I was talking with a friend recently on a paper he was writing comparing three process models recently. He was trying to make a point about removing unnecessary emailing and waiting in an application process but this was hidden by the sheer volume of information on the minutiae of user interaction, and information collected that was in there as well.

 

I’m not making a case for only doing “simple” modelling or communication. I like an incredibly complex model as much as the next guy (Assuming the next guy is a border-ling OCDD, modelling obsessive). It just has to be the right sort of complexity; if reality is complex you need a complex model to explain it. Hell – sometimes it’s complex on purpose. I once did a process model that had to be printed in 4 point type to fit on one A2 page but the point of that was to get across how out-of-control complex the system was.

 

Just make it focused on what it needs to do, and be brutal about cutting out any information that isn’t immediately needed into a separate model.

 

(P.S. First test of email blog posting.)

 

Language is to Thought, as Modelling is to Design

I'm a touch obsessive about using modelling correctly and consistently, whether it's ER, BPMN, Use Cases, or sequence diagrams it's worth doing rigorously to the standard.

Sloppy modelling comes out of, and causes slopping thinking. I'll even take it a step further - modelling is thinking.

If we use the metaphor of language this is obvious to us. Someone who doesn't have the words to describe something can have a flash of an idea, but he will struggle not only to describe the idea to someone else - he will also struggle to tease out all the details and implications of the idea.

An economist has a lot of language to describe what is happening along a supply and demand curve. Having this language allows him to communicate with colleagues easily - but also to think rationally and easily about what is happening inside a market. He has all the mental shorthand readily available.

Similarly a process modeler has a lot of boxes and arrows to describe what's happening in a process and how two people may collaborate. So not only can he communicate with the workflow developer, but he has the vocabulary to do it.

Case in point - I've noticed that has BPMN's support for messaging has improved people are thinking more and more about how processes communicate. It's not that it didn't happen before, but now we have the language to describe it.

In both cases the purpose of the language is that you shouldn't even think about it anymore. You shouldn't see use cases, process modelings, or ER diagrams; you should see interactions, collaboration, and entities. It's only when people model badly that you have to stop to think about models.

A word of warning though - languages box you in. Using the BPMN view may blind you to something that's more obvious in the text-narrative view. The Class diagram view may blind you to something obvious in the ER view. The Keynesian language of economics may blind you to traps of govt inefficiency blindingly obvious if you are speaking like Milton Friedman.

A lot of people assume that you can simplify language as long as you get across the basic idea, and this is true up to a point. But if you don't know the language, you'll never know what you've left out.

This is a very long winded response to a conversation I had at work yesterday about what sort of training we should send budding process-improvement champions on. Someone suggested a course that focused on strategies and process patterns was best, I held that focusing on teaching them to talk about processes was all that was necessary. If they've bright it's all you need, and if they're not it's not going to work anyway.