(Leggi la versione italiana qui.)
I’ve met a software engineer in Italy that was developing an application to help a Mercato dei Salumi e Formaggi to better serve their customers.
Here I tell how he managed to understand what was important to the users and which functionalities should be delivered first.
My colleague was committed to develop incrementally based on his client needs. That translates to:
- release a new version of the application in production periodically (let’s say two weeks) with new features, bug fixes and possible changes requested by the user
- let the user decide (and help him to decide) which features must be delivered first
- let tests guide software design and implementation.
Here Comes The (User) Story
He went to the market to talk to the salesman (a friendly and talkative guy named Gioseppo) and heard…
Vorrei offrire il meglio ai miei clienti… Voglio dire, il meglio che loro possono pagare, capisci? Conosco le persone e i miei prodotti. Però ho bisogno di capire subito quello che devo offrire a loro.
Per esempio, agli studenti offro fin da subito la cosa più economica possibile data la loro poca liquidita. A noi italiani piacciono i prodotti gourmet e più tradizionale, ma anche noi non abbiamo molto denaro da spendere in salumi, formaggi, prosciutti.
Gli americani sono ricchi, ma loro non hanno idea di cosa sia “gourmet” oppure “tradizionale”, e sembra che a loro non da fastidio se c’è troppo grasso. Anzì, è anche meglio. Alle ragazze solitamente non piace il grasso. I brasiliani non comprano niente, soltanto guardano, chiacchierano in quella lingua incomprensibile e vanno via.”
Gioseppo’s market sells many different kinds of salumi, cheeses, hams to people from all over the world. My colleague understood that Gioseppo needed an application to help him offering quickly the right product to each kind of customer, increasing the selling and (very important to Gioseppo)
offering the most expensive product a customer can buy making his customers happy.
He figured that his customers could be grouped in different profiles according to their preferences to certain product characteristics (gourmet, tradition, price, fat), their behavior and purchasing power. My colleague started to write down in a piece of greasy paper…
With Gioseppo’s help, using a ranking that goes from 0 (I don’t care at all) to 5 (Very Important), he assigned to each profile the following attributes:
| Tradition | Premium | Price | Fat | Magician | 2 | 2 | 5 | 0 | Healthy | 1 | 2 | 3 | 5 | Expert | 4 | 4 | 3 | 1 | Gourmet | 2 | 5 | 0 | 2 | Curious | whatever, they wont buy anything anyway |
How to implement the “best offering” algorithm was still a little bit unclear. Talking to Gioseppo, however, they reached an agreement.
They are magicians due to their ability of doing a lot with virtually no money. Offer them the cheapest products.
They expect a miracle of eating Gioseppo’s products and consuming no fat. Offer to healthy people salume, cheese and ham with less fat. In case one or more products have the same amount of fat, present the most expensive ones first.
They prefer the best products, but they may not have enough money to buy them. Offer them mainly traditional products, or gourmet eventually.
(Gioseppo’s first idea was to have the app suggesting products gravitating towards a value ($) defined by him. However, since the idea was to have the app up and running as quick as possible + learn as they go, the requirement was changed to the simplest and apparently identically effective rule above.)
They can spend a lot of money consuming Gioseppo’s product. Offer only the most
expensive tasteful products.
They wont buy anything, but they do ask a lot of questions. Move along, nothing to do here.
They were not 100% sure these rules would work, thus they decided to collect feedback when using the first versions of the app and change them if needed.
They figured this approach is ok because they had to start somewhere. Just thinking and speculating about a decision can lead to nowhere (or to an undesirable place), so they just took a decision that seemed quite reasonable and tested it in the real world. In case that wouldn’t work, they’d learn with their previous attempt(s) and would try again.
About the UI (user interface), they decided to start with a minimalistic mobile app. At that moment, the data was going to be loaded directly into the database by the my colleague developer.
Ideas for The Future
They wrote down other features they were considering for the next releases so they could focus on the first release and not loose track to were they were going:
- web user interface for products management, allowing Gioseppo to consult the available products, add and remove items;
- optionally sending newsletters based on his customers’ interests;
- an Android game app was actually mentioned by Gioseppo to entertain and remind his customers about their experience in his market (quite a modern guy indeed).
To be continued…
*This is a fictional history – or do you believe in titans?