Think about one of the last meaningful gifts you received or gave to someone. It likely wasn't some ornate thing or expensive toy, instead it was something close or emotional (which could me ornate, but likely something simple from the heart). As for me, I received cloth napkins - simple and meaningful (no more paper towels). The gift connected to me and my lifestyle. Instead of buying more paper towels, I would use the cloth napkins - duh! My girlfriend gave these to me, and I realized something in the gift-receiving process. She knows: how I eat (messy), I use a lot of paper towels (messy), I have a tendency to think I'm always out of paper towels (messy). In other words, the meaningful is there, because of a connection. And that's what simplicity is all about. Now, let me tell you another story about simple software....
About 10 years ago, I read the book Don't Make Me Think by Steve Krug. At the time, I was working with a company developing an online reservation system for restaurants. Krug's book was so timely in that it matched our sales and development goals:
- Sales product goal - remove all sales friction (get it in the merchant's hands fast).
- Product team's goal - remove all implementation friction (get users to reserve a table/seat).
We were lucky in that our CEO demanded that the product and sales teams work together to achieve these goals (as the leader of the sales and marketing group, I'd say I was also lucky to work with an amazing usability designer and product manager). Because the sales and product teams worked so closely together, following many of the principles in Marty Cagan's book too, I believe we were able to create a simple product and value prop. In other words, we did, for a short while (I'll get to that), achieve simplicity, and why?
- Sales KNEW the customer - we understood what would be meaningful, and what they would use or pay for...
- Product TESTED WITH THE PEOPLE WE KNEW - we were testing crazy. Not only would sales gather a lot of the feedback, but when wire frames were created and mock ups designed, the product team would push the potential feature to our customers/users who gave immediate feedback, all the time!
- Sales REVIEWED EACH FEATURE - the product development process we pioneered was a work of art. Each feature developed was showcased to the entire team (Cagan's ideas here). Naturally, the design team took the first review, and execs. But then the entire sales and support team would review the newly developed feature and BEFORE IT WAS RELEASED each team leader had to sign off on it.
- Product actually listened, carefully - this is where the meaningful came into play. Sales and support folks are naturally defensive with their customers/users. If a feature wasn't done correctly, you could bet one of the team members would raise a stink, and THEY WERE ENCOURAGED TO.
In part, simplicity is still hard to do... However, could it mean that your product and sales organizations be more aligned? Um... YES! Being meaningful only works when you know someone, closely.
Now, there is a continuum to this story... During the course of the company, we changed to a typical product organization - one where the sales and product team didn't really connect. Guess what happened? The execs lead feature development saying, "I know what the customers want". The product team was told what to do, and also went heads down making things look like works of art, instead of just simple to use (their feedback loop was closed). Sales dropped FLAT! Users complained about the new features, AND HOW COMPLICATED THEY WERE. Eventually, the company died... During this time of transition, I had moved on to another software company, but I was saddened to see such a great idea stumble because of the lack of meaningful simplicity.